|
From: Russ C. <rsc...@pl...> - 2003-09-27 02:36:57
|
First, let me say that Valgrind just pointed out a subtle use-after-free bug in some code of mine that is many years old. Valgrind wins tool of the year in my book. Thanks. However, it took a little coercing to get Valgrind to tell me what I needed to know. My problem is that the program in question uses a custom user-space threading library (think GNU pth, though it's not), so there are lots of small (say 8k) stacks in malloced memory, and as context switches happen the stack pointer hops around between these. It took me a while to find the aforementioned bug because Valgrind diagnosed the invalid read address as "on thread 1's stack", I suspect because the current stack pointer was below the read address in question, far below. I had to comment out the section that leads to setting "akind = Stack" in memcheck, and then I got the actual error that the read address was in freed memory. Is there some way for the debugged programs to tell Valgrind how big their stacks are? I'd be happy to make a call into Valgrind every time I allocate a thread stack, in order to get better error messages. I poked through the documentation but couldn't find anything that seemed relevant. Thanks much! Russ Cox |
|
From: Dirk M. <dm...@gm...> - 2003-09-28 09:30:40
|
On Saturday 27 September 2003 04:19, Russ Cox wrote: > Is there some way for the debugged programs to tell Valgrind > how big their stacks are? I don't think so. the magic stuff is done in our implementation of libpthread.so, which you obviously don't use. for inspiration have a look at do__apply_in_new_thread in coregrind/ vg_scheduler.c > get better error messages. I poked through the documentation > but couldn't find anything that seemed relevant. There is no easy way, sorry. but maybe you can write a wrapper around pthread for your thread handling? then valgrind is able to find the stacks and understands what is going on. |
|
From: Dan K. <da...@ke...> - 2003-09-28 12:10:24
|
Dirk Mueller wrote: > There is no easy way, sorry. but maybe you can write a wrapper around pthread > for your thread handling? then valgrind is able to find the stacks and > understands what is going on. That would probably require running on a system that had NPTL, since the whole reason Russ isn't using pthread is that he was unhappy with linuxthreads. However, that might force him to radically change his code (adding mutexes, etc), so he probably won't be thrilled at the prospect. Heh. Maybe this'll teach Russ. Either use the standard threading packages, or go straight to real state machines and don't look back :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |