Project: AIR desktop, Flex 4.6, AIR 15, OSX 10.9.5, Flash Builder 4.6
I am getting an ADL crash which I haven't been able to diagnose. I've littered my code with trace statements, try/catch statements and breakpoints without tracking down the issue. Memory usage doesn't seem excessive. What is odd is that it doesn't crash when I profile the app.
The only thing I can think of is this is some kind of race condition which running in "profile" mode masks. That or garbage collection which is somehow delayed in "profile" mode. The OSX crash log cites EXC_BAD_ACCESSbut nothing else that I can understand in terms of my code.
Has anyone encountered this sort of ADL crash or recognize these symptoms?
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Project: AIR desktop, AIR 17, OSX 10.10.3
Yes, same thing here... but I'm getting SIGSEGV:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
... which turns out to be an "invalid memory access" message. The last human-readable crash line reads shows:
... __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
Then the rest is just hex values on the com.adobe.AIR. I've also littered with trace, and debug-step-throughs, yada yada.
When I incorporate a delay in code execution (via setTimout), the crashes don't seem to happen. So I think it might be some kind of race condition across asynchronous load/complete.
I don't believe it has anything to do with garbage collection / memory -- as far as I've been able to monitor.
I'm bummed.
Related
I'm trying to identify a bug in a program (32bit) which could probably lead to code execution. So far I debugged the application with ollydbg and ran my exploit code. Then ollydbg gives me an exception.
If I press "Ctrl+F9" nothing seems to be executed of my shellcode
In contrast when the exception occures and I step through the next instructions with "F8" I finally reach my shellcode and it gets executet
If I run the application without ollydbg, my shellcode also doesn't get executed
Why does my shellcode get executed when I step to the next instructions an otherwise not? What's then the normal case when I run my application without a debugger?
Thanks a lot!
When an exception is raised in a thread the system will first check if a debugger is attached.
If a debugger is attached the exception is reported to the debugger (and not to the faulting process or thread). In ollydbg (and most debuggers) you then have the choice to do something with that exception.
The 1st one is to pass that exception to the faulting thread (CTRL+F9) in ollydbg.
The system will look at the EXCEPTION_REGISTRATION_RECORD for the current thread and walks the list of EXCEPTION_REGISTRATION structures (each of these structures has an exception handler) and check if a handler can handle the exception.
If a handler can handle the exception, the stack is unwind (to a certain point) and the thread might continue its life.
If no handler can handle the exception, the final handler is called and the program crashes (the system will then usually display a dialog box informing the user that the process crashed).
This is exactly the same behavior in the case no debugger is attached.
Thus, in your case, passing the exception to the debugger will probably unwind the stack, and the thread will continue its execution after the location of the exception (or simply crash the whole application if the exception couldn't be handled).
The second option - when a debugger is attached - is to not pass the exception to the faulting thread (using one of the step [into | over] / run button). In this case the system will not search for any handler and the thread will either simply rethrow the exception (if it can't pass over it) or continue execution like nothing happened (if the debugger knows how to handle it).
You should check which type (most probably one of: Access violation in read / write ; breakpoint exception) of exception is raised and correct the problem (see at the bottom of the ollydbg window, it will tell you which kind of exception has been raised) if you want to execute your shellcode without problem.
I am working with a Cortex-A9 and my program crashes because of an UNDEFINED_INSTRUCTION exception. The assembly line that causes this exception is according to my debugger's trace:
Trace #9999 : S:0x022D9A7C E92D4800 ARM PUSH {r11,lr}
Exception: UNDEFINED_INSTRUCTION (9)
I program in C and don't write assembly or binary and I am using gcc. Is this really the instruction that causes the exception, i.e. is the encoding of this PUSH instruction wrong and hence a compiler/assembler bug? Or is the encoding correct and something strange is going on? Scrolling back in the trace I found another PUSH instruction, that does not cause errors and looks like this:
Trace #9966 : S:0x022A65FC E52DB004 ARM PUSH {r11}
And of course there are a lot of other PUSH instruction too. But I did not find any other that tries to push specifically R11 and LR, so I can't compare.
I can't answer my own question, so I edit it:
Sorry guys, I don't exactly know what happend. I tried it several times and got the same error again and again. Then I turned the device off, went away and tried it again later and know it works fine...
Maybe the memory was corrupted somehow due to overheating or something? I don't know. Thanks for your answers anyway.
I use gcc 4.7.2 btw.
I suspect something is corrupting the SP register. Load/store multiple (of which PUSH is one alias) to unaligned addresses are undefined in the architecture, so if SP gets overwritten with something that's not a multiple of 4, then a subsequent push/pop will throw an undef exception.
Now, if you're on ARM Linux, there is (usually) a kernel trap for unaligned accesses left over from the bad old days which if enabled will attempt to fix up most unaligned load/store multiple instructions (despite them being architecturally invalid). However if the address is invalid (as is likely in the case of SP being overwritten with nonsense) it will give up and leave the undef handler to do its thing.
In the (highly unlikely) case that the compiler has somehow generated bad code that is fix-uppable most of the time,
cat /proc/cpuinfo/alignment
would show some non-zero fixup counts, but as I say, it's most likely corruption - a previous function has smashed the stack in such a way that an invalid SP is loaded on return, that then shows up at the next stack operation. Best double-check your pointer and array accesses.
I have a solution with several projects. The solution is in Release mode with no optimization and with pdb files generated. While running Unit Tests i get exceptions but the stack trace does not contains the line numbers. At the modules window I can see that the current assembly is not optimized and that it has symbols loaded.
Just to note that I'm checking the stacktrace inside the debugger at a breakpoint where the exception is caugth.
Thanks in advance mates.
I'm debugging some odd ARM exceptions in an embedded system using the IAR workbench toolchain. Sometimes, when an exception is trapped the SVC_STACK is reported as out of range (very out of range!) Is this relevant, or just an artifact of the J-Link JTAG debugger? What is the SVC_STACK used for? It is set to 0x1000 size, but when it is out of range, it is way up in our heap area. Thanks!
ARMs SVC mode is entered when an exception occurs (not an IRQ or FIQ - fast IRQ). It can also be entered directly by code executing in non-user mode by setting the CPRS register, but I think this is uncommon except for when initializing the system.
When an exception occurs, the processor switches to the SVC stack, which has to be set up very early in the initialization of the system. I'm guessing that your initialization code is not properly setting up the SVC stack, or it's possible that one of the exception handlers is not coded properly and is trashing the stack.
A third possibility is that you're using an RTOS that sets up the ARM stacks the way it wants (basically overriding the SVC stack that the IAR's initialization code might set up). If this is the case, it's possible that everything is OK, but the IAR debugger thinks the SVC stack is out of range - the debugger will get its information from the linker config file - but if something changes the stack to another area of memory, then the debugger will get confused.
This happened to me all the time with the user mode stack in IAR when using an RTOS - the stacks were allocated based on task control blocks which were not in the CSTACK segment the debugger thought it should be in, and the debugger would issue irritating warnings. There was some project configuration setting that could be used to quiet the warnings, but I don't recall off the top of my head what it was - we rarely bothered with it, and just lived with the noise.
You'll need to verify that the the stack 'way up in the heap' area is valid - if you don't have some bit of code explicitly doing this, it's likely that it's wrong (or maybe you'll need to ask your RTOS vendor).
The ARM Architecture Reference Manual (ARM ARM) is freely available from arm.com and goes into excruciating detail about how the ARM stacks work. Another good reference is the ARM System Developer's Guide by Andrew Sloss, et al.
So I'm getting a "prefetch abort" exception on our arm9 system. This system does not have an MMU, so is there anyway this could be a software problem? All the registers seem correct to me, and the code looks right (not corrupted) from the JTAG point of view.
Right now I'm thinking this is some kind of hardware issue (although I hate to say it - the hardware has been fine until now).
What exactly is the exception you're getting?
Last time this happened to me, I went up the wrong creek for a while because I didn't realize an ARM "prefetch abort" meant the instruction prefetch, not data prefetch, and I'd just been playing with data prefetch instructions. It simply means that the program has attempted to jump to a memory location that doesn't exist. (The actual problem was that I'd mistyped "go 81000000" as "go 81000" in the bootloader.)
See also:
http://www.keil.com/support/docs/3080.htm (KB entry on debugging data aborts)
http://www.ethernut.de/en/documents/arm-exceptions.html (list of ARM exceptions)
What's the address that the prefetch abort is triggering on. It can occur because the program counter (PC or R15) is being set to an address that isn't valid on your microcontroller (this can happen even if you're not using an MMU - the microcontroller's address space likely has 'holes' in it that will trigger the prefetch abort). It could also occur if you try to prefetch an address that would be improperly aligned, but I think this dpends on the microcontroller implementation (the ARM ARM lists the behavior as 'UPREDICTABLE').
Is the CPU actually in Abort mode? If it's executing the Prefetch handler but isn't in abort mode that would mean that some code is branching through the prefetch abort vector, generally through address 0x0000000c but controllers often allow the vector addresses to be remapped.