vgIntercept not working (was Re: [Valgrind-users] valgrind and poll())

[Julian S. <js...@ac...>]

Ok, I've got the same problem running OpenOffice on R H 9, using the
LD_ASSUME_KERNEL thing and auxinfo patch from Graydon.

OO is blocking in accept().  We get to accept() at vg_intercept.c:140
(correct), which then calls VGL_(accept) (correct).  Unfortunately this
leads to the one in the same file rather than the one in
vg_libpthread.c.  Enquiring with LD_DEBUG=files confirms that ld.so
has somehow done this, despite both valgrind.so and vg_libpthread.so
being in the image.

Graydon, Jeff, is there any known issue in glibc-2.3.2 to do with weak
symbols not being overriden by non-weak symbols?  What we've got here is
just such a case. 

Mystified.

J


On Thursday 03 April 2003 6:56 am, da...@2g... wrote:
> Quoting Jeremy Fitzhardinge <je...@go...>:
> > On Wed, 2003-04-02 at 10:28, David Eriksson wrote:
> > > Strace stops in poll, and if I attach to the server process with gdb I
> > > get this stacktrace:
> > >
> > > (gdb) bt
> > > #0  0x40183272 in vgPlain_do_syscall () from
> > > /usr/local/lib/valgrind/valgrind.so
> > > #1  0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0
> > > #2  0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60)
> > > at vg_intercept.c:194
> > > #3  0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0
> > > #4  0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
> > > #5  0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0
> > > #6  0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616
> > > #7  0x403d3907 in __libc_start_main () from /lib/libc.so.6
> >
> > Hm, looks like the vg_intercept stuff isn't working - it's catching
> > poll, but it isn't passing it into the threads library properly.  What
> > does ldd <your program> say?  What is in /proc/<pid>/maps when you run
> > it?  What does the link command line look like?
>
> ldd says this:
>
>         libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x4002a000)
>         libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4002e000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x40054000)
>         libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0x400a6000)
>         liblber.so.2 => /usr/lib/liblber.so.2 (0x400d4000)
>         libradiusclient.so.0 =>
> /usr/local/radiusclient/lib/libradiusclient.so.0 (0x400df000)
>         libssl.so.2 => /lib/libssl.so.2 (0x400e8000)
>         libcrypto.so.2 => /lib/libcrypto.so.2 (0x40119000)
>         libresolv.so.2 => /lib/libresolv.so.2 (0x401ed000)
>         libc.so.6 => /lib/libc.so.6 (0x401ff000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>         libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4033c000)
>         libdl.so.2 => /lib/libdl.so.2 (0x40347000)
>         libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4034a000)
>         libcrypt.so.1 => /lib/libcrypt.so.1 (0x40352000)
>         libpam.so.0 => /lib/libpam.so.0 (0x4037f000)
>
> The output from /proc/<pid>/maps is attached.
>
> The (short version) of the linking is simply like this:
>
> gcc  -o server  <OBJECTS> `glib-config --libs gthread` <LIBRARIES>
>
> > Did you manage to get a small standalone program to reproduce the
> > problem?
>
> Not yet.
>
> \David