|
From: Bart V. A. <bar...@gm...> - 2008-05-04 08:41:50
|
On Sun, May 4, 2008 at 10:19 AM, Julian Seward <js...@ac...> wrote: > > Can you clarify the link between this mechanism for finding the highest > address in a stack, and why drd takes lots of memory on ppc? I assume > you have some hypothesis in mind, but I don't know what it is. As you know on Linux the NPTL allocates space on the top of the stack for NPTL-private data. This data is accessed by more than one thread. In order to avoid false positives on this NPTL-private data I let DRD suppress data race reports on data accesses in the NPTL-private data area. There is no easy way to find out where this area is allocated, so what happens in DRD is to suppress all accesses to data in the range (highest_used_stack_address() .. (top of stack)). This address range contains a little bit more than the NPTL-private data area, but it contains at least that area. Suppression happens by setting one bit in a bitmap for every address to be suppressed. So my hypothesis about the cause of the out-of-memory error on ppc is that the function highest_used_stack_address() was returning a pointer that was far out of range of the stack addreses. The following error message confirms that VG_(get_StackTrace)() returns a stack pointer that is out of range (see also the source code of highest_used_stack_address() in the source file exp-drd/drd_clientreq.c): exp-drd: drd_clientreq.c:107 (highest_used_stack_address): Assertion 'VG_(thread_get_stack_max)(vg_tid) - VG_(thread_get_stack_size)(vg_tid) <= husa && husa < VG_(thread_get_stack_max)(vg_tid)' failed. Do you already have a clue about why VG_(get_StackTrace)() shows such behavior on ppc ? Bart. |