On 05.05.2012 02:01, Petr Machata wrote: > Florian Echtler <[email protected]> writes: >> On 04.05.2012 01:11, Petr Machata wrote: >>> Florian Echtler <[email protected]> writes: >>>> /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...]
> Ah, but of course! That would explain why it's trying to apply offsets > to the wrong library. The trick is that library is indexed differently > from lte. This is my fix, and it's wrong, I didn't notice that they are > indexed differently. But when written the original way, it leads to > essentially the following code: > > crawl_linkmap(callback, struct ltelf *lte): > callback(lte); > > hook_libdl_cb(struct ltelf *lte): > library[library_num++] = strdup(lib_name); > lte[library_num].base_addr = addr; // <-- buffer overrun > > int linkmap_init(struct ltelf *lte): > crawl_linkmap(hook_libdl_cb, lte); > > extern struct ltelf main_lte; > > Event *next_event(void): > linkmap_init(&main_lte); > > So it's kind of choose your bug. Actually, as I've found, that's not the case after all - I've run into a different case where two consecutive libraries were mapped into significantly different address spaces, but still all symbols were applied with an offset of 0x100000. Indeed, in linker.h from bionic: #define LIBINC 0x00100000 which is apparently exactly what caused most issues. No idea what this is or why it's there... > The libs branch replaces most of that logic, so it will take care of > this naturally when it is merged. I fixed the compilation issues > (though not the SIGILL issues that I'm seeing, but I see those on master > as well). I've also merged my patch into libs (android-libs in my repo). However, it doesn't seem to process already-loaded libraries (i.e., linkmap_init is never called)? > FYI, I went over your patchset and ported the ptrace() fixes to libs > branch, those seem obviously correct. I think the error() fixes are not > relevant anymore, I moved uses of error in generic code to fprintf. The > stuff related to _ElfW was changed as well and is not present anymore. Thanks, the difference between libs and android-libs is now pretty small - helps to focus on the important parts :-) > I don't understand most of the code related to blacklists and altpath, > so I'm leaving it alone. Is it necessary, or is it just a hack to get > things working? The blacklists are just a hack for my specific use case. The altpath, however, was necessary at least in the other branches to actually find the library so files - not sure how the libs branch will handle this, as linkmap_init seems not to be called right now. Florian -- SENT FROM MY PDP-11 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
