1
00:00:00,000 --> 00:00:02,000
[Powered by Google Translate] [Valgrind]

2
00:00:02,000 --> 00:00:05,000
[נייט Hardison, אוניברסיטת הרווארד]

3
00:00:05,000 --> 00:00:07,000
זה CS50, CS50.TV]

4
00:00:07,000 --> 00:00:10,000
חלק מהבאגים הקשים ביותר בתוכניות C

5
00:00:10,000 --> 00:00:13,000
באו מהניהול הכושל של זיכרון.

6
00:00:13,000 --> 00:00:15,000
יש מספר עצום של דרכים לתפשל,

7
00:00:15,000 --> 00:00:17,000
כולל הקצאת הכמות הנכונה של זיכרון,

8
00:00:17,000 --> 00:00:20,000
שוכח לאתחל משתנה,

9
00:00:20,000 --> 00:00:23,000
כתיבה לפני או אחרי סוף החיץ,

10
00:00:23,000 --> 00:00:25,000
ולשחרר לשמור זמני זיכרון מרובים.

11
00:00:25,000 --> 00:00:28,000
הסימפטומים נעים בין קריסות לסירוגין

12
00:00:28,000 --> 00:00:30,000
לערכים מסתוריים נדרסו,

13
00:00:30,000 --> 00:00:34,000
לעתים קרובות במקומות ובזמנים רחוקים מאוד מטעות המקורית.

14
00:00:34,000 --> 00:00:37,000
לאתר את הבעיה שנצפתה בחזרה לשורש הבסיסי

15
00:00:37,000 --> 00:00:39,000
יכול להיות מאתגר,

16
00:00:39,000 --> 00:00:42,000
אבל למרבה המזל, יש תכנית בשם מועילה Valgrind

17
00:00:42,000 --> 00:00:44,000
שיכול לעשות הרבה כדי לעזור.

18
00:00:44,000 --> 00:00:47,000
>> אתה מפעיל תכנית תחת Valgrind כדי לאפשר

19
00:00:47,000 --> 00:00:50,000
בדיקה מקיפה של הקצאות ומקבלת גישה לזכרון ערימה.

20
00:00:50,000 --> 00:00:53,000
כאשר Valgrind מזהה בעיה, זה נותן לך באופן מיידי,

21
00:00:53,000 --> 00:00:56,000
מידע ישיר שמאפשר לך

22
00:00:56,000 --> 00:00:58,000
בקלות רבה יותר לאתר ולפתור את הבעיה.

23
00:00:58,000 --> 00:01:01,000
Valgrind גם דיווחים על בעיות זיכרון פחות קטלניות,

24
00:01:01,000 --> 00:01:04,000
כגון דליפות זיכרון, הקצאת זכרון ערימה,

25
00:01:04,000 --> 00:01:07,000
ושוכח לשחרר אותו.

26
00:01:07,000 --> 00:01:10,000
רוצה המהדר, קלאנג, בבאגים שלנו, GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind הוא תוכנה חופשיה, והוא מותקן על המכשיר.

28
00:01:14,000 --> 00:01:16,000
Valgrind פועל על ההפעלה בינארי שלך,

29
00:01:16,000 --> 00:01:20,000
לא. קבצי קוד מקור h. ג שלך או,

30
00:01:20,000 --> 00:01:23,000
כדי להיות בטוח שיש לך הידור עותק עד למועד התכנית שלך

31
00:01:23,000 --> 00:01:25,000
באמצעות קלאנג או הצע.

32
00:01:25,000 --> 00:01:28,000
ואז, להפעיל את התכנית תחת Valgrind יכול להיות

33
00:01:28,000 --> 00:01:32,000
פשוט כמו סתם קידומת פקודת התכנית הסטנדרטית עם המילה Valgrind,

34
00:01:32,000 --> 00:01:35,000
אשר מתחיל את Valgrind ומריץ את התוכנה הפנימית שלו.

35
00:01:35,000 --> 00:01:38,000
כאשר מתחילים, Valgrind עושה קצת מורכב

36
00:01:38,000 --> 00:01:41,000
הניע להגדיר הפעלה עבור בדיקות הזיכרון,

37
00:01:41,000 --> 00:01:44,000
כך שזה יכול לקחת קצת לקום ולפעול.

38
00:01:44,000 --> 00:01:48,000
התכנית לאחר מכן לבצע בדרך כלל, תהיה זה הרבה יותר לאט,

39
00:01:48,000 --> 00:01:52,000
וכאשר היא מסתיימת, Valgrind יודפס סיכום של השימוש בזיכרון שלו.

40
00:01:52,000 --> 00:01:58,000
אם הכל ילך כשורה, זה ייראה בערך כך:

41
00:01:58,000 --> 00:02:01,000
במקרה זה,. / Clean_program

42
00:02:01,000 --> 00:02:04,000
היא הדרך לתכנית אני רוצה להריץ.

43
00:02:04,000 --> 00:02:06,000
ובזמן שזה לא לוקח כל ויכוחים

44
00:02:06,000 --> 00:02:09,000
אם זה לא הייתי רק טקטיקתם לסוף הפקודה כרגיל.

45
00:02:09,000 --> 00:02:12,000
תכנית נקיה היא רק תכנית קטנה וטיפשית שנוצרתי

46
00:02:12,000 --> 00:02:15,000
שמקצה מקום לבלוק של ints בערמה,

47
00:02:15,000 --> 00:02:19,000
לשים כמה ערכים בתוכם, ומשחרר את כל אגף.

48
00:02:19,000 --> 00:02:23,000
זה מה שאתה יורה ל, ללא שגיאות וללא הדלפות.

49
00:02:23,000 --> 00:02:27,000
>> מדד חשוב נוסף הוא המספר הכולל של בתים שהוקצו.

50
00:02:27,000 --> 00:02:32,000
בהתאם לתכנית, אם ההקצאות שלך הן במגה ומעלה,

51
00:02:32,000 --> 00:02:34,000
אתה כנראה עושה משהו לא בסדר.

52
00:02:34,000 --> 00:02:37,000
האם אתה צורך אחסון עותקים?

53
00:02:37,000 --> 00:02:40,000
האם אתה משתמש בערימה לאחסון, כאשר זה יהיה יותר טוב להשתמש במחסנית?

54
00:02:40,000 --> 00:02:43,000
אז, שגיאות זיכרון יכולות להיות באמת רעות.

55
00:02:43,000 --> 00:02:46,000
אלה גלויים יותר לגרום לקריסות מרהיבות,

56
00:02:46,000 --> 00:02:49,000
אבל גם אז הוא עדיין יכול להיות קשה לשים את האצבע

57
00:02:49,000 --> 00:02:51,000
מה בדיוק הוביל להתרסקות.

58
00:02:51,000 --> 00:02:54,000
יותר חתרנית, תכנית עם שגיאת זיכרון

59
00:02:54,000 --> 00:02:56,000
עדיין יכול לקמפל נקי

60
00:02:56,000 --> 00:02:58,000
ויכול עדיין נראה לעבוד כראוי

61
00:02:58,000 --> 00:03:01,000
בגלל שהצלחת לקבל מזל רוב הזמן.

62
00:03:01,000 --> 00:03:04,000
לאחר כמה "תוצאות מוצלחות",

63
00:03:04,000 --> 00:03:07,000
אתה יכול פשוט חושב שהתרסקות היא מקרית בהחלט של המחשב,

64
00:03:07,000 --> 00:03:10,000
אבל המחשב לא טועה אף פעם.

65
00:03:10,000 --> 00:03:13,000
>> ריצת Valgrind יכולה לעזור לך לאתר את הגורם לשגיאות זיכרון גלויות

66
00:03:13,000 --> 00:03:18,000
כמו גם למצוא אורבים טעויות אתה אפילו לא יודע עדיין עליו.

67
00:03:18,000 --> 00:03:22,000
בכל פעם Valgrind מזהה בעיה, הוא מדפיס את מידע על מה שנצפה.

68
00:03:22,000 --> 00:03:24,000
כל פריט הוא די תמציתי -

69
00:03:24,000 --> 00:03:27,000
שורת המקור של ההוראה הפוגע, מה הבעיה היא,

70
00:03:27,000 --> 00:03:30,000
וקצת מידע על הזיכרון המעורב -

71
00:03:30,000 --> 00:03:34,000
אבל לעתים קרובות זה מספיק מידע כדי להפנות את תשומת לבך למקום הנכון.

72
00:03:34,000 --> 00:03:37,000
הנה דוגמה של Valgrind פועלת על תכנית מרכבה

73
00:03:37,000 --> 00:03:40,000
שעושה קריאה לא חוקית של זכרון ערימה.

74
00:03:40,000 --> 00:03:49,000
אנחנו לא רואים שום שגיאות או אזהרות בהידור.

75
00:03:49,000 --> 00:03:53,000
אוי, סיכום השגיאה אומר שיש שתי טעויות -

76
00:03:53,000 --> 00:03:56,000
2 כניסות לא חוקיות בגודל 4 - בתים, כי הוא.

77
00:03:56,000 --> 00:04:01,000
שניהם הרעים קורא התרחש בפונקציה העיקרית של invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
הראשון על קו 16 והשני בקו 19.

79
00:04:04,000 --> 00:04:06,000
בואו נסתכל על הקוד.

80
00:04:06,000 --> 00:04:11,000
נראה כמו השיחה הראשונה printf למנסה לקרוא int 1 עבר סוף בלוק הזיכרון שלנו.

81
00:04:11,000 --> 00:04:13,000
אם אנחנו מסתכלים אחורה בתפוקה של Valgrind,

82
00:04:13,000 --> 00:04:16,000
אנו רואים שValgrind אמר לנו בדיוק את זה.

83
00:04:16,000 --> 00:04:19,000
הכתובת שאנחנו מנסים לקרוא מתחילה 0 בתים

84
00:04:19,000 --> 00:04:22,000
מעבר לקצה הבלוק בגודל 16 בתים -

85
00:04:22,000 --> 00:04:25,000
4 ints 32-bit שהוקצינו.

86
00:04:25,000 --> 00:04:29,000
כלומר, הכתובת היינו מנסה לקרוא מתחילה ממש בסוף של הבלוק שלנו,

87
00:04:29,000 --> 00:04:32,000
בדיוק כפי שאנו רואים בשיחת printf הרעה שלנו.

88
00:04:32,000 --> 00:04:36,000
עכשיו, לא חוקי כניסות אולי לא נראות כמו כל כך גדול של עסקה,

89
00:04:36,000 --> 00:04:39,000
אבל אם אתה משתמש בנתונים אלה כדי לשלוט בזרימה של התכנית שלך -

90
00:04:39,000 --> 00:04:42,000
לדוגמה, כחלק מאם הצהרה או לולאה -

91
00:04:42,000 --> 00:04:45,000
אז דברים בשקט יכולים להתקלקל.

92
00:04:45,000 --> 00:04:47,000
תראה איך אני יכול להפעיל את תכנית invalid_read

93
00:04:47,000 --> 00:04:50,000
ושום דבר יוצא דופן קורה.

94
00:04:50,000 --> 00:04:52,000
מפחיד, הא?

95
00:04:52,000 --> 00:04:56,000
>> עכשיו, בואו נסתכל על עוד כמה סוגים של טעויות שאתה עשוי להיתקל בקוד שלך,

96
00:04:56,000 --> 00:04:59,000
ואנחנו נראה איך Valgrind מזהה אותם.

97
00:04:59,000 --> 00:05:01,000
פשוט ראינו את דוגמה של invalid_read,

98
00:05:01,000 --> 00:05:04,000
אז עכשיו בואו נבדוק את invalid_write.

99
00:05:04,000 --> 00:05:09,000
שוב, ללא שגיאות או אזהרות בהידור.

100
00:05:09,000 --> 00:05:12,000
אוקיי, Valgrind אומר שיש שתי שגיאות בתכנית זו -

101
00:05:12,000 --> 00:05:15,000
וinvalid_write וinvalid_read.

102
00:05:15,000 --> 00:05:18,000
בואו לבדוק את הקוד הזה.

103
00:05:18,000 --> 00:05:21,000
נראה שיש לנו דוגמה של strlen הקלסיים בתוספת אג אחד.

104
00:05:21,000 --> 00:05:24,000
הקוד לא malloc ייט של שטח נוסף

105
00:05:24,000 --> 00:05:26,000
ל/ 0 אופי,

106
00:05:26,000 --> 00:05:30,000
לכן כאשר str עותק הלך לכתוב את זה בssubstrlen "cs50 סלעים!"

107
00:05:30,000 --> 00:05:33,000
זה כתב בית 1 עבר סוף הבלוק שלנו.

108
00:05:33,000 --> 00:05:36,000
Invalid_read מגיע כאשר אנו עושים קריאתנו לprintf.

109
00:05:36,000 --> 00:05:40,000
Printf מסתיים בקריאה לא חוקי לזיכרון כאשר הוא קורא את התו / 0

110
00:05:40,000 --> 00:05:43,000
כמו שזה נראה בסופו של המייתר הזה זה דפוס.

111
00:05:43,000 --> 00:05:45,000
אבל כל זה לא נמלט Valgrind.

112
00:05:45,000 --> 00:05:48,000
אנו רואים שזה תפס את invalid_write כחלק מעותק str

113
00:05:48,000 --> 00:05:51,000
על קו 11 של ראשי, וinvalid_read הוא חלק מprintf.

114
00:05:51,000 --> 00:05:54,000
רוק ב, Valgrind.

115
00:05:54,000 --> 00:05:57,000
שוב, זה אולי לא נראה כמו עניין גדול.

116
00:05:57,000 --> 00:06:00,000
אנחנו יכולים להפעיל את התכנית שוב ושוב מחוץ לValgrind

117
00:06:00,000 --> 00:06:03,000
ולא רואה שום סימפטומי שגיאה.

118
00:06:03,000 --> 00:06:06,000
>> עם זאת, בואו נסתכל על וריאציה קלה של זה כדי לראות

119
00:06:06,000 --> 00:06:09,000
איך דברים יכולים להיות ממש לא רעים.

120
00:06:09,000 --> 00:06:14,000
לכן, מובן מאליו, אנחנו מנצלים לרעה את הדברים יותר מאשר רק קצת בקוד זה.

121
00:06:14,000 --> 00:06:17,000
אנחנו רק הקצאת שטח על הערמה במשך שתי מחרוזות

122
00:06:17,000 --> 00:06:19,000
אורך cs50 סלעים,

123
00:06:19,000 --> 00:06:22,000
הפעם, נזכר בדמות / 0.

124
00:06:22,000 --> 00:06:25,000
אבל אז אנחנו זורקים במחרוזת ארוכה במיוחד לבלוק הזיכרון

125
00:06:25,000 --> 00:06:27,000
שS כדי להצביע.

126
00:06:27,000 --> 00:06:30,000
איזו השפעה תהיה לכך על בלוק הזיכרון שנקודתי T ל?

127
00:06:30,000 --> 00:06:34,000
ובכן, אם נקודתי T לזיכרון, שרק בסמוך לS,

128
00:06:34,000 --> 00:06:37,000
מגיע רק אחרי זה,

129
00:06:37,000 --> 00:06:39,000
אז אולי כתבתי על חלק ט

130
00:06:39,000 --> 00:06:41,000
בואו להפעיל את הקוד הזה.

131
00:06:41,000 --> 00:06:43,000
תראה מה קרה.

132
00:06:43,000 --> 00:06:47,000
מייתרינו מאוחסנים בערמתנו ששני נראה היה שהודפסו בצורה נכונה.

133
00:06:47,000 --> 00:06:49,000
שום דבר לא נראה רע בכלל.

134
00:06:49,000 --> 00:06:52,000
עם זאת, בואו נחזור לקוד שלנו ו

135
00:06:52,000 --> 00:06:55,000
הערה את הקו שבו אנחנו להעתיק cs50 סלעים

136
00:06:55,000 --> 00:06:59,000
לבלוק הזיכרון השני, הצביע על ידי לא.

137
00:06:59,000 --> 00:07:02,000
כעת, כאשר אנו מפעילים את הקוד הזה אנחנו צריכים

138
00:07:02,000 --> 00:07:06,000
רואה רק את התוכן של בלוק הזיכרון הראשון להדפיס.

139
00:07:06,000 --> 00:07:09,000
וואו, למרות שלא עשו str עותק

140
00:07:09,000 --> 00:07:12,000
תווים כלשהם לתוך בלוק הערימה השנייה, זו שהצביעו על ידי T,

141
00:07:12,000 --> 00:07:15,000
אנחנו מקבלים את הדפסה.

142
00:07:15,000 --> 00:07:18,000
ואכן, את המחרוזת אנחנו דחוסים לתוך הבלוק הראשון שלנו

143
00:07:18,000 --> 00:07:21,000
כבש את הבלוק הראשון ולבלוק השני,

144
00:07:21,000 --> 00:07:23,000
עושה הכל נראה נורמלי.

145
00:07:23,000 --> 00:07:26,000
Valgrind, אם כי, מספר לנו את הסיפור האמיתי.

146
00:07:26,000 --> 00:07:28,000
הנה.

147
00:07:28,000 --> 00:07:32,000
כל אלה לא חוקיים קורא וכותב.

148
00:07:32,000 --> 00:07:36,000
>> בואו נסתכל על דוגמה של סוג אחר של שגיאה.

149
00:07:36,000 --> 00:07:39,000
הנה אנחנו עושים משהו מאוד לא נעים.

150
00:07:39,000 --> 00:07:41,000
אנו תופסים את המרחב לint בערמה,

151
00:07:41,000 --> 00:07:45,000
ולאתחל מצביע int - עמ '- כדי להצביע על מקום זה.

152
00:07:45,000 --> 00:07:48,000
עם זאת, בעוד שהמצביע שלנו מאותחל,

153
00:07:48,000 --> 00:07:52,000
את הנתונים שהוא מצביע על מה שיש רק זבל הוא שבחלק מהערימה.

154
00:07:52,000 --> 00:07:55,000
לכן, כאשר אנו לטעון את הנתונים לתוך int i,

155
00:07:55,000 --> 00:07:57,000
אנחנו מבחינה טכנית אני לאתחל,

156
00:07:57,000 --> 00:08:00,000
אבל אנו עושים זאת עם נתוני זבל.

157
00:08:00,000 --> 00:08:03,000
השיחה כדי לטעון, שהוא מאקרו ניפוי שימושי

158
00:08:03,000 --> 00:08:06,000
הגדרתו בספרייה בשם צדק לטעון,

159
00:08:06,000 --> 00:08:09,000
תסגר התכנית אם תנאי המבחן שלה נכשל.

160
00:08:09,000 --> 00:08:11,000
כלומר, אם אני לא 0.

161
00:08:11,000 --> 00:08:14,000
תלוי מה היה בשטח הגל, שאליו מצביע p,

162
00:08:14,000 --> 00:08:18,000
תכנית זו יכולה לעבוד לפעמים ונכשלת בזמנים אחרים.

163
00:08:18,000 --> 00:08:20,000
אם זה עובד, אנחנו פשוט מקבלים מזל.

164
00:08:20,000 --> 00:08:24,000
המהדר לא יתפוס את השגיאה, אבל Valgrind בטוח יהיו.

165
00:08:24,000 --> 00:08:28,000
יש לנו לראות את השגיאות הנובעות מהשימוש בנתונים אלה הזבל שלנו.

166
00:08:28,000 --> 00:08:32,000
>> כשאתה להקצות זכרון ערימה אבל לא deallocate או לשחרר אותו,

167
00:08:32,000 --> 00:08:34,000
זה נקרא דליפה.

168
00:08:34,000 --> 00:08:37,000
לתכנית קטנה, קצרת מועד שפועלת ומייד עם יציאתו

169
00:08:37,000 --> 00:08:39,000
הדלפות הן תמימות למדי,

170
00:08:39,000 --> 00:08:42,000
אך לפרויקט בגודל גדול יותר ו / או אריכות ימים,

171
00:08:42,000 --> 00:08:46,000
אפילו דליפה קטנה יכולה מתחמת למשהו גדול.

172
00:08:46,000 --> 00:08:49,000
לCS50, אנחנו מצפים ממך

173
00:08:49,000 --> 00:08:51,000
לדאוג לשחרור כל זכרון הערימה שתקצה,

174
00:08:51,000 --> 00:08:54,000
מכיוון שאנחנו רוצים אותך כדי לבנות את הכישורים לטפל כראוי התהליך הידני

175
00:08:54,000 --> 00:08:56,000
הנדרש על ידי ג

176
00:08:56,000 --> 00:08:59,000
כדי לעשות זאת, התכנית שלך צריכה להיות מדויקת

177
00:08:59,000 --> 00:09:03,000
התאמה של אחד לאחד בין malloc ושיחות חינם.

178
00:09:03,000 --> 00:09:06,000
למרבה המזל, Valgrind יכול לעזור לך עם דליפות זיכרון מדי.

179
00:09:06,000 --> 00:09:09,000
הנה תכנית דולפת נקראת leak.c שמקצה

180
00:09:09,000 --> 00:09:13,000
מקום בערמה, כותב אליו, אבל לא ישחרר אותו.

181
00:09:13,000 --> 00:09:16,000
אנו עורכים אותו עם הפכו ולהפעיל אותו תחת Valgrind,

182
00:09:16,000 --> 00:09:18,000
ואנחנו רואים את זה, בזמן שאין לנו שגיאות זיכרון,

183
00:09:18,000 --> 00:09:20,000
יש לנו דליפה אחת.

184
00:09:20,000 --> 00:09:23,000
יש 16 בתים בהחלט איבוד,

185
00:09:23,000 --> 00:09:27,000
כלומר את המצביע לזיכרון שלא היה בהיקפה כאשר התכנית יצאה.

186
00:09:27,000 --> 00:09:30,000
עכשיו, Valgrind לא נותן לנו המון מידע על הדליפה,

187
00:09:30,000 --> 00:09:35,000
אבל אם תעקוב אחרי הפתק הקטן הזה שזה נותן לכיוון החלק התחתון של הדו"ח שלה

188
00:09:35,000 --> 00:09:38,000
לשידור חוזר עם - דליפה לבדוק = מלא

189
00:09:38,000 --> 00:09:41,000
כדי לראות את הפרטים המלאים של זיכרון שדלף,

190
00:09:41,000 --> 00:09:44,000
נקבל מידע נוסף.

191
00:09:44,000 --> 00:09:46,000
כעת, בסיכום הערמה,

192
00:09:46,000 --> 00:09:50,000
Valgrind אומר לנו איפה הזיכרון שאבד בתחילה הוקצה.

193
00:09:50,000 --> 00:09:52,000
בדיוק כפי שאנו מכירים מהתבוננות בקוד המקור,

194
00:09:52,000 --> 00:09:55,000
Valgrind מודיע לנו שאנחנו הדלפנו את הזיכרון

195
00:09:55,000 --> 00:09:58,000
הוקצה בקריאה לmalloc על קו 8 של leak.c

196
00:09:58,000 --> 00:10:00,000
בתפקיד הראשי.

197
00:10:00,000 --> 00:10:02,000
די מגניב.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind מסווג הדלפות שימוש במונחים אלה:

199
00:10:04,000 --> 00:10:07,000
אבדתי בהחלט - זה זיכרון שהוקצה ערימה

200
00:10:07,000 --> 00:10:10,000
כדי שהתכנית כבר לא מצביעה.

201
00:10:10,000 --> 00:10:14,000
Valgrind יודע שפעם היה המצביע, אך מאז אבדת אותו.

202
00:10:14,000 --> 00:10:17,000
זיכרון זה בהחלט דלף.

203
00:10:17,000 --> 00:10:20,000
אבד בעקיפין - זה זיכרון שהוקצה ערימה

204
00:10:20,000 --> 00:10:24,000
כדי שהמצביעים רק לזה גם הולכים לאיבוד.

205
00:10:24,000 --> 00:10:27,000
לדוגמה, אם אבדת את המצביע לצומת הראשונה של רשימה מקושרת,

206
00:10:27,000 --> 00:10:30,000
אז הצומת הראשונה עצמו הייתה בהחלט הפסיד,

207
00:10:30,000 --> 00:10:34,000
בעוד שכל צומת באים יהיו אבודים באופן עקיף.

208
00:10:34,000 --> 00:10:37,000
ייתכן שאבדה - זה זיכרון שהוקצה ערימה

209
00:10:37,000 --> 00:10:41,000
כדי שValgrind לא יכול להיות בטוח אם יש מצביע או לא.

210
00:10:41,000 --> 00:10:44,000
עדיין נגיש הוא זיכרון שהוקצה ערימה

211
00:10:44,000 --> 00:10:47,000
כדי שהתכנית עדיין יש מצביע ביציאה,

212
00:10:47,000 --> 00:10:50,000
אשר בדרך כלל אומר שנקודות משתנות גלובליות לזה.

213
00:10:50,000 --> 00:10:53,000
כדי לבדוק אם קיים הדליפה האלה, אתה גם צריך לכלול את האפשרות

214
00:10:53,000 --> 00:10:55,000
- עדיין נגיש = כן

215
00:10:55,000 --> 00:10:58,000
בפנייה לValgrind.

216
00:10:58,000 --> 00:11:01,000
>> מקרים שונים אלה עלולים לחייב אסטרטגיות שונות לניקוים,

217
00:11:01,000 --> 00:11:05,000
אבל הדלפות יש לחסל.

218
00:11:05,000 --> 00:11:08,000
למרבה הצער, תיקון דליפות יכול להיות קשה לעשות,

219
00:11:08,000 --> 00:11:11,000
מאז שיחות שגויות לחופשיים יכולות לפוצץ את התכנית שלך.

220
00:11:11,000 --> 00:11:14,000
לדוגמה, אם אנו מסתכלים על invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
אנו רואים דוגמה לdeallocation זיכרון הרע.

222
00:11:18,000 --> 00:11:21,000
מה צריך להיות שיחה אחת לשחרר את כל הגוש

223
00:11:21,000 --> 00:11:24,000
של זיכרון אליו מצביע int_block,

224
00:11:24,000 --> 00:11:27,000
הפך במקום ניסיון לשחרר את כל קטע int בגודל

225
00:11:27,000 --> 00:11:29,000
של הזיכרון בנפרד.

226
00:11:29,000 --> 00:11:32,000
זה ייכשל קטסטרופלי.

227
00:11:32,000 --> 00:11:34,000
בום! מה שגיאה.

228
00:11:34,000 --> 00:11:36,000
זה בהחלט לא טוב.

229
00:11:36,000 --> 00:11:39,000
אם אתה תקוע עם סוג זה של שגיאה, אם כי, ואתה לא יודע איפה לחפש,

230
00:11:39,000 --> 00:11:41,000
לנפול על גב החבר הכי הטוב החדש שלך.

231
00:11:41,000 --> 00:11:44,000
נחשת נכון - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, כמו תמיד, יודע בדיוק מה קורה.

233
00:11:47,000 --> 00:11:50,000
ספירת alloc וחופשיה אינה מתאימה.

234
00:11:50,000 --> 00:11:52,000
יש לנו alloc 1 ו 4 משחררים.

235
00:11:52,000 --> 00:11:55,000
וValgrind גם אומר לנו איפה שיחה חינם הרע הראשונה -

236
00:11:55,000 --> 00:11:58,000
אחד שהפעיל את הפיצוץ - שממנו מגיע -

237
00:11:58,000 --> 00:12:00,000
קו 16.

238
00:12:00,000 --> 00:12:03,000
כפי שאתם רואים, שיחות רעות לחינם הן באמת רעות,

239
00:12:03,000 --> 00:12:05,000
לכן מומלץ לתת דליפת התכנית שלך

240
00:12:05,000 --> 00:12:08,000
בזמן שאתה עובד על מקבל פונקציונלי נכון.

241
00:12:08,000 --> 00:12:12,000
להתחיל לחפש דליפות רק לאחר התכנית שלך אינה פועלת כראוי,

242
00:12:12,000 --> 00:12:14,000
ללא שגיאות אחרות.

243
00:12:14,000 --> 00:12:16,000
>> וזה כל מה שיש לנו בסרטון זה.

244
00:12:16,000 --> 00:12:18,000
עכשיו מה אתם מחכים?

245
00:12:18,000 --> 00:12:21,000
ללכת לנהל Valgrind על התוכניות שלך עכשיו.

246
00:12:21,000 --> 00:12:25,000
השם שלי הוא נייט Hardison. זה CS50. [CS50.TV]