From: Keith M. <kei...@us...> - 2009-07-24 17:03:56
|
On Friday 24 July 2009 04:54:58 leledumbo wrote: > > Well, clean ANSI C don't exactly throw exceptions. > > Even via setjmp and longjmp? No. ANSI-C doesn't formalise *any* exception handling model. (The only references to exceptions, in the sense of abnormal condition traps, in the ANSI-C standard is to floating-point exceptions, but these aren't related to the C++ exception handling model). That GCC-C++ formerly offered a setjmp/longjmp exception model does not, in any way, imply that setjmp/longjmp relate exclusively to exception handling. Your fixation with exceptions is likely to be distracting you from the true cause of your problem. > > Have you tried GDB or WinDbg? > > Yes, GDB only tells segmentation fault ... So, your application is attempting to access memory outside of its allowed addressing range, or it is trying to write data into a read only data section. The single most common cause of the former segfault condition is any dereference of a NULL (likely uninitialised) pointer. Causes of the latter condition may be less obvious; here's an example of incorrect code, which will segfault when compiled with GCC, but may *appear* to work, if compiled with MSVC: . char *text = "some random text"; . strcpy( text, "new text" ); . > without a proper backtrace > (perhaps I didn't include the debug info correctly, I'll rebuild > and check) Have you tried *stepping* through your code, to locate the problem context? It is most likely that there is an invalid memory access bug in your code; newer versions of GCC are becoming more stringent in their rejection of invalid code, such as shown in the example above, (which would already fail with GCC-3.4). This increased intolerance of invalid code is a more likely explanation for the fault appearing with the newer GCC version, than the change in the C++ exception handling model, (*especially* when you aren't using C++ anyway). -- Regards, Keith. |