I'm running a computationally intensive task that reads data from the viewfinder using UIGetScreenImage and does computations on it, repeatedly. After about 60 seconds (on 3GS) I'm getting a crash every time. But I can't debug it, because I get this:
Program received signal: “0”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")
(gdb) continue
The program is not being run.
And at this point I'm toast, the stack trace is all blank.
I've used Instruments, object allocations, allocations, activity monitor, and they all show that I'm not leaking. In activity monitor for example physical memory used rises from 77MB to to 112 MB and stays there (up and down a bit) until the crash.
Anyone have an idea of what to try?
You might have some recursion that's got a bit out of control?
I've seen your symptoms happen when I've accidentally call a setter from within a setter i.e.
-(void)setX:(int)value {
self.x = value; //!< Oops, accidentally called this method again :(
}
and you get odd errors from the debugger because you've broken the stack. Don't know how this answer helps you find the error though :(
Are you using any version control at all - I'd fix this by stepping back though your changes and finding the change that causes the bug?
Related
I made a breakpoint in Xcode with the jump commend to force passing some condition, but when it execute to line 168 it crash with message
"Thread 1: EXC_BAD_ACCESS (code=1, address=0x1)"
why did that happen?
the console logged:
warning: MoreMultitypeCollectionViewCell.swift:178 appears multiple times in this function, selecting the first location:
MoreMultitypeCollectionViewCell.(updateButtonStateCkeck in _9A12557DCAB30EEB52DC7C2EA09487CD)() -> () + 1580 at MoreMultitypeCollectionViewCell.swift:178
MoreMultitypeCollectionViewCell.(updateButtonStateCkeck in _9A12557DCAB30EEB52DC7C2EA09487CD)() -> () + 1600 at MoreMultitypeCollectionViewCell.swift:178
my questions are:
How should I type in lldb to select location?
Is there a better way to force passing into If Statement without change code and rebuild project?
sometimes when I type 'po' in lldb or click print description in variable view, it will show fail message, how is that?
1) In lldb, the equivalent command is thread jump and you can specify an address as well as a line number there.
2) thread jump or the Xcode equivalent is an inherently dangerous operation. If you jump over the initialization of some variable, you will be dealing with bad data now and will likely crash. That sort of thing you can sometimes spot by eye - though Swift is lazy about initialization so the actual initialization of a variable may not happen where you think it does in the source. There are more subtle problems as well. For instance, if you jump over some code that as a byproduct of its operation retains or releases an object, the object will end up under or over retained. The former will cause crashes, the latter memory leaks. These retains & releases are generated by the compiler, so you can't see them in your source code, though you could if you look at the disassembly of the code you are jumping over.
Without looking at the code in question, I can't tell why this particular jump caused a crash.
But you can't 100% safely skip some of the code the compiler choose to emit. Looking at the disassembly you might be able to spot either (a) a better place to stop before the jump - i.e. stop past some retain or release that is causing a problem or jump to an address in the middle of a line so you still call a retain that's needed. You'll have to figure this out by hand.
3) There's not enough info to answer this question.
BTW, your image links don't seem to resolve.
I have a wxWidgets/GTK based application that works well - except for one installation on an Debian Squeeze ARM system. There it crashes when the user just activates the main window of it. To find the reason for that I added a signal handler to the application and use libunwind out of that signal handler to find the source for the crash. During a test that worked fine, when the software writes e.g. to address 0x0 libunwind correctly points me to the function where that happens.
But the results for the system where the crash appears unexpectedly are a bit strange, they seem to happen outside of my application. One crash comes from a function with no name (here libunwind returns an empty string), and one is caused by "malloc_usable_size", a system function which should never die this way.
So...what to do next? All ideas, suggestions or any other hints are welcome since I'm not sure how to contunue with that problem...
Check for buffer overrun or overwriting some memory unexpectedly for any structures, pointers, memory locations for items returned by library functions.
Check for invalid pointer frees in your code for the library allocated pointers that you are using.
May be using valgrind would also help.
I've seen a few different types of crash logs since I begin learning iOS development.
I know that:
Exception Type: EXC_BAD_ACCESS (SIGSEGV) mean we are accessing a released object.
but don't know about:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Type: EXC_CRASH (SIGABRT)
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Do you know how many Exception Types in iOS crash logs and what do they mean?
I know that: Exception Type: EXC_BAD_ACCESS (SIGSEGV) mean we are accessing a released object.
No.
A SIGSEGV is a segmentation fault, meaning you are trying to access an invalid memory address.
Those exceptions (in fact, they are signals) are not related to Objective-C, but C.
So you can get such an exception without Objective-C objects.
Note that a signal is not an exception, meaning you can't catch them with #try and #catch blocks.
You may set a signal handler with the signal and sigaction functions. Keep in mind some signals, like SIGABRT cannot be blocked.
You can check the Wikipedia page about signals, if you want more informations.
That said, to resume:
SIGSEGV (Segmentation fault)
Access to an invalid memory address. The address exist, but your program does not have access to it.
SIGBUS (Bus error)
Access to an invalid memory address. The address does not exist, or the alignment is invalid.
SIGFPE (Floating point exception)
Invalid arithmetic operation. Can be related to integer operations, despite the name.
SIGPIPE
Broken pipe.
SIGILL
Illegal processor instruction.
SIGTRAP
Debugger related
SIGABRT
Program crash, not related to one of the preceding signal.
SIGSEGV literally means you're accessing an address you don't own. So it's not necessarily that you're accessing a released object; you could be accessing an object that never existed, as in:
UIView *view; // uninitialised, could point to anything
[view setFrame:someFrame];
Or even just making an error in C-level non-object stuff, such as:
int array[100];
array[1000] = 23; // out-of-bounds access
SIGBUS is very similar to SIGSEGV, the difference being at the hardware level (usually the difference between trying to access an address that does exist but which you don't own and trying to access an address that doesn't have anything behind it, but that's not a strict definition), but is usually associated with the same sort of errors, though a SIGBUS is much more likely to be to do with an uninitialised variable than a SIGSEGV.
If you're trying to map to errors you probably made in Objective-C, you probably just want to read SIGSEGV and SIGBUS together as meaning "a memory access I didn't have the right to make".
SIGABRT is a program attempting to abort itself, so it usually means that some sort of internal consistency check has failed. For example, SIGABRT is raised if you try to free the same memory twice, or — at the Cocoa level — if you raise an NSException that isn't caught. If you get a SIGABRT, you've done something wrong that is detected by the system software (in contrast to SEGV and BUS, which arise in hardware).
SIGTRAP is a call out from the program to a debugger. Anecdotally, Apple seem to use these when you do something wrong that can be detected in software but relates to the environment rather than your specific code. So, for example, you call a C function that exists in the SDK you built with but not on the device you are running on (such as when you build against the latest SDK with a lower deployment target), or do a similar thing with an object.
These messages are from gdb, and they are not exclusive for objective-C.
To get info about the signals all you have to do is enter info signals at the debugger console, this is an example output. Sorry for no posting it here, but the format of the console output is awful.
Source and more info about signals
I've recently studied this topic area and here is my summary:
EXC_BAD_ACCESS (SIGSEGV) or
EXC_BAD_ACCESS (SIGBUS)
Our program most likely tried to access a bad memory location or the address was good but we did not have the privilege to access it. The memory might have been deallocated due to memory pressure.
EXC_BREAKPOINT (SIGTRAP)
This is due to an NSException being raised (possibly by a library on our behalf) or _NSLockError or objc_exception_throw being called. For example, this can be the Swift environment detecting an anomaly such as force unwrapping a nil optional.
EXC_BAD_INSTRUCTION (SIGILL)
This is when the program code itself is faulty, not the memory it might be accessing. This should be rare on iOS devices; perhaps a compiler or optimizer bug, or faulty hand written assembly code. On Simulator, it is a different story as using an undefined opcode is a technique used by the Swift runtime to stop on access to zombie objects (deallocated objects).
EXC_GUARD
This is when the program closed a file descriptor that was guarded. An example is the SQLite database used by the system.
I have a matlab script, that every now and them produces the message:
Caught std::exception Exception message is:
bad allocation
Unexpected error status flag encountered. Resetting to proper state.
What could be causing this?
This is a bug in MATLAB, in which some part of MATLAB is not handling a std::bad_alloc exception correctly (std::bad_alloc is an out-of-memory exception thrown from the C++ runtime library).
The "Unexpected error status flag encountered. Resetting to proper state." is an internal diagnostic - you shouldn't see it unless MATLAB has gotten into a bad state, which in this case is happening because it's encountering the bad_alloc someplace where it was not expected. Recent versions of MATLAB have fixed most of these issues, except in extremely low-memory situations (like, there's less than 1 kilobyte of free memory left). What version are you using?
My best guess is that your script is trying to allocate some memory and failing. The occurrence of such an error will depend on the availability of memory on your computer at the time allocation is attempted. The available memory will vary according to what is going on at the time in other programs, the operating system, even the state of your Matlab session.
For a more accurate diagnosis, you'll have to tell us more, maybe even post your script.
It was happening to me, and it turned out I had too many files open. fclose('all') set everything back to normal, and I made sure that all my fopen were followed by fclose.
In my systems programming class we are working on a small, simple hobby OS. Personally I have been working on an ATA hard disk driver. I have discovered that a single line of code seems to cause a fault which then immediately reboots the system. The code in question is at the end of my interrupt service routine for the IDE interrupts. Since I was using the IDE channels, they are sent through the slave PIC (which is cascaded through the master). Originally my code was only sending the end-of-interrupt byte to the slave, but then my professor told me that I should be sending it to the master PIC as well.
SO here is my problem, when I un-comment the line which sends the EOI byte to the master PIC, the systems triple faults and then reboots. Likewise, if I leave it commented the system stays running.
_outb( PIC_MASTER_CMD_PORT, PIC_EOI ); // this causes (or at least sets off) a triple fault reboot
_outb( PIC_SLAVE_CMD_PORT, PIC_EOI );
Without seeing the rest of the system, is it possible for someone to explain what could possibly be happening here?
NOTE: Just as a shot in the dark, I replaced the _outb() call with another _outb() call which just made sure that the interrupts were enable for the IDE controller, however, the generated assembly would have been almost identical. This did not cause a fault.
*_outb() is a wrapper for the x86 OUTB instruction.
What is so special about my function to send EOI to the master PIC that is an issue?
I realize without seeing the code this may be impossible to answer, but thanks for looking!
Triple faults usually point to a stack overflow or odd stack pointer. When a fault or interrupt occurs, the system immediately tries to push some more junk onto the stack (before invoking the fault handler). If the stack is hosed, this will cause another fault, which then tries to push more stuff on the stack, which causes another fault. At this point, the system gives up on you and reboots.
I know this because I actually have a silly patent (while working at Dell about 20 years ago) on a way to cause a CPU reset without external hardware (used to be done through the keyboard controller):
MOV ESP,1
PUSH EAX ; triple fault and reset!
An OUTB instruction can't cause a fault on its own. My guess is you are re-enabling an interrupt, and the interrupt gets triggered while something is wrong with your stack.
When you re-enable the PIC, are you doing it with the CPU's interrupt flag set, or cleared (ie. are you doing it sometime after a CLI opcode, or, sometime after an STI opcode)?
Assuming that the CPU's interrupt flag is enabled, your act of re-enabling the PIC allows any pending interrupts to reach the CPU: which would interrupt your code, dispatch to a vector specified by the IDT, etc.
So I expect that it's not your opcode that's directly causing the fault: rather, what's faulting is code that's run as the result of an interrupt which happens as a result of your re-enabling the PIC.