I have a access violation at the exit of my MFC based VS 2005 C++ application. It uses MFC as a shared library and multibyte char set options. The call stack reveals the functions like
CAfxStringMgr::Free(ATL::CStringData * pData=0x00e07c47) Line 154 + 0x9 bytes C++
__crtExitProcess
doexit()
exit()
__tmainCRTStartup()
WinMainCRTStartup()
How to resolve this?
You could try to use the ATL/MFC Trace Tool to diagnose the problem.
Related
I am a java developer trying my hands on C-C++ code.
Basically I have some build script that uses Visual Studio components to build the application libraries - dlls. We do not use Visual Studio IDE to debug.
But whenever we face some crash in our application, we have to enter the debug statements line by line and need to check the exact line of code in which it is crashing.
Is there any API in C/C++ which would write the stack trace into a file during the crash of our program?
Some kind of event listener that would be called during a program exit and that could print the stack trace and error information into a log file.
I have seen many questions related to this but I am not able to get how to handle this in code rather than debugging tools. I feel Java is very much advanced with respect to error handling.
Thanks in advance!
The Standard does not give you any facilites for this. That said, you can use OS-specific APIs to get what you want. On windows, the easiest is probably to use StackWalker. You do need to take care of SEH oddities yourself. I suggest this article for more information.
On POSIX platforms, you can use the backtrace function from glibc.
In general, both require your program to be compiled with debug information. It is also possible to create crash dumps without symbol names (see Minidumps on Windows), but you will need to decode them (which Visual Studio does for you for example, but you mentioned in your post that you don't use it).
Also, keep in mind that writing crash dumps from a crashing process is very error-prone (since you really have no idea what state your application is at that time). You might get more reliable results if you write the crash dumps from another process. Earlier I've put together a simple example out-of-process crash handler that demonstrates how to implement that.
You can use std::set_terminate to define a function to be called when an exception leaves main() additionally you can install a signal handler for SIGSEGV to catch segmentation faults.
You can get a stack trace (on Linux) using libunwind ( http://www.nongnu.org/libunwind/ ) or use the backtrace() function from libc.
One thing I sometimes do in my own exception classes is to grab and store a stacktrace in the constructor that I can then obtain where I catch the exception and print the trace of where it was thrown from.
You could use <errno.h> in C to handle your error and log them into a log file. The standard flux for the errors is stderr.
One solution to get the error is to use the function perror included in <errno.h> that will display the exact error.
To use it, put it in an error catcher.
if (!fileIsOpen())
perror("File not opened");
I hope it helped.
I have made a DLL with VC++ 2008 and when i use it in console application VC++ 6.0, there is an exception:
(msvcr90.dll): 0xc0000005: Access Violation
Access Violation in this case can mean so many things, and the msvcr90.dll reference can be very much misleading. If you pass invalid data to any of the MSVC standard library functions, the access violation will occur within msvcr90.dll and not in your code (when viewing the stack trace or looking at the exception info.
That said, there should not, in theory, be a problem using a VC9 DLL in VC++ 6, as the ABI has not changed and the PE format is the same. You might have problems if msvcrt9.dll is unsupported on your platform (for instance if you're running MSVC6 on Windows NT), but otherwise it means you need to review your code.
What I mean is: attach a debugger and look at what's happening beneath the scene!
One more note: when using different versions of the MSVC libraries dynamically, you MUST NOT allocate data in one library and free it in another as they are not guaranteed to be using the same heap and you can get memory corruption (and Access Violation errors) rather easily like this. This also means that if you're writing C++, you must not create an object and then pass it by return value to the calling app as that's what will happen beneath the scenes.
If you want to build a DLL with Visual C++ version X and use it in Visual C++ version Y, you have some options:
Build a DLL which exposes a pure C interface. You can use C++ inside the DLL, but the public interface must be pure C (so, for example, you can't throw exceptions crossing DLL boundaries).
Build a COM DLL (possibly with the help of tools like ATL).
Build a DLL using COM-like techniques, i.e. expose only abstract interfaces and factory functions from your DLL (this technique is explained in this article on CodeProject "HowTo: Export C++ classes from a DLL", in particular in the paragraph "C++ Mature Approach: Using an Abstract Interface").
It is also important to point out that the code which allocates memory and the code which frees memory must use the same allocator.
Hello and thank you very much for your help!
In my c++ code I have some embedded assembler code and at the line [mov ecx,1AF858h] an error message keeps popping up saying "Access violation". It works perfectly with Windows XP but unfortunately not with Windows 7.
I don’t understand what causes the problem and I would like to know what I need to do to fix it.
Kind Regards, David
You need to use VirtualProtect/VirtualProtectEx to mark your byte array as executable or allocate it with VirtualAlloc using the correct flags (probably PAGE_READWRITE when writing the code and then PAGE_EXECUTE_READ). Note that it will probably need to be done on a page basis.
Is there a way catch an exception like access violation and get information about on which line an exception occurred? This would be very good for debugging purposes, especially for testers..
My environment is Windows with VC++ on VS2008
An access violation is not an exception in C++ terms, so the answer is in general "no". Concieveably, your specific implementation might have a feature that turns access violations into C++ exceptions - you need to specify what compiler & platform you are using.
In case you really want to log info about C++ exceptions (AV is not one) thrown from your code, you can use macros __FILE__ and __LINE__ within constructors of your exception types.
If you catch the SEH exception using a __catch handler you can then access the thread context at the time of the exception and then use StackWalk64 to dump the call stack at the point where the exception was generated. Note that as I mentioned here: Printing the stack trace in C++ (MSVC)? StackWalker by Jochen Kalmbach [MVP VC++] and available on codeproject is probably the easiest way to do this. It wraps up all of the details of dealing with the underlying StackWalk64 API.
Alternatively you could the same solution that I proposed here: How to catch divide-by-zero error in Visual Studio 2008 C++? to convert the Windows Structured Exceptions into C++ exceptions and capture the stack trace as shown above at the point where you translate the exception. This would give you a C++ exception with a stack trace like you get in C# or Java.
I'm not sure why testers would need to know which line an exception occurred.
The developers might want to know, though. But a better approach is the following:
Include the information about class and method with each PROGRAM exception. These are exceptions that should NOT have happened.
This should be output by whatever logs your exceptions. Your program does catch and log every exception, doesn't it? If not, it should.
Make sure your methods are small enough that the above is enough information to easy track down a bug. If you need line information as well, then your methods are too large and your exceptions are not specific enough.
In MSVC you can set the debugger to break when any exception or things like an access violation happen buy going to debug->Exceptions and checking the appropriate box.
Note that access violations are not C++ exceptions and will be handled differently on different systems. In Windows you can trap them with a structured exception handler. In unixy systems it will usually core dump. You can usually get a stacktrace from that.
For msdev / Windows, during development, always have your linker generate a MAP file.
When Windows throws up an access violation, and it's your code (not library), you can use the address to match up function / data in the MAP file and get within a few lines of the offender. At a minimum, you'll know the function/method.
That's really a compiler question.
If you want to know if it is possible for a compiler to provide, the answer is yes. I know multiple Ada compilers that provide tracebacks for unhandled exceptions, so it is clearly possible. This includes the gcc-based Gnat, so if the C++ compiler uses any of the same facilities for its exceptions, the support for doing that should already be there.
On unix type systems a Access violation generates a SEGV or BUS signal. This normally causes the application to core dump. You could always write your own signal handler. From there you could probably generate a stack-dump using the glibc before core dumping.
A core dump generally give you all this for wasy analysis in gdb.
My answer refers to Windows only. You have quite a few options:
Without changing your code -
Avoid catching exceptions (at least ones you do not expect), and let your app just crash. Configure good ol' dr. watson (drwtsn32.exe) to create a crash dump, and open that dump in your debugger. You'll get the exact line of code there.
Use adPlus (from the windbg installation) to monitor your app's run, and create a dump when an exception is thrown.
From within your code, you can -
Easily walk the stack when a structured exception is thrown. See Jochen Kalmbach's stack walker for example.
Use this weird hack to walk the stack when a C++ exception is thrown.
Finally, quite a lot of questions have been asked here on this issue. Look around, and you'll get additional answers.
On one project I worked on, the root class of the exception hierarchy used captured a callstack in the constructor in case that information was needed later for debugging after the exception was caught. It was a decent idea, although if you're catching and 'handling' the exception, exactly when it was thrown shouldn't really matter all that much.
To put it another way, if you care about this info (context of "who" threw it), you probably shouldn't be using an exception to report this condition, or potentially you shouldn't be catching the exception in the first place. Uncaught exceptions cause crashes, giving you a crash dump at the point the exception was thrown.
On windows, the C runtime system function _set_se_translator() takes a simple static function with signature
void f(int, EXCEPTION_POINTERS*)
neither of which argument you totally need. In the body of f, throw your favorite exception. Call the function near the beginning of your program. The documentation is reasonable for microsoft.
You can do all manner of additional stuff with this function.
The google breakpad project has many good things. Among them are means to convert a crash address to file, line, and function name using build symbols and the debuginfo dll.
Knowing an exception code, is there a way to find out more about what the actual exception that was thrown means?
My exception in question:
0x64487347
Exception address: 0x1
The call stack shows no information.
I'm reviewing a .dmp of a crash and not actually debugging in Visual Studio.
A true C++ exception thrown from Microsoft's runtime will have an SEH code of 0xe06d7363 (E0 + 'msc'). You have some other exception.
.NET generates SEH exceptions with the code 0xe0434f4d (E0 + 'COM').
NT's status codes are documented in ntstatus.h, and generally start 0x80 (warnings) or 0xC0 (errors). The most famous is 0xC0000005, STATUS_ACCESS_VIOLATION.
Because you're reviewing a crash dump I'll assume it came in from a customer and you cannot easily reproduce the fault with more instrumentation.
I don't have much help to offer save to note that the exception code 0x64487347 is ASCII "dShG", and developers often use the initials of the routine or fault condition when making up magic numbers like this.
A little Googling turned up one hit for dHsg in the proper context, the name of a function in a Google Book search for "Using Visual C++ 6" By Kate Gregory. Unfortunately that alone was not helpful.
If you know which block threw the exceptioon, can you put more specific handlers in the catch block to try and isolate it that way?
Are you throwing an exception that you rolled yourself?
Edit: I forgot to point you towards this article on Visual C++ exceptions which I've found to be quite useful.
Rob