Endless loop of First Hand Exceptions
in [Visual C]
|
Prev: Create status bar
Next: Combo Box Special Style
From: chhenning on 10 Feb 2010 17:26 Hi there, I realize that my question probably cannot being answered from this forum. But what I'm looking for is some guidance on how to tackle my problem. For some reason I believe my c++ runtime is messed up. The reason I say that is that I get an endless loop of the following message when calling fflush(...): First-chance exception at 0x8018c470 in WorkerHost.exe: 0xC0000005: Access violation at location 0x000000008018c470. The code I using to trigger this problem is simply this: FILE* f = fopen( "c:\\remove.txt", "w" ); fwrite( "Hello", 1, 5, f ); fflush( f ); fflush() function never returns. I have tried using ofstream from the STL but same thing in the end. Only when I use Win32 calls like CreateFile(), WriteFile(), etc. I have no problems. This only occurs in my debug build and not in my release build. Also, the problem does not occur with a simple Hello World program. The application I'm trying to debug is a rather big one. Basically a .net executable is forking of a C++ com module to do some work. I believe this problem started to occur when I upgraded my VS2005 with the SP1. Since then I have rebuild all the dependencies of my application to avoid potential problems with having to deal with different runtime linked with different modules. But no luck. Is there anyone out there who could give me some hints on what I can do about this? Also, in case this is the wrong forum please refer me to the correct one. Thanks a lot, Christian
From: Ulrich Eckhardt on 11 Feb 2010 03:14 chhenning wrote: > For some reason I believe my c++ runtime is messed up. The reason I > say that is that I get an endless loop of the following message when > calling fflush(...): > > First-chance exception at 0x8018c470 in WorkerHost.exe: 0xC0000005: > Access violation at location 0x000000008018c470. So, for the record, you are on a 64-bit system. > The code I using to trigger this problem is simply this: > > FILE* f = fopen( "c:\\remove.txt", "w" ); > fwrite( "Hello", 1, 5, f ); > fflush( f ); Assuming 'f' isn't NULL, the code is fine. > fflush() function never returns. I have tried using ofstream from the > STL but same thing in the end. Streams come from the IOStreams library, not from the STL. What you mean is the C++ standard library. ;) > Only when I use Win32 calls like CreateFile(), WriteFile(), etc. I > have no problems. fopen() and std::fstream are basically wrappers around CreateFile() etc, so I share your guess that the runtime might cause it. > This only occurs in my debug build and not in my release build. Also, > the problem does not occur with a simple Hello World program. That again speaks against the runtime but rather for the abuse of the runtime. > The application I'm trying to debug is a rather big one. Basically a > .net executable is forking of a C++ com module to do some work. > > I believe this problem started to occur when I upgraded my VS2005 with > the SP1. Since then I have rebuild all the dependencies of my > application to avoid potential problems with having to deal with > different runtime linked with different modules. But no luck. Generally I would: * Revert to a known good state using the version control system (or a backup) and try again. If that works, jump to a state in the middle and try if it breaks there etc, until you have the commit that caused the problems. * Deactivate stuff until it stops breaking, until you find the parts that breaks things. Might be difficult in your case though. Specifically I would: * Check where the debug/release configurations differ. * Verify that the e.g. the default alignment and packing and the default calling convention isn't touched in the project settings or some headers. * Try to create a thread using _beginthread and see if it works in that thread. This would be a hint that some initialisations are not performed or not performed correctly. Good luck! Uli -- C++ FAQ: http://parashift.com/c++-faq-lite Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
From: chhenning on 11 Feb 2010 10:23 Hi Uli, > > > First-chance exception at 0x8018c470 in WorkerHost.exe: 0xC0000005: > > Access violation at location 0x000000008018c470. > > So, for the record, you are on a 64-bit system. Sorry, I forgot to state that. Yes I'm working on with 64bit code. > > Streams come from the IOStreams library, not from the STL. What you mean is > the C++ standard library. ;) Details details. ;-) > > > Only when I use Win32 calls like CreateFile(), WriteFile(), etc. I > > have no problems. > > fopen() and std::fstream are basically wrappers around CreateFile() etc, so > I share your guess that the runtime might cause it. > > > This only occurs in my debug build and not in my release build. Also, > > the problem does not occur with a simple Hello World program. > > That again speaks against the runtime but rather for the abuse of the > runtime. > > > The application I'm trying to debug is a rather big one. Basically a > > .net executable is forking of a C++ com module to do some work. > > > I believe this problem started to occur when I upgraded my VS2005 with > > the SP1. Since then I have rebuild all the dependencies of my > > application to avoid potential problems with having to deal with > > different runtime linked with different modules. But no luck. > > Generally I would: > * Revert to a known good state using the version control system (or a > backup) and try again. If that works, jump to a state in the middle and try > if it breaks there etc, until you have the commit that caused the problems. > > * Deactivate stuff until it stops breaking, until you find the parts that > breaks things. Might be difficult in your case though. > > Specifically I would: > * Check where the debug/release configurations differ. > * Verify that the e.g. the default alignment and packing and the default > calling convention isn't touched in the project settings or some headers. > * Try to create a thread using _beginthread and see if it works in that > thread. This would be a hint that some initialisations are not performed or > not performed correctly. Thanks for all of these advises. I'll try them all. Once I'm done I'll post a summary to this forum. > > Good luck! Thanks! Christian
From: Tamas Demjen on 11 Feb 2010 17:36 chhenning wrote: > The code I using to trigger this problem is simply this: > > FILE* f = fopen( "c:\\remove.txt", "w" ); > fwrite( "Hello", 1, 5, f ); > fflush( f ); > > > fflush() function never returns. It's possible that some internal data structures have become corrupted earlier. These random access violations are hard to find, they could be coming from another thread, or a different DLL altogether. Buffer overrun is not the only thing that can corrupt memory. Uninitialized variable, writing to deleted objects, calling functions in an unloaded DLL can cause that, too. If you use COM, it's enough to forget about calling AddRef before you hold onto an object, and it can cause the object to be destroyed while you're still using it. > Basically a .net > executable is forking of a C++ com module to do some work. You mention .NET, which makes things even tougher, because of the unpredictability of the garbage collection. If you pass a pointer from .NET to native code and forget about pinning it, your data could be collected away at any moment. Debugging native COM objects from .NET is disastrous, as you have no control over when the GC calls Release on them. An unused COM object can live for minutes without being released. Once I had an AddRef missing, and the crash happened a few million lines after the COM object was last used, because that's when the GC decided to release the native object. While debugging you can call GC.Collect before crossing into native boundary, or simply use C++ to debug COM object. This helps removing the non-deterministic behavior. Data misalignment can be another source of problems. If sizeof(MyData) doesn't match in the different DLLs, you can expect random crashes to occur anywhere, including fflush. The bottom line is your 3-line code probably has nothing to do with the crash. The real source of the problem could be 100s of lines earlier. Tom
From: chhenning on 12 Feb 2010 15:32
Thank you Tom and Brian. I'm afraid to say that but my problem just disappeared. This is somewhat unsatisfying since I know it will come back one day. These problems always do. ;-) My last action was installing Application Verifier and then I couldn't reproduce the error. Next time I'm having this problem I'll save my debug output to compare to being able to compare with the working state. Christian |