I already searched the web for a while but it appears my problem is very rare:
I'm programming a Audio Unit Plugin with JUCE in C++.
When I run it in a host, the host crashes. When I attach the XCode debugger to the hoist before loading my plugin, it points me to the following:
error: address doesn't contain a section that points to a section in a object file
If I type "bt" into the debug console, it says:
* thread #1: tid = 0x1f03, 0x00000000, stop reason = EXC_BAD_ACCESS (code=2, address=0x0)
frame #0: 0x00000000
I don't get a stack trace, making it impossible to find the source of the bug. It would help a lot to see, what was executed right before the bad access happened, but I can't figure out how.
I can set a breakpoint somewhere in the program and from there slowly make my way through the code until I reach the crash. I did this and eventually the execution leaves my source code and I get the assembly lines. I can see it jumping out of a lot of calls with the "ret" command. Eventually on one "ret" command, the crash occurs.
The assembly code is from the host that runs my plugin. But the crash appears on different types of host so I'm pretty sure, its a fault on my side. Any ideas?
Thank you!
Related
This one is really frustrating, I have no idea where it is coming from.
A little backstory
I am working on my chess game in c++, and currently I'm on the chess engine part. Everything is going on well, suddenly, at this very specific position of pieces on the board, this error comes
Process returned -1073741819 (0xC0000005) execution time : 2.049 s
Press any key to continue.
It comes during the calculation on the moves, it just stops in the middle and shows this error. The project itself isn't small. I haven't been able to narrow this error down to any of the functions, it just happens. I have read a lot about it and I have seen it being related to pointers?, I am not using them in my program, What can I do to start solving this issue?
I don't really know where the error comes from so I have no idea what code I can provide here.
I am using The Code::Blocks IDE with mingw compiler
If you're on linux and have command line executable, you can follow below steps
Run your executable inside gdb ( gdb ./your_executable )
Start running your executable by run command
This will crash your program inside gdb env.
Now enter where command to know full back trace of crash
You can also apply break point to that function ( break "fun_name" ) after knowing the location of crash and monitor its stack contents by entering bt full
I have an crash issue with one of our customers, and I managed to acquire the logs with adplus -pmn utility, running in monitor mode so that it monitors the process during the crash.
Once I inspected the dump, it shows me the following:
WARNING: Frame IP not in any known module. Following frames may be wrong
The dump file has an access violation. But the callstack only has functions from IE javascript engine.
I am trying to get the correct callstack, and I noticed this article from 2011 that explains the virtual address space in windows, and apparently my program is in another address space.
Any approach on getting the call stack from this crash?
Highly appreciate it.
My understanding is that gdb can monitor the complete state of a running program. Can I save a gdb session that is paused at a breakpoint and resume the session later?
My first attempt was simply generating a core dump in a first gdb session that was paused at a breakpoint and then using the core dump to start a second gdb session.
Saving core file in gdb
This resulted in the following error.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
So breakpoint information is inserted into the program state, interesting. On my second attempt I did the same but this time I added the same breakpoint to the second session as were in the first session.
Getting gdb to save a list of breakpoints?
Still, I get the same error.
Can I save and restart a gdb session? If so, how?
I don't think this is directly relevant but I'm also getting this warning.
warning: core file may not match specified executable file.
Is gdb simply stating that such a thing is possible in general or does gdb believe this may have happened in the running session? I'm confident that the same executable that produced the core dump is being run under gdb.
Edit: For anyone else who comes along, this question: Save a process' memory for later use? adds to Mats Petersson's answer and links to this article: http://blogs.msdn.com/b/oldnewthing/archive/2004/04/20/116749.aspx which is an interesting read. The linked question also has the suggestion of wrapping the process up in a VM.
I doubt that will ever work. Handles for files and any other resources (semaphores, shared memory, serial ports, network connections and lots of other things) that the program has opened/created will be lost when you save the core-file. You can inspect it, but you can't "continue". A core-file is simply a copy of all the memory that original program was using. Anything else is "lost" when the program terminates. In other words, a core-file will only be useful to inspect things later on, but you can't run, step or continue in a core-file debug session. Only "look at things". And if you can't execute, breakpoints won't really work either... ;)
Well. that´s the question. Just that.
I got an app made with SDL and OpenGL. SDL opens an extra window (which is the console) additional to the graphical one. When i execute i´m getting a 3 output error, the console tells me. And it gets closed (the graphical one).
But i know this happens when a SIGSEGV signal is received (don´t know how to capture it) and it appears in my IDE (Code::blocks) while debugging. But this time nothing appears, and everything works all right. But when executing it crashes..
What the...
What kind of error can i expect?. Sometimes it gets closed, sometimes it doesn´t. How to know what kind of problem i got?.
SIGSEGV is a segmentation fault, you're trying to access memory that isn't accessible to your process.
Assuming you're on a UNIXy system, you should be able to get the program to core dump and then look at the core dump in a debugger; alternatively, use a memory debugger like Valgrind to pinpoint the memory management issue that's causing this problem.
Here's the situation:
Background
I have a mixed mode .NET/Native application developed in Visual Studio 2008.
What I mean by mixed mode is that the front end is written in C++ .NET which calls into a native C++ library. The native code does the bulk of the work in the app, including kicking off new threads as it requires. The .NET code is just for UI purposes (win forms).
I have a release build of application running on a tester's computer.
The native libraries were compiled with full optimisations but also with debugging enabled (the "Debug Information Format" was set to "Program Database").
What this means is that I have the debugging symbols for the application in a PDB file.
The problem
So anyway, one of the testers is having a problem with the app where it occasionally crashes on XP. I've been able to get the minidump of the crash using Dr Watson for several runs.
When I debug into it (using the minidump - I'm not actually debugging the real app), all the debugging symbols are loaded correctly: I can see the full stack trace of all of the native threads correctly. Other threads (which are presumably the .NET threads) don't have a stack trace, but they all at least show me which dll the thread was started on (i.e. ntdll.dll).
It correctly reports the thread which fails ("Unhandled exception at 0x0563d652 in user(5).dmp: 0xC0000005: Access violation reading location 0x00000000).
However when I go into the thread it shows nothing useful. In the stack trace there is a single entry which just has the memory address "0563d652()" (not even "ntldll.dll").
When I go into dissasembly it just shows a random section of about 30 instructions. Either side of the memory address is just "???". It almost looks like it is not part of my source code (isn't your binary loaded sequentially into memory? is it normal to have a random set of assembly statements in the middle of nowhere?).
My questions
So basically my questions are threfold.
1) Can anyone explain the debugger's lack of information?
2) Bearing in mind, I can't show the error occurred in my code, can anyone suggest a reason for the failure
3) Can I do anything else to help me diagnose this current problem in the future?
Help!
John
Update:
Here is the stack dump for the failing thread from WinDBG
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 099bf414 02d0e7fc 0x563d652
01 00000000 00000000 0x2d0e7fc
Weird huh? Doesn't even show a DLL.
Is it possible that I've corrupted the stack/heap somehow which has caused a thread to just get corrupted...?
Are you using WinDbg? If so, are you using the Son of strike extension?
Bugslayer: Son-of-Strike
-or-
Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects?
We had an issue similar to this where a code bug was silent in MSVC2K5 SP1, but if you had the MSVC2K5 SP2 runtime installed it caused an error which didn't point at valid code.
Part of the problem is, when you start executing data as code you could be doing anything and so the crash location becomes useless as you cannot even get back to a valid stack trace.
We had this happen to us when the new .Net runtime install installed a newer version of the MSVC C++ Runtime in the SxS directory.
In the end our method to resolve the issue was to make the crash happen frequently and add as much logging as necessary to localize it.
could you post the stack of the faulting thread once you've grabbed and installed a copy of windbg and opened the dump file there?
we could start from there.
Your EIP was just corrupted.
Assuming the ESP is valid, you can view the callstack, just type:
dds esp [enter]
dds [enter]
You can also use the memory windows:
Set address to: esp
Set format to: Pointer&Symbol