|
From: Jeremy F. <je...@go...> - 2003-12-18 09:03:40
|
On Thu, 2003-12-18 at 00:24, Tom Hughes wrote: > It gives the kernel a pointer to a pid_t which in which it should > store the current thread's tid whenever it feels like it. In this > case ld.so was actually passing NULL as the argument so it was in > fact turning off this functionality. So we can just ignore the syscall for now? > No. It was looking at the symbol tables and was managing to map about > half the libraries then reporting mmap failed for the rest. As I increased > that number it gradually reported fewer and fewer failures. Hm. I'm a bit confused. Can you look at what's mapped at the time it fails? > >> 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? > > At 4 and 5, after stdin/out/err and my valgrind log fd which is 3: That was actually a bug in your patch to set VG_(max_fds) dynamically - it was trying to use VG_(safe_fd) before you'd initialized VG_(max_fds). I just checked in a fix. J |