Florian Echtler <[email protected]> writes: > [...] > read(37, "D", 1) = 1 > write(26, "W", 1) = 1 > write(38, "f", 1) = 1 > read(25, "W", 16) = 1 > read(37, "D", 1) = 1 > write(38, "f", 1) = 1 > +++ killed by SIGTRAP +++ > > Is this a known problem? My Android patch mostly fixed a few function > signatures and build issues, so I'm unsure whether it is the culprit... > [ For reference, it is available at https://github.com/floe/ltrace ].
I looked into your patch set. First, I was using error.h liberally in my code, as I thought it's standard, but apparently it isn't. Mea culpa, I'll need to fix that before merging. Other than that, I don't see anything in your patches that would break tracing like what you show. If you forked off 0.6.0, the threading fixes aren't in yet. Might that be the cause? I don't see any evidence of threads in your snippet, but if the process that you are tracing shares the address space with someone else, that someone else will see breakpoints that ltrace puts in, and will be SIGTRAP'd if it hits one of those. That would then kill the original traced process as well, which is what you are seeing. There's a bunch of patches that implement support for processes with shared address space. Unfortunately those same patches might break ARM support. They also rely on procfs, is that available on Android? Other than that I don't know what might cause that ltrace interprets SIGTRAP as a real signal as opposed to a tracing event. Maybe if Android kernel doesn't support PTRACE_O_TRACESYSGOOD we might be hitting some weird corner case (that's not really tested, recent kernels all know about that option). Thanks, PM _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
