I got some crash reports in crashlytics which I don't understand at all, here's the crash log of the thread that crashed:
I don't find any hints to my code, nor is it something reproducable or only happening on specific devices. According to Crashlytics it's not a problem with RAM or disk space, so I'm really helpless here.
Does anyone have some hints with that stacktrace?
I have some thoughts:
The second line of the first row is the iOS way of saying what went wrong. It reads: EXC_BAD_ACCESS KERN_INVALID_ADDRESS. This is a Bad access error.
You're trying to _dealloc something, according to the stack trace listing a method, [_queueForDealloc:]. With iOS's ARC (Automatic Resource Counting) system, things in Xcode can't call alloc or release because of it allocating memory and releasing it automatically. This technology was released with iOS 5.
My guess is, the compiler really doesn't like that [_queueForDealloc:] method you may have called, or you're trying to dealloc something that has already been dealloc'ed. (See the third line: a call of -[_PFArray dealloc].)
Either way, this is a bad access error. Check what you're deallocating and whether or not you should be deallocating it.
Related
Am attempting to learn Swift and am building an audio application inside of OSX.
I am attempting to debug the code, and I am experiencing the following error:
ESX_BAD_INSTRUCTION(code=EXC_I386_INVOP,subcode=0x0) at runtime during debugging.
No further information is available from the debugger.
Now, of course I would normally be hard at work by this point googling for a solution, but there is more information...
The function in which this error appears is fairly large, and the debugger line is about 3 lines of code from the top of the function.
Problem is, that the crash happens way down inside the function - in the main loop, and after it has run over 80 times. The debugger appears to be moving its pointer back earlier in the code which is pretty confusing. I can confirm that the execution thread is way further on than the position in the code where the crash is being reported.
Due to the fact that the stack location is incorrect, all the debug variables are missing in the debugger.
Can the debugger be forced to report the correct stack location?
does anyone know why boost unique lock objects can only be instantiated on the stack and not on the heap?
This works perfectly:
boost::unique_lock<boost::mutex> lock1(mutex1);
:
wait_condition.wait(lock1);
But this causes a runtime crash on both Windows 7 & Windows 8 after compiling with mingw:
boost::unique_lock *lock1;
lock1 = new boost::unique_lock<boost::mutex>(mutex1);
:
wait_condition.wait(*lock1);
Thanks in advance
Many thanks Igor for your response. I'm using boost 1.52.0. The RAII statement made me think and then I realised what I should have realised before: Creating it on the heap means the lock never goes out of scope even after exiting the function where the unique_lock is created. When wait returns, it re-locks, without unlocking the heap-based lock when the function returns, causing deadlock. By crash in this context I meant "application freezing and not letting me close it".
The above problem is solved. However, I now have a new problem :-) After following the RAII paradigm and using the stack, my application still crashes once I have 25 child threads in a wait-state. I don't know why. Is there some Windows, boost or mingw limitation with over 25 threads waiting on a mutex? The over-25-thread crash is worse than above; it crashes properly with a Windows error: "The application was forced to close in an unexpected way". This doesn't happen with less than 25 threads...
Before some time i coded my own little db editor program, i was coding it from the zero using Win API's so its not very small project.
It was working fine on all OS till now, i have Win 7 x64 with all latest updates and my application is crashing with 0xC000005 exception because of some of the Heap functions(HeapAlloc or HeapFree, i use nothing else), i tried replacing HeapAlloc & HeapFree with VirtualAlloc and VirtualFree and it was all fine, but i dont want to use the virtual memory....
Something else, i tried to attach with debugger to trace the problem, but when i attach debugger its not crashing, then i tried to display MessageBox to trace where it crashes, but when i display MessageBox its not crashing too....
My application is running as 32bit process.
Coded in C.
Anyone had similar problem ?
Firstly, both HeapAlloc and VirtualAlloc allocate virtual memory.
My guess as to what is happening is that you are writing past the boundary of the allocated memory. The reason why this does not work with HeapAlloc is that it allocates exactly the amount of memory you request. With VirtualAlloc, the size returned is the requested size rounded up to the next page boundary. In your case, this gave a bit more leeway (even though your code is still doing the wrong thing).
In terms of why it has been working so far: you just got lucky. Look carefully at the code accessing the allocated memory and if you get stuck, post the relevant part up here. If the debugger isn't helping and the bug is easily reproducible, just comment out parts of the code until you locate the line causing the crash.
Have you attached it to Debug version of your application? If the problem does not appear in debug version then you should check what warnings (on highest level) generate your code, maybe you will find some uninitialized variables. If nothing here, then you might use some static analysis tool to help with finding bugs - like PVS-Studio http://www.viva64.com/.
You can also compile Release version with debugging information enabled, this way when problem arrises you should be able to attach to your application with debugger and see callstack with function names. To make it easier to debug, disable code optimizations.
You can also try gflags from windows debugger tools, this program will trigger breakpoint each time you write outside of buffer boundary. This is really helpfull tool because not all buffer overruns end up with exceptions. Use it on application with debugging information enabled, and preferably with code optimizations off. To enable gflags for your app use:
gflags /p /enable myapp.exe /full
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff543097%28v=vs.85%29.aspx)
In Xcode 4.x I've edited my Run scheme to 'Enable Guard Malloc' since I have a nondescript malloc error I need to track down. I'm aware I need to run in the simulator to use this feature. However, when I do so the app immediately freezes and Xcode shows me a stack trace that looks like this:
I've googled around to find a solution, but thus far no joy. It was reported elsewhere that I should be setting an environment variable in my scheme:
DYLD_INSERT_LIBRARIES -> /usr/lib/libgmalloc.dylib
However this doesn't solve the problem. I have also tried 'lsystem' as the value, but that didn't work either.
Can anyone suggest a solution to this dylib issue, or perhaps recommend an alternative to 'Enable Guard Malloc' to identify where a malloc'd heap area is being exceeded?
UPDATE
To clarify, this is the type of error I'm dealing with:
malloc: *** error for object 0x2b4b54: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
I've tried setting a symbol breakpoint of malloc_error_break, however it still breaks 'randomly' upon memory issues rather than at the point of exceeding an allocated region.
To help with the debugging you can set MallocStackLogging, then when your App crashes, type this in the gdb console:
(gdb) info malloc-history 0x543216
Replace 0x543216 with the address of the object that caused the crash, and you will get a much more useful stack trace and it should help you pinpoint the exact line in your code that is causing the problem.
See this article for more detailed instructions.
Short Q.: What does this exception mean? "EXC_BAD_ACCESS (0x0001)"
Full Q.: How can I use this error log info (and thread particulars that I omitted here) to diagnosis this app crash? (NB: I have no expertise with crash logs or OS kernels.)
In this case, my email client (Eudora) crashes immediately on launch, every time, after no apparent system changes.
Host Name: [name of Mac]
Date/Time: 2008-09-28 14:46:54.177 -0400
OS Version: 10.4.11 (Build 8S165)
Report Version: 4
Command: Eudora
Path: /Applications/[...]/Eudora Application Folder/Eudora.app/Contents/MacOS/Eudora
Parent: WindowServer [59]
Version: 6.2.4 (6.2.4)
PID: 231
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000001
To answer your short question: EXC_BAD_ACCESS means an illegal memory access. This means that the program tried to use a memory location outside its virtual address space (roughly speaking, the area of memory it has requested from the OS kernel). This is what Unix people typically call a "segmentation fault" (segfault), and what Windows people typically call an "access violation" (AV) or "general protection fault" (GPF). (Yes, you probably already knew that. But I'm just making sure...)
Does the crash report say what memory address was being referenced? Does the report include the call stack or a core dump? All three are very valuable, especially the core dump as you can load it into the debugger and restart the program right from the point of the exception. And if the memory address seems totally out of whack (in the higher half of the virtual address, or very close to 0, then you have a good clue where the problem lies).
Just to complete Michael's answer - analyzing the crash log is not what you are supposed to do. The eudora programmers screwed up (or the people providing the tools the eudora programmers use to make eudora). The best thing you can do is copy and paste the entire contents of the crash log in to a mail client (try MAIL, as you can't seem to use eudora, right now, hahaha), and send it to eudora-support#eudora.com along with a short description of what's happening. It's their job to figure out what went wrong.