|
From: Nicholas N. <nj...@ca...> - 2003-11-17 09:40:19
|
On Thu, 13 Nov 2003, David Judson wrote:
> I have a problem running a program under valgrind on RH9. The application
> is multi-threaded. When run under valgrind, one of the threads call munmap
> on the memory segment of a shared library. Subsequently, another thread
> needs a symbol in the library and tries to reload it. However the dlopen
> library becomes very confused, probably because it doesn't realize that the
> original copy of the library is unmapped. Things go rapdily downhill from
> there.
>
> This problem does not happen when using valgrind on RH 7.2
> When I run the program on RH9 using gdb, there is no call to munmap at this
> part of the program.
>
> To track this down, I would like to determine where the call to munmap is
> being made. How can I temporarily modify valgrind to produce a stack dump
> when munmap is called?
Try adding this:
VG_(pp_ExeContext)(
VG_(get_ExeContext)(
VG_(get_current_or_recent_tid)() ) );
VG_(message)(Vg_UserMsg, "");
to coregrind/vg_syscalls.c:munmap_segment().
N
|