|
From: Jeremy F. <je...@go...> - 2003-12-18 01:12:22
|
On Wed, 2003-12-17 at 03:41, Tom Hughes wrote: > With RH9 it was complaining about syscall 258 which is set_tid_address > which is called by ld.so early on, so valgrind never used to see it. A > patch to add support for this is attached. What does set_tid_address do again? It might be better to just silently fail it with ENOSYS since we're not doing anything useful with that stuff yet. > Although simple programs worked, a debug build of one of our main > programs failed to mmap many of the shared objects. I managed to work > round this by adjusting VALGRIND_MAPSIZE in stage2.c to a little > over 300Mb in size. Debug builds of our software are somewhat extreme > in their use of shared libraries - this program had about 150 or so > and they mostly had level 3 DWARF debugging on. It should only be trying to map one of those in at once - do you really have a 100MByte+ .so file? > I noticed that if you track FD leaks then both /usr/bin/valgrind and > the client executable are reported as leaks. That shouldn't be. What fds is it finding them at? J |