Hello again, On 25.04.2012 19:23, Petr Machata wrote: >>> That's on master as well. There's about 60 commits on top of what's >>> tagged 0.6.0, and most of that is for fixes relating to tracing >>> processes with shared address space. We should really do 0.7, but I >>> can't seem to be able to reach Juan. >> In any case, I'll forward-port my patch to master and see if there's any >> difference. > Be sure to post your findings. [Warning: long post to follow]
I've ported my patch to master, see also repo at [1]. Results: 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: ./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. /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...] 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. Nevertheless, I would be very grateful for any additional insights on what might have changed between 0.6.0 and master that could shed some light on these issues - I'm not familiar enough with the code be able to tell that from looking at the git log. Many thanks, Florian [1] https://github.com/floe/ltrace/tree/android-master -- SENT FROM MY PDP-11 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
