|
From: Martin B. <mar...@ya...> - 2004-05-03 12:24:34
|
PROBLEM: I have a program dying on a segmentation fault. The location of the segmentation fault varies from run to run. None of those location in the code make sense. I suspect another thread is corrupting the stack of the thread causing the segmentation. QUESTION: How Valgrind can be used to detect that a thread is accessing the stack of another thread? If not, how shall I ask for this new feature? Thanks all. Martin. ===== Mar...@ya... (514) 836-5724 ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
|
From: Martin B. <mar...@ya...> - 2004-05-03 12:26:38
|
PROBLEM: I have a program dying on a segmentation fault. The location of the segmentation fault varies from run to run. None of those location in the code make sense. I suspect another thread is corrupting the stack of the thread causing the segmentation. QUESTION: How Valgrind can be used to detect that a thread is accessing the stack of another thread? If not, how shall I ask for this new feature? Thanks all. Martin. ===== Mar...@ya... (514) 836-5724 ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
|
From: Henrik N. <hn...@ma...> - 2004-05-03 15:13:34
|
On Mon, 3 May 2004, Martin Bouchard wrote: > QUESTION: > How Valgrind can be used to detect that a thread is > accessing the stack of another thread? Not sure how practical this is, but it sounds like a good move provided it is optional. Tere is however situations where two threads may want to share local data on the stack so it can not be on by default. You should also be able to use a redzone on the stack of the crashing thread and hopefully catch the corruption this way. Adding a redzone should be as simple as declaring a local array and then tell valgrind that this area is inaccessible (VALGRIND_MAKE_NOACCESS). But I am a little uncertain on how valgrind manages thread stacks. I know there is some magics for the normal stack, but not sure if this also applies to thread stacks or if this magics have any implications on manual instrumentation. Regards Henrik |
|
From: Nicholas N. <nj...@ca...> - 2004-05-04 09:07:45
|
On Mon, 3 May 2004, Henrik Nordstrom wrote: > > How Valgrind can be used to detect that a thread is > > accessing the stack of another thread? > > Not sure how practical this is, but it sounds like a good move provided it > is optional. Tere is however situations where two threads may want to > share local data on the stack so it can not be on by default. > > You should also be able to use a redzone on the stack of the crashing > thread and hopefully catch the corruption this way. Adding a redzone > should be as simple as declaring a local array and then tell valgrind that > this area is inaccessible (VALGRIND_MAKE_NOACCESS). But I am a little > uncertain on how valgrind manages thread stacks. I know there is some > magics for the normal stack, but not sure if this also applies to thread > stacks or if this magics have any implications on manual instrumentation. This is a difficult problem to detect, and Valgrind (Memcheck and/or Addrcheck) probably aren't going to be able to help you. They track each memory byte with a single bit that indicates the byte is "addressable" or "not addressable". There's no notion of ownership, or way of saying "this memory is addressable by thread A, but should be left alone by thread B". If thread A is writing into the middle of thread B's stack, that won't be detected, unfortunately. As for the redzone suggestion, I think Memcheck/Addrcheck already put redzones at the end of thread stacks, so any overruns of that sort should be caught... I could be wrong about that, though. N |
|
From: Henrik N. <hn...@ma...> - 2004-05-04 10:36:18
|
On Tue, 4 May 2004, Nicholas Nethercote wrote: > As for the redzone suggestion, I think Memcheck/Addrcheck already put > redzones at the end of thread stacks, so any overruns of that sort should > be caught... I could be wrong about that, though. Still it would be nice to have answered if it is OK to manually place redzones in stacks. I assume one must/should reset the memory area before returning from the function where the zone is defined (before stack frame freed), but is there any other gotchas wrt how Valgrind tracks stack usage to think of when doing this kind of things? Manually adding stack redzones could be quite useful for detecting stack based buffer overflows and similar things, but with the stack managed slightly differently than the heap I am a little scared about upsetting valgrind if playing around with this, but maybe there is nothing to worry about? (assuming one properly cleans up after oneself, not leaving redzones in freed stack frames, messing up later reuse of the same stack space in another call) Regards Henrik |