On Sep 10, 6:20 pm, DaveG <[email protected]> wrote: > With forcecopy enabled, I now get the crash in a different location:
Interesting. Could be that whatever was trashing the virtual heap is now trashing the native heap. The guard areas are 256 bytes before/ after, but if the write is outside that (or something is retaining a pointer and writing to it after the memory is freed) the problem wouldn't be detected. Could also be timing related -- forcecopy does tend to slow things down. What you really want here is valgrind, but I don't know of a version that works on ARM (though I've heard rumors). (BTW, there's a bug in forcecopy -- I got the arg order wrong on memset (dataBuf, len, 0xdd); -- but because the guard area is more than 0xdd bytes it's harmless.) > I/DEBUG ( 547): ip 804d13c4 sp 46628e18 lr afe1355d pc afe0e14c cpsr > 00000010 > I/DEBUG ( 547): #00 pc 0000e14c /system/lib/libc.so > I/DEBUG ( 547): #01 pc 0001355a /system/lib/libc.so > > Which corresponds to the strlen() call within fputs(), but which > unfortunately > doesn't clarify the situation at all, since we don't have any calls to > fputs(). Well, maybe. What you've got isn't really a stack trace, it's just the value of the PC and LR registers, the latter of which holds a recent return address or maybe just a temporary. It seems to be in the right range for the library though. So you can count on being in the #00 method, but all you know about #01 is that the method was called sometime recently, and may or may not be the method that called #00. debuggerd does some "stack unwinding" gymnastics similar to what gdb does. Basically it scans up the code to figure out if LR was saved to the stack on method entry, and if so it uses that instead of the value in the LR register. Since this is using LR from the register, and I'm assuming there were no additional entries, it's reasonable to assume that the stack unwind failed, and debuggerd is essentially shrugging and formatting what's in the registers. gdb's unwinding may be better, assuming that the stack itself wasn't trampled. You may also be able to find the saved LR on the stack, which is why a chunk from the top of the stack is also dumped out. It's probably wise to ensure that you really are in strlen() by pulling libc.so off the device and checking it with arm-eabi-objdump - d. I hate it when the lib on the device isn't quite what I thought it was. :-) Curious that the fault address is 00000002 rather than a null pointer. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
