|
From: Michael B. <mi...@ob...> - 2008-03-10 11:57:43
|
Hi,
I've been asked to look at some intermittent segmentation faults in some
code written by other developers so I decided to run the code under
Valgrind to see if it might reveal any issues. The good(?) news is that
Valgrind does highlight a number of potential issues but I'm not always
able to reconcile the lines that Valgrind reports with the actual lines
in the code.
I've copied a small example here to explain further what I mean. From
the following report, it can be seen that lines 1823 and 1833 are indeed
conditionals, but line 1851 is actually a printf statement containing
only a string literal. However, the next line (1852) is a conditional.
At first, I suspected a synchronization issue between the running code
and the sources, but I've now convinced myself that this is not the case.
Can anyone explain this behaviour? Am I just doing something stupid?
Regards and TIA,
MikeB
Valgrind report:
==24033== Conditional jump or move depends on uninitialised value(s)
==24033== at 0x45958F8: Reschedule (scheduling.c:1823)
==24033==
==24033== Conditional jump or move depends on uninitialised value(s)
==24033== at 0x4595941: Reschedule (scheduling.c:1833)
==24033==
==24033== Conditional jump or move depends on uninitialised value(s)
==24033== at 0x4595951: Reschedule (scheduling.c:1833)
==24033==
==24033== Conditional jump or move depends on uninitialised value(s)
==24033== at 0x45959C0: Reschedule (scheduling.c:1851)
scheduling.c:
1823: if( ( thread->timedwait.tv_sec != 0 )
1824: || ( thread->timedwait.tv_nsec != 0 ) )
1825: {
.
1833: if( ( thread->timedwait.tv_sec < currentTime.tv_sec )
1834: || ( ( thread->timedwait.tv_sec == currentTime.tv_sec )
1835: && ( thread->timedwait.tv_nsec <=
currentTime.tv_nsec)))
.
1851: printf("!!\n");
1852: if(thread->timedwait.tv_sec == 0)
|
|
From: Julian S. <js...@ac...> - 2008-03-10 12:14:07
|
> I've copied a small example here to explain further what I mean. From > the following report, it can be seen that lines 1823 and 1833 are indeed > conditionals, but line 1851 is actually a printf statement containing > only a string literal. However, the next line (1852) is a conditional. > > At first, I suspected a synchronization issue between the running code > and the sources, but I've now convinced myself that this is not the case. > > Can anyone explain this behaviour? Am I just doing something stupid? There can sometimes be a small degree of error in the line numbers. Reading it exactly accurately is not always easy and gcc has been known to emit bogus line number info, especially at high optimisation levels. Ideally, code you want to Memcheckify shouldn't be compiled at -O2 or -O3. Also you have no stack traces. Are you compiling with -fomit-frame-pointer? Anyway, the obvious conclusion from looking at these is that thread->timedwait.tv_sec contains an uninitialised value. You might want to figure out where that came from. Finally .. it is important to fix the first reported error first -- error cascades are well known. J |
|
From: Nicholas N. <nj...@cs...> - 2008-03-10 21:04:50
|
On Mon, 10 Mar 2008, Julian Seward wrote: >> I've copied a small example here to explain further what I mean. From >> the following report, it can be seen that lines 1823 and 1833 are indeed >> conditionals, but line 1851 is actually a printf statement containing >> only a string literal. However, the next line (1852) is a conditional. > > There can sometimes be a small degree of error in the line numbers. > Reading it exactly accurately is not always easy and gcc has been > known to emit bogus line number info, especially at high optimisation > levels. Yes -- Valgrind's line number reports are entirely dependent on the debug info added by GCC. N |