[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-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 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 csetjmp
#include iostream
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-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 unistd.h
#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 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 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 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 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
