[Ltrace-devel] How can I definitely relate a library call to a library file?

[Petr Machata]

Uwe Galle wrote:
> Hi,
> 
> I didn't find an answer in a FAQ or with a web search so I want to post
> it here.
> 
> My procinfo (version 18) crashes with a "[Floating point exception]".
> ldd shows me the following dynamic link libraries:
> 
>         linux-gate.so.1 =>  (0xffffe000)
>         libncurses.so.5 => /lib/libncurses.so.5 (0xb7f46000)
>         librt.so.1 => /lib/librt.so.1 (0xb7f3d000)
>         libc.so.6 => /lib/libc.so.6 (0xb7e0a000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb7e06000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0xb7def000)
>         /lib/ld-linux.so.2 (0xb7f8f000)
> 
> Now I invoked "ltrace --indent 10 -o trace-indent-S.txt -Si procinfo -f"
> and got the lines, inter alia:
> 
> ...
> [0xb7f08c74] SYS_open("/lib/libc.so.6", 0, 077300)         = 3
> [0xb7f08cf4] SYS_read(3, "\177ELF\001\001\001", 512)       = 512
> [0xb7f08c3e] SYS_fstat64(3, 0xbff90020, 0xb7f0eff4, 15, 0xb7f0f670) = 0
> [0xb7f09273] SYS_mmap2(0, 0x1325f0, 5, 2050, 3)            = 0xb7d6f000
> [0xb7f08ef9] SYS_fadvise64(3, 0, 0, 0x1325f0, 3)           = 0
> [0xb7f09273] SYS_mmap2(0xb7e9c000, 12288, 3, 2066, 3)      = 0xb7e9c000
> [0xb7f09273] SYS_mmap2(0xb7e9f000, 9712, 3, 50, -1)        = 0xb7e9f000
> [0xb7f08cad] SYS_close(3)                                  = 0
> ... (many other lines)
> [0xffffe410] SYS_set_tid_address(0xb7d52708, 0xb7d67ff4, 2, 0xb7d526c0,
> 0) = 21774
> [0xffffe410] SYS_set_robust_list(0xb7d52710, 12, 0xb7d67ff4, 0xb7d526c0,
> 0) = 0
> [0xffffe410] SYS_rt_sigaction(32, 0xbff90568, 0, 8, 0xb7d67ff4) = 0
> [0xffffe410] SYS_rt_sigaction(33, 0xbff90568, 0, 8, 0xb7d67ff4) = 0
> [0xffffe410] SYS_rt_sigprocmask(1, 0xbff90820, 0, 8, 0xb7d67ff4) = 0
> [0xffffe410] SYS_ugetrlimit(3, 0xbff908a8, 0xb7e9dff4, 16, 1) = 0
> [0xffffe410] SYS_uname(0xbff9061c)                         = 0
> [0x8049521] __libc_start_main(0x804da50, 2, 0xbff90954, 0x8050510,
> 0x8050500 <unfinished ...>
> 
> The logged sequence of calls is interrupted on the indent level of

Interrupted?  You interrupt it, or the program fails, or what happens?

> __libc_start_main so it seems to be this function what crashes. Of

Not necessarily, __libc_start_main is probably just the last PLT entry
that got hit.  It can easily be inside the `main` function, or one of
the functions called from main.  If they are not library calls, and thus
are not routed via PLT, ltrace wouldn't know about them.

> course, the name __libc_start_main let me suggest that this call should
> be contained in /lib/libc.so.6. But what puzzles me is the difference of
> the IP before __libc_start_main and after /lib/libc.so.6. On my system

0xffffe410 is, according to your linkmap, inside linux-gate.so.1, which
is, if I'm not mistaken, virtual DSO (library mapped in by the kernel
without backing of actual library file).  I wouldn't be surprised if
syscall handler was located there.

0x8049521 is not mentioned in your linkmap, but 0x80something is where
non-PIE binaries on x86 get loaded.  It's probably PLT entry for
__libc_start_main.

So the sequence up to the call to __libc_start_main looks healthy, but
then something goes awol.  I'm afraid ltrace is too coarse-grained a
tool to be helpful in this case, you may want to use gdb to do finer
analysis of what breaks and where.

HTH,
PM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20080213/2e67af4f/attachment.pgp