[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-01 04:52 --- Subject: Re: [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions Yes, indeed. John Eaton sends apologies. Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 22:18 --- Apparently fixed in the original source. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-27 06:23 --- (In reply to comment #5) > (In reply to comment #0) > John Eaton's last word on the subject: __ Here is a fix for the Ctrl-C crashes Octave on Cygwin problem. My apologies to the GCC people for thinking this was a bug with GCC. jwe liboctave/ChangeLog: 2005-03-26 John W. Eaton <[EMAIL PROTECTED]> * cmd-edit.cc (do_readline): Wrap call to ::octave_rl_readline with {BEGIN,END}_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE. src/ChangeLog: 2005-03-26 John W. Eaton <[EMAIL PROTECTED]> * input.cc (gnu_readline): Don't wrap call to command_editor::readline with {BEGIN,END}_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE. Index: liboctave/cmd-edit.cc === RCS file: /cvs/octave/liboctave/cmd-edit.cc,v retrieving revision 1.23 diff -u -r1.23 cmd-edit.cc --- liboctave/cmd-edit.cc 25 Nov 2003 06:05:20 - 1.23 +++ liboctave/cmd-edit.cc 26 Mar 2005 17:53:14 - @@ -36,6 +36,8 @@ #include #endif +#include "quit.h" + #include "cmd-edit.h" #include "cmd-hist.h" #include "lo-error.h" @@ -192,7 +194,13 @@ eof = false; - char *line = ::octave_rl_readline (prompt.c_str ()); + char *line = 0; + + BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE; + + line = ::octave_rl_readline (prompt.c_str ()); + + END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE; if (line) { Index: src/input.cc === RCS file: /cvs/octave/src/input.cc,v retrieving revision 1.160 diff -u -r1.160 input.cc --- src/input.cc 4 Mar 2005 02:46:08 - 1.160 +++ src/input.cc 26 Mar 2005 17:53:27 - @@ -177,12 +177,8 @@ { bool eof; - BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE; - retval = command_editor::readline (s, eof); - END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE; - if (! eof && retval.empty ()) retval = "\n"; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-27 06:19 --- (In reply to comment #0) Recent correspondence between John Eaton and me. __ On 25-Mar-2005, Paul Thomas paulthomas2 at wanadoo dot fr wrote: | Well, we have a response on the more recent bug - it's a bit negative | insofar as the advice is don't do what you're doing - it might appear to | work but, in fact, does not. I have replied to say that I am consulting | with you and might or might not scrub the PR. OK. | > --- Additional Comments From rth at gcc dot gnu dot org 2005-03-24 | > 22:34 --- | > Sorry, but this test case is never going to work -- with either sjlj | > exceptions | > or unwind exceptions. By longjmp-ing from the middle of a catch clause, | > you've | > left the c++ library with live exceptions hanging around in global state. | > With | > unwind exceptions it may appear to work, but is sure to fail in subtle | > ways. So should it be OK to move the longjmp outside the catch clause? For example, to simply set a flag inside the catch clause and call longjmp later? Note that doing that in my example program still fails. Try the new version below. If you define CRASHME, it will fail, and the longjmp is called outside the catch clause. If you don't define CRASHME, the longjmp happens in a completely separate function and it appears to work (tested on a Cygwin system with the current GCC). In Octave, I think I can move the call to longjmp outside the catch clause without too much trouble, but I don't think I can easily move it to a completely separate function. | > What I would strongly recommend is using either setjmp or | > exceptions, but not both. Perhaps I'm misunderstanding precisely what is meant by this. If it is that one should never use setjmp and exceptions in the same program, then I don't think this is a realistic solution given that real programs often mix code from various sources. If I'm writing C++ and prefer to use exceptions, then I can't call any library code that might happen to use setjmp somewhere along the way? jwe #include #include jmp_buf context; class exception { // empty; }; static bool do_longjump_return = false; static void callback_fcn (void) { try { std::cerr << "toit: throwing exception" << std::endl; throw exception (); } catch (exception) { do_longjump_return = true; std::cerr << "toit: caught exception, preparing to longjump" << std::endl; } #if defined (CRASHME) if (do_longjump_return) { std::cerr << "foreign code: exception in callback, longjumping" << std::endl; longjmp (context, 1); } #endif } typedef void (*fptr) (void); void foreign_code (fptr f) { std::cerr << "foreign code: executing callback" << std::endl; (*f) (); #if ! defined (CRASHME) if (do_longjump_return) { std::cerr << "foreign code: exception in callback, longjumping" << std::endl; longjmp (context, 1); } #endif } static void doit (void) { if (setjmp (context) == 0) { std::cerr << "doit: calling foreign code that uses callback_fcn" << std::endl; foreign_code (callback_fcn); } else { std::cerr << "doit: longjump landed, throwing exception" << std::endl; throw exception (); } } int main (void) { try { std::cerr << "main: calling doit" << std::endl; doit (); } catch (exception) { std::cerr << "main: caught exception" << std::endl; } return 0; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-25 05:27 --- Subject: Re: [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions Thanks for the quick response. I am consulting with the reporter to what he wants to do. Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-24 22:34 --- Sorry, but this test case is never going to work -- with either sjlj exceptions or unwind exceptions. By longjmp-ing from the middle of a catch clause, you've left the c++ library with live exceptions hanging around in global state. With unwind exceptions it may appear to work, but is sure to fail in subtle ways. As for the more immediate segfault, real setjmp does not interoperate with sjlj exceptions, in that there is invisible eh state that needs to be managed behind your back, and that code is being bypassed. I suppose it wouldn't be impossible to extend this state manipulation to also catch calls to the system setjmp routine, but I certainly don't feel particularly motivated work on that. What I would strongly recommend is using either setjmp or exceptions, but not both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-24 18:47 --- RTH, do you have any insight as to what might be going wrong here? -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 18:00 --- Confirmed, this is happens on all target which use setjmp/longjmp exceptions. I forget if any of the primary/secondary targets still use sjlj exceptions but this is a regression from 2.95.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.1.0 Known to work||2.95.3 Last reconfirmed|-00-00 00:00:00 |2005-03-12 18:00:03 date|| Summary|problem mixing C++ |[3.3/3.4/4.0 Regression] |exceptions and |problem mixing C++ |setjmp/longjmp under Cygwin |exceptions and ||setjmp/longjmp with SJLJ ||exceptions Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442