WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
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
MinGW-users mailing list
Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
You may change your MinGW Account Options or unsubscribe at: