I've come across the below error. This error persists even if I try to use my code on another machine with same version of Xcode 4.2 final. Can any one help?
Console Output
error while killing target (killing anyway): warning: error on line 2184 of "/SourceCache/gdb/gdb-1708/src/gdb/macosx/macosx-nat-inferior.c" in
function "void macosx_kill_inferior_safe()":
(os/kern) failure (0x5x) quit
The debugger is crashing. Crashing debuggers are a world of pain.
Looks like you are using gdb. Try moving to lldb and see if that works around it.
If that doesn't, try nuking your derived data directory as it may be that you have a corrupt symbol that is causing the debugger to crash.
I have no idea what the error is, but googling for the file produces macosx-nat-inferior.c which describes itself as being a part of GDB. So assuming it is the same file as on your computer, then diving in to it may help solve your issue. However that message appears on line 1981 of the file I found .. so I doubt it is the same one as on your computer. But issues with GDB sound weird.
Related
I am running opencv 3.0's sample code hog.cpp (from the folder \samples\gpu\hog.cpp) for people detection, using the GPU. (the CPU part crashes for me). The code compiles, but when I run it, it crashes at the line:
gpu_hog->detectMultiScale(gpu_img, found);
Unhandled exception at 0x000007FEDE717A28 (opencv_core300.dll) in
Hog3StandAlone.exe: 0xC0000005: Access violation reading location
0x000002380000013C.
I am using visual studio 2012, Windows 7 Pro 64 bit.
There are quite a few things that can cause such a problem.
The code itself seems "fine".
What I suggest is that you compile the program in Debug mode. Then, run it from Visual Studio. The IDE's debug session should stop at the exact place in which the "access violation" happened. From there, you can have a more precise idea on the origin of the problem.
For example, I got similar problem at line #341
vc >> frame;
because the VideoCapture vc object returned corrupted frames.
Your problem might be similar (or completely different. That's why you should run a debug session in Visual Studio)
I've tried the same sample before and worked without any problems as far as I remember. On the other hand, this access violation is probably due to the fact that your input "gpu_img" is empty or corrupted. Make it sure that you read the frames correctly (you can use imshow function to visually examine) and also you upload it into gpu_img as well. I don't see any other possible explanation.
I have got a minigame.exe which crashes at some point inside the game. It does not show any error message and it just says Not Responding. I am using Win 7. I want to identify the crashing point and try to fix the games problem. I think the problem might be caused due to a specific DLL imported by the executable. However, I have no clue about how to find out that specific assembly line and try to patch the executable with OllyDBG.
With the information given, this answer would need a full tutorial style, which is considered as too broad for this site. But the first step, finding out what type of crash it is and where it occurs can be explained.
I'll use WinDbg as the debugger, since I'm not familiar with OllyDbg. It is is part of the Debugging Tools for Windows and it's freely available. Install the versions, x64 or x86, that matches minigame.exe.
Start WinDbg, use the correct bitness
Run minigame.exe under WinDbg (File/Open executable). It will stop at the initial breakpoint.
Set up the symbols, at least .symfix c:\debug\symbols and .reload. This will download information needed to construct the callstack.
Continue running the application with g
Reproduce the issue / wait until it crashes
When WinDbg stops,
create a crash dump with .dump /ma c:\debug\minigame.dmp so you can analyze it later, e.g. for asking questions here, so that you needn't reproduce the bug again.
get information about the exception with .exr -1
switch to the thread that caused the exception with ~#s
look at the callstack with k
Now you should have a better understanding of the crash, perhaps enough to apply a patch, maybe not. At least it's a better starting point for further exploration.
I've got an app that gets information from a SOAP web service and I want to display the results in a UITableView.
I had a previous version of this app and I'm creating a new version to basically clean things up and get rid of a bunch of legacy code that's deprecated and no longer used.
In the previous version, this worked well. In the new version, not so much.
Basically, the current scenario is returning 3 strings that I'm trying to use as the basis for the data in my UITableView.
I'm struggling with this issue because it's so stinkin' hard to track down EXC_BAD_ACCESS errors!
(Parenthetically, if someone has a way to make the debug experience more like Visual Studio, I'd love to hear it! It's so frustrating to not have any idea which line caused the error, and also to not be able to look through my local variables at the time of the crash to see what's what. I've already added in the exception breakpoint, but that doesn't seem to do much.)
Anyway, the line that's causing the error APPEARS to be:
return [[self Libraries] count];
It occurs in tableView:numberOfRowsInSection:.
The error message I get APPEARS to reference a string that should be stored in the NSMutableArray [self Libraries].
What's going on here?
I'm using ARC, so shouldn't all of my memory management be correctly handled?
I don't have any manual release statements in my code ANYWHERE!
Please help me fix this!
Set NSZombieEnabled, MallocStackLogging, and guard malloc in the debugger. 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.
ARC relies on the Apple standard/recommended naming practices. Check that you are not violating any of them.
Just for starters, if "Libraries" is an instance there are are naming issues.
OK, so I feel a little bit silly, but I've got two production machines. On one of them, I had installed a copy of Xcode 4.2 beta alongside the final, production copy. I forgot to uninstall the beta copy and was using it to run my code. As soon as I cleared that up and ran my code against the final, released Xcode 4.2, all works fine again.
As I mentioned to Jonathan Grynspan above, I DO understand Obj-C memory management. For some reason, I was getting a retain/release/release (performed by ARC), and that bug is remedied in the final version.
Thanks for the help in tracking this down! At least I got a definitive answer to WHY the problem existed!
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.
I was having some problems with memory (exc-bad-access) in Objective-C, XCode, for iPhone, so I searched a little bit and found about the (awesome) NSZombieEnabled. Everyone outhere is just explaining how cool this is ... but it doesn't work for me :/
I followed the following 'tutorial': http://www.cocoadev.com/index.pl?DebuggingAutorelease
I double clicked on the executable under the executable tab (left panel) and I added NSZombieEnabled=YES to the environmental variables
I also added a bunch of other options (like malloc history, some custom ~/.gdbinit that I found on the web, etc) but this didn't solve the problem
So basically when I launch (in debug mode) GDB sais
"Undefined command: "NSZombieEnabled". Try "help".
And it basically stops (in the status bar it says - error in GDB - terminating).
The problem is most likely in your ~/.gdbinit file in that the error you have provided indicates that gdb was trying -- and failing -- to parse a command.
In .gdbinit, the command should look like:
set env NSZombieEnabled=YES
To help further, you'd need to drop your .gdbinit in the question. However, there is rarely a need to use a .gdbinit file (for all but advanced debugging). I'd suggest deleting it.
For autorelease debugging, use Instruments....