Valgrind: questions about some kinds of error reports

Accinson · 08-30-2010, 05:04 AM

Hi,
i have been using Valgrind for a week now.It did help A LOT finding some nasty bugs. I am,though,accumulating some questions about the reports,which i need to clarify. I hope they are not too silly questions.....

Question 1

Quote:

4 errors in context 308 of 7231:
Thread 6:

a)Why does it say "4 errors"? Is it just to not report the same error 4 times?
b)I wonder also about the context datum:does it mean that the program (or the thread?) has made 7231 context switchings,and i'm observing the 308th?
c)The "Thread 6":it means that the following part of the report will be relative to the 6th thread of my application? And how does Valgrind establishes that it is the 6th thread (i imagine cause it's the 6th thread started in chronological order)

Question 2

Quote:

1
==3622== Invalid write of size 4
2
==3622== at 0x80F8975: MainForm::create(_WidgetRec*) (MainForm.cpp:38)
==3622== by 0x2CC9F71: XtAppNextEvent (in /usr/lib/libXt.so.6.0.0)
==3622== by 0x2CBCE23: XtAppMainLoop (in /usr/lib/libXt.so.6.0.0)
==3622== by 0x8169ED4: start(int, char**) (main.cpp:196)
==3622== by 0x8169FC1: main (main.cpp:289)
3
==3622== Address 0xa180c60 is 8 bytes after a block of size 8 alloc'd
==3622== at 0x40060D5: operator new(unsigned int) (vg_replace_malloc.c:214)
==3622== by 0x80F85B4: MainForm::create(_WidgetRec*) (MainForm.cpp:81)
==3622== by 0x2CC9D48: ??? (in /usr/lib/libXt.so.6.0.0)
==3622== by 0x2CC9F71: XtAppNextEvent (in /usr/lib/libXt.so.6.0.0)
==3622== by 0x2CBCE23: XtAppMainLoop (in /usr/lib/libXt.so.6.0.0)
==3622== by 0x8169ED4: start(int, char**) (main.cpp:196)
==3622== by 0x8169FC1: main (main.cpp:289)

So far i interpreted this kind of report as composed by the 3 numbered sections:
1)What kind of error
2)Where is the error
3)Where is the allocation (or, more generally, the operation) which leads to the memory allocation/freeing related to my uncorrect reading/writing.

Is that correct?

Question 3

Quote:

==00:00:19:11.423 3648== 8 bytes in 1 blocks are possibly lost in loss record 1,387 of 10,007
==00:00:19:11.423 3648== at 0x4005903: malloc (vg_replace_malloc.c:195)
==00:00:19:11.423 3648== by 0x2CAEF17: XtMalloc (in /usr/lib/libXt.so.6.0.0)
==00:00:19:11.423 3648== by 0x5C9D48: XmeTraitSet (in /usr/lib/libXm.so.4.0.3)
==00:00:19:11.423 3648== by 0x62787B: XmSetToolTipString (in /usr/lib/libXm.so.4.0.3)
==00:00:19:11.423 3648== by 0x4E9EB0: ??? (in /usr/lib/libXm.so.4.0.3)
==00:00:19:11.423 3648== by 0x2CB7467: ??? (in /usr/lib/libXt.so.6.0.0)
==00:00:19:11.423 3648== by 0x2CB7427: ??? (in /usr/lib/libXt.so.6.0.0)
==00:00:19:11.423 3648== by 0x2CB7ED3: ??? (in /usr/lib/libXt.so.6.0.0)
==00:00:19:11.423 3648== by 0x2CB87EE: _XtCreateWidget (in /usr/lib/libXt.so.6.0.0)
==00:00:19:11.423 3648== by 0x2CB8AB3: XtCreateManagedWidget (in /usr/lib/libXt.so.6.0.0)
==00:00:19:11.423 3648== by 0x509BE2: ??? (in /usr/lib/libXm.so.4.0.3)
==00:00:19:11.423 3648== by 0x2CB7467: ??? (in /usr/lib/libXt.so.6.0.0)

Does this mean that i am possibly losing 8 bytes in the block allocated by the XtMalloc instruction in libXt.so.6.0.0 ? What's the size of a block?

Mara · 08-31-2010, 03:21 PM

Quote:

Originally Posted by Accinson

Question 1

a)Why does it say "4 errors"? Is it just to not report the same error 4 times?

AFAIK yes

Quote:

b)I wonder also about the context datum:does it mean that the program (or the thread?) has made 7231 context switchings,and i'm observing the 308th?

Context in valgrind means the situation, not context switch. So there are 7k+ interesting situation and this problem happens in the 308th one.

Quote:

c)The "Thread 6":it means that the following part of the report will be relative to the 6th thread of my application? And how does Valgrind establishes that it is the 6th thread (i imagine cause it's the 6th thread started in chronological order)

Yes, it's 6th thread. AFAIK it's the thread ID as returned from pthread_create.

Quote:

Question 2

So far i interpreted this kind of report as composed by the 3 numbered sections:
1)What kind of error
2)Where is the error
3)Where is the allocation (or, more generally, the operation) which leads to the memory allocation/freeing related to my uncorrect reading/writing.

Is that correct?

Yes.

Quote:

Question 3

Does this mean that i am possibly losing 8 bytes in the block allocated by the XtMalloc instruction in libXt.so.6.0.0 ? What's the size of a block?

Not in XtMalloc instruction, but XtMalloc function (that calls malloc() ). Yes, this memory may be lost. However, with such kind of a library it may be tricky to find out for sure.

Mara · 08-31-2010, 03:21 PM

BTW remember that valgrind may also return some problems, that are not problems at all (it may be wrong!). It happends for some exotic ioctls, for instance.

johnsfine · 08-31-2010, 03:50 PM

Quote:

Originally Posted by Accinson

Hi,
i have been using Valgrind for a week now.It did help A LOT finding some nasty bugs.

Did you figure out the bug that is the subject of your question 2?

The allocation event in your part 3 of question 2, specifically line 81 of MainForm.cpp happened earlier in time than the access event in your part 2 of the same question, specifically line 38 of MainForm.cpp.

So line 38 was executed later than line 81 (both reported to be in the same function), typically implying either a loop or a subsequent call. But line 38 was also compiled to a later physical address than line 81, which is less common.

The call stack also has a difference between the two events:

Code:

==3622== by 0x2CC9D48: ??? (in /usr/lib/libXt.so.6.0.0)

That all makes me have trouble trusting the whole report.

But it does seem to be reporting a serious bug in you code and unless the report is totally messed up, the bug ought to be pretty obvious if you look at the relationship between what happens on lines 81 and 38 of MainForm.cpp

So what did you figure out that bug was?