[Bug c++/20442] New: problem mixing C++ exceptions and setjmp/longjmp under Cygwin

[Bug c++/20442] New: problem mixing C++ exceptions and setjmp/longjmp under Cygwin

[paulthomas2 at wanadoo dot fr]

This is a copy of a posting by John Eaton on the Cygwin list.  I can confirm 
that the problem starts with gcc-3.3 and is present in gcc-4.0
______________________________________________________________
I believe the following program should print

  main: calling doit
  doit: calling toit
  toit: throwing exception
  toit: caught exception, longjumping
  doit: longjump landed, throwing exception
  main: caught exception

but on the current Cygwin (updated today) using the 1.5.13-1
cygwin.dll and either gcc 3.3 or 3.4, it crashes with a segfault just
after printing the next to last line:

  doit: longjump landed, throwing exception

I tried going back to 1.5.12, but that did not fix the problem.

Can anyone reproduce this problem?

This problem affects GNU Octave, as it uses this technique to handle
interrupts in code that is a mixture of C++, C, and Fortran.  If
SIGINT arrives in a section of Octave code, the signal handler sets a
flag and then returns, letting Octave check the flag periodically.  At
some safe location, an exception is thrown that will return control
to the top level of the main interpreter loop.  If SIGINT arrives
inside some foreign code (say, readline, or some Fortran code) then
the signal handler jumps back to the location of the call to the
foreign code.  At that point, an exception is thrown to get back to
the top level.  I've not had problems with this approach until
recently when I upgraded my Cygwin installation.  Now Ctrl-C at the
prompt causes a segfault.  The program below is a distillation of the
key features of the Octave code, and shows the same problem.

Any clues?

Thanks,

jwe

-- 
www.octave.org | jwe@octave.org


#include <setjmp.h>

#include <iostream>

jmp_buf context;

class
exception
{
  // empty;
};

static void
toit (void)
{
  try
    {
      std::cerr << "toit: throwing exception" << std::endl;
      throw exception ();
    }
  catch (exception)
    {
      std::cerr << "toit: caught exception, longjumping" << std::endl;
      longjmp (context, 1);
    }
}

static void
doit (void)
{
  if (setjmp (context) == 0)
    {
      std::cerr << "doit: calling toit" << std::endl;
      toit ();
    }
  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;
}

-- 
           Summary: problem mixing C++ exceptions and setjmp/longjmp under
                    Cygwin
           Product: gcc
           Version: 3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: paulthomas2 at wanadoo dot fr
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442

[Bug middle-end/20442] problem mixing C++ exceptions and setjmp/longjmp under Cygwin

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |middle-end
           Keywords|                            |EH, sjlj-eh, wrong-code


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

[pinskia at gcc dot gnu dot org]

------- 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|0000-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

[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions

[mmitchel at gcc dot gnu dot org]

------- 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

[rth at gcc dot gnu dot org]

------- 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

[paulthomas2 at wanadoo dot fr]

------- 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

[paulthomas2 at wanadoo dot fr]

------- 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

[paulthomas2 at wanadoo dot fr]

------- 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  <jwe@octave.org>

* 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 <jwe@octave.org>

* 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 -0000 1.23
+++ liboctave/cmd-edit.cc 26 Mar 2005 17:53:14 -0000
@@ -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 -0000 1.160
+++ src/input.cc 26 Mar 2005 17:53:27 -0000
@@ -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

[rth at gcc dot gnu dot org]

------- 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

[paulthomas2 at wanadoo dot fr]

------- 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