Florian Echtler <[email protected]> writes: > On the pro side: no spurious crashes anymore. I'm assuming this was > indeed a multi-threading issue. > > However, on the con side: no library calls are traced anymore either. > (Syscalls still work fine). As before, my command line is:
If you see no calls, that most probably means breakpoints are either not inserted at all, ar inserted to wrong addresses (as you indicate below). Therefore nothing hits them, and things keep working (unless the breakpoint happens to maim some important datum somewhere). Absence of failures is a natural consequence of absence of tracing. > ./ltrace -F ltrace.conf -f -p 556 -D 77 \ > -x open -x close -x read -x write > > Excerpt from the debug log: > > DEBUG: breakpoint.c:43: enable_breakpoint: pid=556, addr=0xafc0b450, > symbol=read > DEBUG: breakpoint.c:35: arch_enable_breakpoint(556,0xafc0b450) > DEBUG: breakpoint.c:46: current = 0xffffffff, orig_value = 0x0, > thumb_mode = 0 > > DEBUG: breakpoint.c:43: enable_breakpoint: pid=556, addr=0x8a00, > symbol=_ZNK7android7RefBase9decStrongEPKv > DEBUG: breakpoint.c:35: arch_enable_breakpoint(556,0x8a00) > DEBUG: breakpoint.c:46: current = 0xe28fc600, orig_value = 0x0, > thumb_mode = 0 > > Note the difference between the externally specified function (read) > where current = 0xffffffff and the auto-added function where current != > 0xffffffff. current=-1 seems to indicate that PTRACE_PEEKTEXT failed. Unfortunately ltrace is full of unchecked errors. Here this is apparently caused by reading from unmapped region (wrong address). Since these are requested by -x, it seems that _r_debug probe at least found the list of libraries and went over them, trying to add breakpoints. > /proc/556/maps shows: > > 00008000-00009000 r-xp 00000000 1f:00 459 /system/bin/app_process > 00009000-0000a000 rwxp 00001000 1f:00 459 /system/bin/app_process > 0000a000-0065d000 rwxp 0000a000 00:00 0 [heap] > > [This looks correct to me: the 0x8a00 address is somewhere within the > original process.] > > afc00000-afc01000 r-xp 00000000 1f:00 411 /sys../lib/libstdc++.so > afc01000-afc02000 rwxp 00001000 1f:00 411 /sys../lib/libstdc++.so > afd00000-afd40000 r-xp 00000000 1f:00 401 /system/lib/libc.so > afd40000-afd43000 rwxp 00040000 1f:00 401 /system/lib/libc.so > > [This looks wrong: address 0xafc0b450 is somewhere between the spaces > where libstdc++.so and libc.so have been mapped...] This is puzzling. It's as if it took symbols from libc.so and applied them on top of libstdc++. Strange. > Looking at /system/lib/libc.so with readelf -a shows: > > 109: 0000b450 0 FUNC GLOBAL DEFAULT 7 read > > Apparently, the offset is correct, but the base address is wrong. > > I have a hunch this is somehow - again - caused by the > weird/strange/broken linker from Android's bionic-libc; I will > investigate. I just tried ltrace on trimslice (Ubuntu 10.10), and it seems to be more or less working. The testsuite is not remotely clean, and I'm seeing spurious SIGILLs (I suspect most failures are due to this), but it's not as bad as I had expected after some reports on this list. Both ARM and Thumb binaries seem to be approximately on par. Even threading seems OK (if you are lucky and none of the threads SIGILL's). The situation is similar with the libs branch that I'd like to merge soonish, though the compilation needs some ironing out (a couple includes are missing here and there). So there are bugs in ARM support, but it's not catastrophic and it works "a bit". So... yeah, it seems like it's something in Android rubbing ltrace the wrong way. Thanks, PM _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
