|
From: Adam G. <ar...@cy...> - 2003-05-06 10:18:09
|
At 13:45 04/05/03 +0100, you wrote: >On Mon, 28 Apr 2003, Adam Gundy wrote: > >> there are three places where if a thread switches stack, valgrind doesn't >> keep its idea of the highest word in the stack in sync. This causes backtraces >> with only one function in them, and sometimes causes valgrind to quit. >> >> The attached patch fixes all three cases. > >Do you have some small example programs which exhibit the bugs -- >too-small backtraces and early quitting? not really. these were all discovered while running WINE under valgrind, which switches the stack once it has created a thread. I have hacked together the attached simple program which demonstrates the problem with stack switching (this one doesn't even need threads - just altstack signal handling). Compile it with gcc -g, then run under valgrind. Hit Ctrl-C - valgrind will give a stack trace like: ==12716== Conditional jump or move depends on uninitialised value(s) ==12716== at 0x804852A: doit (test.c:9) apply the patch, rebuild valgrind, then try again: ==12718== Conditional jump or move depends on uninitialised value(s) ==12718== at 0x0804852A: doit (test.c:9) ==12718== by 0x0804854A: handler (test.c:14) ==12718== by 0x40187C4F: (within /usr/lib/valgrind/valgrind.so) early quitting depends on the 'stack overflow' check in scheduler_sanity() - since this only gets run for threads other than the primary, and also it only gets run when the scheduler is called (ie every 50000 bbs), then it is very code dependant whether valgrind will quit or not! Forcing the rescheduling quantum down to a low number makes it much more likely to trigger. the fixes are pretty transparent once you realize the problem. There is a per-thread variable which contains the highest valid word of the current stack. This must ALWAYS be correct, otherwise you get short backtraces, and occasionally (depending on scheduling) stack overflow messages. All three fixes are simply ensuring that tst->stack_highest_word is always correct... Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |