תוכנות תכנות C ו-C++ וכלי ניפוי שגיאות בלינוקס

דף הבית » פייתון » תוכנות תכנות C ו-C++ וכלי ניפוי שגיאות בלינוקס

אם אתם מגיעים מרקע של Windows + Visual Studio ופתאום מגיעים לבסיס קוד ענק של C או C++ בלינוקס, השינוי יכול להיות אכזרי. מעבר על מאות אלפי שורות עם GDB מאחורי עורך כמו VS Code, והמתנה של 30-60 שניות לכל שלב, יכול לגרום לכם לתהות האם אתם עושים משהו ממש לא בסדר או שמא פיתוח לינוקס פשוט איטי מעצם עיצובו. החדשות הטובות הן ששרשראות כלים וניפוי באגים מודרניים בלינוקס הם בעלי יכולות יוצאות דופן; ​​אתם רק צריכים לדעת כיצד להגדיר אותן ואילו כלים מתאימים לפרויקטים גדולים של C/C++.

מדריך זה מוביל אתכם בנוף של מהדרים, IDEs וכלי ניפוי שגיאות ב-C/C++ בלינוקס (ראו שליטה בלינוקס מאפס ), החל מ-GCC, Clang/LLVM ו-IBM Open XL C/C++ ועד GDB, Eclipse, SystemTap, strace, ltrace וזרימות עבודה מתקדמות של core-dump. לאורך הדרך, ניגע גם במערכות למידה קלאסיות (כמו Geany + GCC) ונציג טיפים קונקרטיים להאצת ניפוי שגיאות ולקרב את פיתוח לינוקס עם C ו-C++ לנוחות שאתם אולי רגילים אליה ב-Windows.

מהדרים עבור C ו-C++ על לינוקס: GCC, Clang/LLVM ו-IBM Open XL

בלינוקס, שרשרת הכלים הייחוסית עבור C ו-C++ היא עדיין GCC (אוסף המהדרים של GNU), כאשר g++ הוא חזית ה-C++ שלה. רוב ההפצות שולחות GCC כברירת מחדל, וכמעט כל המדריכים, מערכות הבנייה וצינורות ה-CI מניחים שהוא קיים. בדרך כלל אתה קומפיל עם פקודות כמו gcc עבור C ו- g++ עבור C++, למשל g++ -g -O2 main.cpp -o app כדי לבנות קובץ בינארי אופטימלי הניתן לניפוי באגים.

Clang ומערכת האקולוגית של LLVM התפתחו לחלופה רבת עוצמה ל-GCC בלינוקס , ומציעות קומפילציה מהירה, אבחון מעולה ומערך עשיר של כלים (ניתוח סטטי, עיצוב קוד, סניטייזרים ועוד). Clang הוא חזית C/C++ שנבנתה על גבי LLVM, תשתית מהדר מודולרית בקוד פתוח התומכת בארכיטקטורות ושפות מרובות ומתוחזקת באופן פעיל על ידי קהילה גדולה.

IBM Open XL C/C++ עבור לינוקס ב-Power הוא שרשרת כלים מסחרית המשלבת באופן הדוק את Clang/LLVM עם המומחיות ארוכת השנים של IBM באופטימיזציה של מהדרים. הוא מיועד למערכות Power של IBM, וממנף את תכונות שפת C/C++ המודרניות (כולל C++17), אופטימיזציות LLVM סטנדרטיות ותאימות עם GCC כדי לספק קבצים בינאריים בעלי ביצועים גבוהים בחומרת Power. משמעות הדבר היא שאתם מקבלים את היתרונות של המערכת האקולוגית של LLVM בתוספת אופטימיזציות מותאמות לפלטפורמה שפותחו על ידי IBM.

עבור סביבות עבודה מדור קודם, IBM עדיין מספקת את מהדרי XL C/C++ הישנים יותר עבור לינוקס , כך שארגונים עם שרשראות בנייה קיימות או אילוצי הסמכה יכולים להמשיך להשתמש בהם תוך אימוץ הדרגתי של Open XL C/C++ עבור עומסי עבודה חדשים יותר.

הגדרת למידה קלאסית: GCC ו-IDEs קלים משקל

אם אתם רק מתחילים עם C או C++ בלינוקס, הגדרה נפוצה ויעילה מאוד היא GCC בתוספת IDE קל משקל כמו Geany. Geany הוא חוצה פלטפורמות (לינוקס ו-Windows), מהיר, ומשלב תכונות בסיסיות כמו ניהול פרויקטים, פקודות בנייה וניפוי שגיאות פשוט ללא התקורה של IDEs כבדים לחלוטין.

קורסי C/C++ רבים וארוכים עבור לינוקס ממליצים בדיוק על השילוב הזה: GCC כמהדר ו-Geany כסביבת פיתוח. באמצעות הדרכות כאלה, בדרך כלל לומדים את השפה מהיסוד: מהו מהדר GNU וכיצד להפעיל אותו, כיצד לבנות תוכנית, כיצד לעבוד עם תנאים, פונקציות, מערכים, מחרוזות, מצביעים, מבנים, איגודים, קלט/פלט של קבצים ובסופו של דבר מושגים מונחי-עצמים כמו ירושה, עומס יתר של אופרטורים ופולימורפיזם ב-C++.

בעוד שאפשרויות ה-IDE משתנות, העצות הבסיסיות של שרשרת הכלים נוטות להיות עקביות: השתמשו ב-GCC (או g++) בפלטפורמות שונות ככל האפשר. בלינוקס זוהי ברירת המחדל; ב-Windows ו-macOS ניתן להתקין את GCC דרך MinGW, MSYS2, WSL, Homebrew או כלים דומים, תוך שמירה על זרימת עבודה אחידה בין מערכות ושיתוף קל יותר של סקריפטים ו-Makefiles.

אפילו כאשר IDE ממחק את שלבי הבנייה, הבנה שהוא פשוט קורא gcc or g++ מאחורי הקלעים הוא קריטי לאיתור ניפוי בעיות מורכבות של בנייה או זמן ריצה. אפשרויות כמו -g עבור מידע על ניפוי באגים, רמות אופטימיזציה כמו -O0, -O2 or -O3ודגלים כדי להתאים אזהרות או תאימות לתקנים (-Wall, -std=c++17וכו') כולם חשובים מאוד בעת אבחון באגים עדינים.

ניפוי באגים בבסיסי קוד גדולים ב-C++: מקוד VS ל-GDB מקורי

מפתחים שעוברים מ-Visual Studio ב-Windows ללינוקס מתחילים לעתים קרובות עם Visual Studio Code בתוספת הרחבה מבוססת GDB ומבחינים במהירות שההפעלת ניפוי הבאגים יכולה להיות איטית להחריד במערכות קצה גדולות. זה לא בלתי נתפס שיש עיכובים של 30-60 שניות בכל שלב בעת ניפוי באגים במערכות עיבוד או מסירה גדולות עם מאות אלפי שורות ורכיבי קצה רבים.

חוויה איטית זו בדרך כלל אינה מגבלה של GDB עצמו, אלא של שכבת האינטגרציה או התצורה בין קוד VS לבין ניפוי השגיאות הבסיסי. בעיות בהרחבת ניפוי השגיאות, באופן שבו נקודות עצירה מסונכרנות, באופן שבו מידע סמלים נטען וכיצד פקודות MI (ממשק מכונה) מתורגמות, כל אלה יכולים לתרום להאטות משמעותיות ביישומים מורכבים בעולם האמיתי.

ישנן בעיות ידועות ארוכות שנים שדווחו בהרחבת VS Code C/C++ הקשורות לביצועי Stepping עם GDB בלינוקס. עבור חלק מהצוותים, משמעות הדבר היא ש-VS Code מצוין כעורך אך לא בהכרח האפשרות המהירה ביותר כממשק קצה לאיתור שגיאות בשירותי C++ מפלצתיים; קיימות חלופות כמו Google Antigravity IDE ו-IDEs מקוריים. כאשר הביצועים קריטיים, מהנדסים רבים נוטים להשתמש ב-GDB ישירות או לעבור ל-IDE מקורי המשולב בצורה עמוקה יותר עם שרשרת הכלים המקומית.

לכן, אם אתם מגלים שכל שלב בסשן ניפוי השגיאות VS Code שלכם בלינוקס לוקח חצי דקה, אל תניחו שניפוי השגיאות בלינוקס הוא מטבעו כל כך איטי. לפני שאתם מוותרים, כדאי לבדוק את GDB בטרמינל ישירות על אותו קובץ בינארי ולהשוות את ההתנהגות. לעתים קרובות, הכניסה לתוך GDB מהירה משמעותית, מה שמצביע על צוואר בקבוק בתצורה או בהרחבה ולא על בעיה בסיסית במערכת ההפעלה או במהדר.

בסביבות C++ גדולות בלינוקס, חלופות פופולריות לניפוי שגיאות נוח כוללות Eclipse with CDT (C/C++ Development Tooling), CLion, Qt Creator, KDevelop ומערכות פיתוח מקוריות אחרות שמשתלבות בצורה הדוקה יותר עם GDB והמערכת המקומית. סביבות אלו יכולות לספק ניווט בקוד המקור, חלונות צפייה ונקודות עצירה עשירות תוך שימוש ב-GDB ללא התקורה של שכבות ניפוי שגיאות שאינן תלויות בשפה.

מידע על ניפוי באגים בלינוקס: ELF, DWARF, debuginfo ו-debugsource

בלינוקס, תוכניות מהודרות וספריות משותפות מאוחסנות בדרך כלל בקבצי ELF (פורמט Executable and Linkable), ומידע ניפוי השגיאות המשויך אליהן מקודד בפורמט DWARF. DWARF מכיל את המטא-דאטה שמאגרי הבאגים צריכים כדי למפות קוד מכונה חזרה לקבצי מקור, מספרי שורות, פונקציות, סוגים ומשתנים.

ניתן לבדוק את מקטעי הגמדים בקובץ בינארי של ELF בעזרת כלים כמו readelf -w file, אשר מוחק את רשומות ניפוי השגיאות הגולמיות. למרות שבדרך כלל לא קוראים את DWARF באופן ידני, זה מאשר האם קיימים מידע על ניפוי שגיאות ויכול להיות בעל ערך רב לאבחון בעיות מסוג "לא נטענו סמלים" ב-GDB או בכלים אחרים.

פורמט ניפוי שגיאות ישן יותר בשם STABS עדיין קיים אך נחשב מיושן ולא מומלץ בהפצות לינוקס מודרניות כמו Red Hat Enterprise Linux. GCC ו-GDB מספקים תמיכה במאמץ הטוב ביותר עבור STABS, אך כלים מרכזיים במערכת האקולוגית (לדוגמה Valgrind או elfutils) עשויים לא לעבוד כהלכה איתו, ולכן DWARF מומלץ מאוד.

מכיוון שנתוני ניפוי שגיאות נוטים להיות גדולים, רוב ההפצות מפצלות אותם מהקבצים הבינאריים העיקריים לחבילות debuginfo ו-debugsource נפרדות. קובץ ההפעלה שאתה מתקין ממאגר ברירת המחדל בדרך כלל מוסר מסמלי ניפוי השגיאות שלו כדי לחסוך במקום דיסק ולהפחית את שטח הזיכרון, בעוד שחבילת debuginfo המתאימה מכילה את נתוני ה-DWARF, ובאופן אופציונלי, debugsource כולל את קוד המקור התואמים.

במערכות RHEL ומערכות דומות, אתה מבקש במפורש מידע על ניפוי שגיאות בזמן הקומפילציה באמצעות -g בעת בניית פרויקטים משלך עם GCC. עבור ספריות מערכת וספריות צד שלישי שהותקנו מחבילות, ניתן להשיג את המידע הרלוונטי debuginfo ו debugsource חבילות ממאגרי ניפוי שגיאות ייעודיים, שלעתים קרובות רמזו ישירות על ידי GDB כאשר הוא מבחין בסמלים חסרים במהלך סשן ניפוי שגיאות.

התקנה ואיתור debuginfo עבור קבצים בינאריים של המערכת

כשאתה מנפה באגים בתוכניות C או C++ שתלויות בספריות מערכת, התקנת debuginfo עבור ספריות אלו יכולה לעשות הבדל משמעותי באיכות המעקבים האחוריים ובדיקת המשתנים. בלעדיו, תראה רק כתובות גולמיות או שמות פונקציות מעוותים בספריות משותפות; בעזרתו, אתה מקבל מעקבי מחסנית מדויקים לפי שורה ושמות משתנים סמליים.

בהפצות דמויות RHEL, ה-GNU Debugger (GDB) יכול לזהות באופן אוטומטי מתי חסר מידע ניפוי שגיאות עבור אובייקט טעון ולהציע פקודה קונקרטית להתקנת ה... debuginfo חבילה דרך dnf. אתה פשוט מפעיל את המומלץ dnf debuginfo-install ... פקודה, אשר כאשר תתבקש, והמערכת תאחזר ותתקין את חבילות הסמלים הנדרשות עבור ההפעלה שלך.

אם רמזים אוטומטיים אינם זמינים, ניתן לזהות ידנית את מידע ניפוי הבאגים הנדרש על ידי איתור קובץ הבינארי או קובץ הספרייה באמצעות כלים כגון locate ולאחר מכן לבצע שאילתה במסד הנתונים של RPM. השמיים locate הפקודה מגיעה מ- mlocate package, שאותה ייתכן שתצטרך להתקין ולאתחל, וברגע שיהיה לך את הנתיב, תוכל לשאול איזו חבילה היא הבעלים ולאחר מכן להתקין את גרסת debuginfo המתאימה.

ישנם מצבים בהם לא ניתן לקבוע את החבילה שהתקינה קובץ בינארי נתון, לדוגמה כאשר הקובץ הועתק ידנית או נבנה במקום ללא אריזה. במקרים אלה, ייתכן שתצטרך לחזור לקבצי סמלים מותאמים אישית או, אם אפשר, לבנות מחדש את הקובץ הבינארי בעצמך באמצעות -g מופעל כך של-GDB יהיו נתוני ניפוי שגיאות מלאים.

זכרו שהתקנת debuginfo עבור כל ספרייה במערכת היא לעיתים רחוקות הכרחית ויכולה להיות בזבזנית. התמקדו במודולים הרלוונטיים ביותר לבעיה שלכם: הקבצים הבינאריים של האפליקציה והספריות הספציפיות שמהן נובעת הקריסה או ההתנהגות השגויה, במקום למשוך חבילות ניפוי שגיאות עבור כל מערכת ההפעלה.

שימוש ב-GDB לצורך ניפוי שגיאות אינטראקטיבי בלינוקס

GDB הוא הכלי המרכזי לאיתור שגיאות ביישומי C ו-C++ מקוריים בלינוקס, וחושף הן ממשק שורת פקודה והן, באמצעות אינטגרציות, חזיתות גרפיות כמו Eclipse CDT. ב-Red Hat Enterprise Linux, ההפצה הסטנדרטית כוללת את GDB המלא יחד עם ממשקי משתמש גרפיים אופציונליים.

כדי לאתר באגים בתוכנית מההתחלה, בדרך כלל מפעילים את gdb ./program, קבע את ההגדרה של נקודות עצירה לפי הצורך, ולאחר מכן הפעל את הביצוע בתוך GDB עם ה- run פקודה. לחלופין, ניתן להתחבר לתוכנית שכבר פועלת עם gdb -p <pid> או על ידי הפעלת GDB ושימוש ב- attach הפקודה יחד עם מזהה התהליך.

אם GDB אינו יכול להסיק את קובץ היעד להרצה עבור PID נתון במהלך ההצמדה, ניתן לציין לו במפורש באיזה קובץ בינארי להשתמש דרך file פקודה ולאחר מכן המשך בניפוי שגיאות. זה שימושי במיוחד כשאתה מתמודד עם משגרים מותאמים אישית, סקריפטים של עטיפת קבצים או הגדרות מרובות קבצים בינאריים שבהם נתיב ההפעלה בפועל אינו ברור.

לאחר החיבור או ההשקה, ניתן לשלוט בזרימת התוכנית באמצעות פקודות כמו n (הַבָּא), s (שָׁלָב), until, finish ופשוט c (המשך), תוך כדי סגירת ניפוי הבאגים עם q כאשר נעשה. לכל אחת מהפקודות הללו יש סמנטיקה ספציפית לגבי האם היא נכנסת לגוף הפונקציה, פועלת עד שורה נתונה או מחדשת את הביצוע עד לנקודת העצירה או הסיום הבאים.

להבנת מצב, GDB מספק פקודות אינטרוספקטיבה עשירות לבדיקת משתנים, מחסניות קריאה, אוגרים ועוד, וגם מציע עזרה הקשרית באמצעות help info ופקודות דומות. ניתן להציג את שורת המקור הנוכחית באמצעות list, הדפס משתנים עם print, חקור מסגרות מחסנית עם backtrace ולנווט במסגרות עם frame, up ו down.

נקודות עצירה, נקודות מעקב ותנאים ב-GDB

בניפוי שגיאות בעולם האמיתי, כמעט אף פעם לא יוצאים בעיוורון מ... main()במקום זאת, אתם ממקמים אסטרטגית נקודות עצירה כדי לעצור את התוכנית בדיוק במקומות שבהם ההתנהגות הופכת למעניינת. הפקודה הסטנדרטית break מאפשר לך להגדיר נקודות עצירה לפי מספר קובץ ושורה או לפי שם פונקציה, ו-GDB יעצור את הביצוע בפגיעה הבאה.

לדוגמה, ניתן להגדיר נקודת עצירה בשורת מקור ספציפית באמצעות תחביר כגון break file.cpp:123, או הפסקה בתחילת פונקציה עם break my_function. כאשר מגיעים לנקודת העצירה, GDB עוצר את התוכנית, ומאפשר לך לבדוק משתנים מקומיים, לבדוק את מחסנית הקריאות ולהחליט אם להיכנס, לעבור או להמשיך.

נקודות עצירה מותנות הן בעלות ערך רב כאשר באג מופיע רק לאחר איטרציות רבות או תחת ערכי קלט ספציפיים. ניתן לשייך תנאי בוליאני שנכתב ב-C או C++ לנקודת עצירה כך ש-GDB יפסיק רק כאשר התנאי מוערך כ-true, ובכך להפחית באופן דרמטי עצירות מיותרות ולהפוך לולאות ניפוי שגיאות או מכונות מצב מורכבות ליעילות הרבה יותר.

כדי לנטר שינויים בנתונים ולא בזרימת הקוד, GDB מציע נקודות מעקב, אשר מופעלות כאשר ביטוי (לעתים קרובות משתנה) נקרא או נכתב אליו. עם פקודות כמו watch, rwatch (לקרוא) או awatch (קריאה/כתיבה), ניתן לעצור את הביצוע בדיוק כאשר שדה מסוים משתנה או נגיש, דבר מועיל במיוחד במעקב אחר שינויים בלתי צפויים במצב.

אתה מנהל את כל נקודות העצירה ונקודות המעקב באמצעות פקודות כגון info breakpoints or info br, וניתן למחוק לפי מספר או לפי מיקום באמצעות delete עם טיעונים מתאימים. זה מקל על שמירה על קבוצה נקייה של נקודות עצירה פעילות ומניעת בלבול בעת ניפוי שגיאות במודולים או סשנים מרובים.

ניפוי באגים בתהליכים מרובי-הליכים ופורקים

ניפוי באגים בתוכניות C ו-C++ שעושות שימוש נרחב ב-threads או forks דורש מודעות נוספת לאופן שבו GDB עוקב אחר הקשרים של ביצוע. כברירת מחדל, GDB מציין רצף נוכחי ורוב הפקודות פועלות על רצף זה אלא אם כן אתה עובר במפורש באמצעות thread ומזהה השרשור.

כאשר התוכנית שלך מתפצלת, ההגדרה set detach-on-fork קובע האם GDB עוקב אחר הצאצא או ההורה וכיצד הוא מטפל בתהליך שאינו עוקב. ניתן להגדיר את GDB כך שישמור על שליטה בשניהם או שיתנתק אוטומטית מאחד הצדדים, תלוי אם ההורה, הצאצא או שניהם רלוונטיים לניתוח שלך.

גרסאות חדשות יותר של GDB פיתחו את אופן המספור של הליכים, והכניסו מזהה הליך נחות לכל הליך יחד עם מזהה הליך גלובלי נפרד לצורך תאימות. משתנה הנוחות $_thread ו-API של פייתון InferiorThread.num כעת משקף מספור לפי נחות, בעוד שהמזהה הגלובלי זמין דרך $_gthread ו InferiorThread.global_num, תוך הבטחה שכלים ישנים יותר המבוססים על מזהים גלובליים ימשיכו לפעול.

טיפול באותות בניפוי שגיאות מרובה-הליכי משנה שופר גם הוא כך שאותות תמיד מועברים לתהליך הנכון. אם משנים תהליך לאחר שאות עוצר את התוכנית ואז מנסים להמשיך, GDB יכול לבקש אישור, ובכך למנוע מסירה שגויה בשוגג ולהפוך את ניפוי השגיאות הקשור לאות לאמינים יותר.

כל זה אומר שכאשר מנתחים קיפאון, מרוצים או קריסות מוזרות המופעלות על ידי אותות, ניתן לסמוך על מודל ה-thread של GDB כדי לעקוב אחר נתיב הביצוע הנכון עם שליטה מדויקת. בשילוב עם נקודות עצירה, נקודות מעקב ונקודות תפיסה, זה מאפשר ניפוי שגיאות רב-הליך חזק אפילו בשירותי C++ בו זמנית מאוד.

קריאות למערכת מעקב ולספרייה: strace, ltrace ו-SystemTap

לפעמים הדרך המהירה ביותר להבין מדוע תוכנית C או C++ מתנהגת בצורה לא נכונה היא לא לעבור על כל שורה, אלא להתבונן כיצד היא מקיימת אינטראקציה עם מערכת ההפעלה והספריות המשותפות שלה. לינוקס מציעה מספר כלים רבי עוצמה לכך: strace, ltrace, SystemTap ואפילו GDB עצמו באמצעות נקודות זיהוי מיוחדות.

השמיים strace קריאות מערכת של מעקב אחר כלי שירות - אינטראקציות עם הליבה כגון open, read, write, mmap, execve וכן הלאה - יחד עם הפרמטרים וערכי ההחזרה שלהם. אתה יכול להריץ את התוכנית שלך דרך strace או לצרף לתהליך פעיל באמצעות PID, תוך סינון אופציונלי של אילו קריאות סיסמה להציג באמצעות ביטויים כמו -e trace=call ושליטה האם לעקוב אחר ילדים מפוצלים או משורשרים עם -f.

מכיוון שיישומים אמיתיים מבצעים מספר עצום של קריאות מערכת, המשלבות strace עם כלי מעטפת כמו tee נפוץ הן לצפות בפלט בזמן אמת והן לאחסן אותו לצורך ניתוח. זה עוזר לך לזהות קבצים חסרים, בעיות הרשאות, התנהגות רשת בלתי צפויה או בעיות אחרות ברמת מערכת ההפעלה שאולי אינן ברורות מהקוד עצמו.

משלים סטראס, ltrace מתמקד בקריאות לפונקציות של ספרייה משותפת במרחב המשתמש, ומציג קריאות וערכי החזרה עבור פונקציות מיוצאות מאובייקטים דינמיים. ב-RHEL 8 קיימת מגבלה ידועה שבה ltrace אינו יכול לעקוב אחר קבצי הרצה מסוימים של המערכת, אך הוא פועל כרגיל עבור קבצים בינאריים שנבנו על ידי המשתמש, מה שהופך אותו לכלי בעל ערך להבנת האופן שבו התוכנית שלך משתמשת בממשקי API של ספריות.

SystemTap היא מסגרת מעקב מתקדמת יותר המאפשרת מטפלי אירועים מותאמים אישית עבור אירועי ליבה ואירועי משתמש באמצעות שפת סקריפטים משלה. השימוש בו יכול להיות מורכב יותר מאשר strace או ltrace, אך הוא יכול להרחיב את עצמו בצורה טובה יותר ותומך בסינון וצבירה מתוחכמים. לנוחיותכם, סקריפט לדוגמה בשם strace.stp מגיע עם SystemTap כדי לחקות התנהגות דמוית strace באמצעות התשתית של SystemTap.

GDB עצמו יכול להשתתף במעקב באמצעות נקודות זיהוי עבור קריאות סיסטמיות ואותות, באמצעות פקודות כמו catch syscall ו catch signal. אלה גורמים לניפוי שגיאות להפסיק את הביצוע בכל פעם שהתוכנית מבצעת קריאות מערכת מסוימות או מקבלת אותות מסוימים, דבר שיכול להיות שימושי מאוד כאשר אתה זקוק לשליטה מדויקת במהלך ניפוי שגיאות אינטראקטיבי.

עיבוד שבבי ליבה וניפוי שגיאות לאחר המוות עם GDB

כאשר יישום C או C++ קורס או נתקע בצורה שקשה לשחזר באופן אינטראקטיבי, core dumps מספקים תמונה של הזיכרון והמצב שלו ברגע הקריטי. core dump הוא קובץ ELF המכיל את התוכן של חלקים מזיכרון התהליך (stack, heap, mappings) בסיום התהליך, שאותו ניתן לנתח מאוחר יותר עם GDB כאילו היית מחובר בזמן הקריסה.

כדי להשתמש בקבצי ליבה ביעילות, עליך לוודא שהם נוצרים בפועל ואינם חסומים על ידי מגבלות משאבים או תצורה. מגבלות מעטפת כגון ulimit -c יכול למנוע יצירת קבצי ליבה; הגדרת המגבלה ל unlimited מסיר מגבלות גודל, אם כי כדאי לבדוק את ההשלכות של שטח דיסק במערכות ייצור.

במערכות RHEL מודרניות, systemd-coredump מנהל את מטמי הליבה בצורה שקופה ומאחסן אותם במיקום מרכזי דמוי יומן במקום להשאיר core קבצים הפזורים בין ספריות. השמיים coredumpctl הכלי מאפשר לך לרשום קריסות שתועדו, לבדוק את המטא-דאטה שלהן ולייצא את קובץ הליבה בפועל לנתיב נבחר לצורך ניתוח מעמיק יותר.

בעת יצירת תהליך עבודה שיטתי של לכידת קריסות, מקובל להתקין את sos אריזה ושימוש sosreport כדי ליצור קובץ tarball עם תצורת מערכת ויומני רישום. בשילוב עם קובץ הליבה המיוצא וקבצי הבינארי של היישום, זה נותן לך את כל מה שצריך כדי לנתח קריסות במחשב נפרד או להעביר אותן לצוות או לספק אחר.

ניתן אפילו להפעיל במכוון core dump עבור תהליך שאינו מגיב על ידי שליחת אות ביטול או שימוש בכלים כמו gcore, אשר משמידים את זיכרון התהליך בזמן שהוא עדיין פועל. במהלך gcore dump, התהליך מושהה לזמן קצר, ולאחר מכן חוזר לביצוע רגיל, מה שמאפשר ניתוח לא מקוון של מצב בעייתי מבלי לסיים לחלוטין את השירות.

מציאת קובץ ההפעלה והסמלים הנכונים לניתוח ליבה

כדי לנתח קובץ core dump בצורה משמעותית, GDB זקוק הן לקובץ הליבה והן לקובץ ההפעלה המדויק (בתוספת כל ספריות משותפות רלוונטיות) שיצרו אותו. זה חשוב מכיוון שקבצים בינאריים לא תואמים - שנבנו מגירסאות שונות - עלולים להוביל למעקבים לאחור מטעים ולפריסות משתנים שגויות.

כלים כמו coredumpctl info הצג מטא-דאטה מפורטות עבור כל ליבה שנלכדה, כולל הנתיב לקובץ ההפעלה הראשי ומזהה בנייה המזהה באופן ייחודי את הקובץ הבינארי. מזהה הבנייה עשוי להיראות כמו גיבוב הקסדצימלי ארוך, וניתן להשוות אותו למזהה הבנייה של העותק המקומי שלך של הקובץ הבינארי כדי לוודא שהם זהים לפני הפעלת GDB.

אם קובץ ההפעלה והספריות שלו הגיעו מחבילות RPM, ניתן להשתמש sosreport ומסד הנתונים של החבילות כדי לאחזר את הגרסאות המדויקות הנדרשות. במקרים מסוימים, ניתן אפילו להתקין מחדש את החבילות התואמות במחשב ניפוי שגיאות ייעודי ולאחר מכן להשתמש ב-GDB. set sysroot תצורה כדי לכוון אותו לפריסת ספרייה משוקפת עבור ניפוי שגיאות בסגנון מרחוק.

לאחר שיהיו לך האובייקטים הנכונים, אתה מתחיל סשן GDB עם פקודה כגון gdb /path/to/exe /path/to/core ותן ל-GDB לטעון את הליבה. אם חסר debuginfo עבור מודולים כלשהם, GDB יציג הודעות שירמזו על אילו חבילות או קבצי סמלים עליך להתקין כדי לקבל נראות מלאה של הסמלים.

אם סמלי ניפוי השגיאות של היישום שלך מסופקים בקבצים נפרדים ולא דרך חבילות, תוכל לטעון אותם במפורש באמצעות symbol-file פקודה בתוך GDB. אינך מחויב שיהיה לך מידע ניפוי שגיאות עבור כל ספרייה משותפת בליבת המערכת; התמקדות באפליקציה שלך ובספריות החשודות בדרך כלל מספיקה כדי לשחזר את המחסנית והמצב הרלוונטיים.

בעת ניתוח קובץ core dump, זכרו שפקודות לשליטה בביצוע התוכנית (כגון step או continue) כבר אינן הגיוניות, מכיוון שאין תהליך חי מצורף. במקום זאת, אתם מסתמכים על פקודות בדיקה - בדיקת מסגרות stack, משתנים מקומיים וגלובליים, אזורי זיכרון והליכי משנה - כדי להסיק מדוע התרחשה הקריסה או היכן התוכנית נתקעה.

תרחישי זיכרון מתקדמים ושינויי GDB ב-RHEL מודרני

יישומים מסוימים בעלי אבטחה גבוהה או ביצועים גבוהים מסמנים חלקים מהזיכרון שלהם כלא ניתנים ל-dump באמצעות דגלים כגון VM_DONTDUMP, אשר מונע כתיבה של זיכרון זה לקבצי ליבה. זה מגן על נתונים רגישים (לדוגמה, מפתחות קריפטוגרפיים או רשומות פיננסיות) ומקטין את גודלי ה-dump, אך מקשה על ניתוח מלא במצב לא מקוון.

אם יש לך צורך עז ללכוד הכל - כולל אזורים שבדרך כלל אינם כלולים ב-dumps - תוכל להגדיר את GDB להתעלם מדגל non-dump ולאלץ dump זיכרון מקיף. GDB מספק אפשרויות לעקיפה VM_DONTDUMP ולזרוק את כל זיכרון התהליך לקובץ ליבה לצורך זיהוי פלילי או ניפוי שגיאות עמוק.

בצד הכלים, גרסת ה-GDB שמגיעה עם RHEL 8 מציגה מספר שינויים שבירים והתנהגותיים בהשוואה ל-RHEL 7, במיוחד בתחומים שבהם אנשים נהגו לנתח את פלט הטרמינל. במקום לגרוד פלט טקסטואלי, רד האט ממליצה לכתוב סקריפטים באמצעות Python API של GDB או פרוטוקול Machine Interface (MI), ששניהם מיועדים לצריכה תכנותית.

שינויים בולטים כוללים הפעלת שרתים נחותים של GDBserver דרך מעטפת כדי לאפשר הרחבת ארגומנטים, הסרת תמיכה ב-GCJ (Java), תחביר מעודכן לפקודות תחזוקה של symbol-dump והתאמות בטיפול ב-sysroot כדי לתמוך טוב יותר בניפוי שגיאות מרחוק. פקודות ומצבים מסוימים, כגון תאימות HP-UX XDB ו- remotebaud, הוצאו משימוש או הוחלפו במקבילות גנריות יותר כמו set serial baud.

בנוסף, GDB הציגה מגבלות כמו max-value-size כדי למנוע הקצאת זיכרון בלתי מוגבלת בעת הדפסת ערכים גדולים מאוד, שינו את אופן השליטה בגודל היסטוריית הפקודות באמצעות GDBHISTSIZE במקום HISTSIZE, והוסיפו הגבלה על מועמדים להשלמת קורס באמצעות set max-completions. אמצעי הגנה אלה מסייעים במניעת הקפאות או צריכת זיכרון מוגזמת בעת איתור באגים של תוכניות פתולוגיות או פגומות.

התוצאה הסופית עבור מפתחי C ו-C++ בלינוקס היא ניפוי באגים חזק יותר וניתן לסקריפטים, אשר ניתן להרחבה לבסיסי קוד ענקיים ותרחישי כשל מוזרים, בתנאי שאתם מודעים לפקודות ולכפתורי התצורה המעודכנים. בשילוב עם תשתיות מהדר מודרניות כמו GCC ו-Clang/LLVM (והצעות כמו IBM Open XL C/C++ ב-Power), GDB מהווה את עמוד השדרה של שרשרת כלים עוצמתית לפיתוח ופתרון בעיות של תוכנות מקוריות מורכבות בלינוקס.

בחירת המהדר וה-IDE הנכונים, הפעלת מידע ניפוי שגיאות DWARF והתקנת חבילות debuginfo, ומינוף זרימות עבודה של GDB, strace, ltrace, SystemTap ו-core-dump נותנות לכם סביבת C/C++ בלינוקס שהיא מהירה, שקופה ומתאימה לשרתים האחוריים הגדולים ביותר, גם אם הרושם הראשוני שלכם הגיע מסשן ניפוי שגיאות איטי של VS Code. עם תצורה נכונה ומודעות לכלים הזמינים, ניפוי שגיאות בלינוקס לא רק משתווה לנוחות של Visual Studio ב-Windows; בתרחישים רבים, זה למעשה נותן לכם שליטה עדינה יותר וראות עמוקה יותר לגבי האופן שבו יישומי C ו-C++ שלכם באמת מתנהגים.