Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 20 Feb 2004 11:47:24 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Repeatable crash with CVS version of cygwin1 DLL
Message-ID: <20040220164724.GA5195@redhat.com>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20040219060514 DOT GA11752 AT redhat DOT com> <200402201603 DOT i1KG31b01524 AT mx1 DOT redhat DOT com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="Qxx1br4bt0+wmkIi"
Content-Disposition: inline
In-Reply-To: <200402201603.i1KG31b01524@mx1.redhat.com>
User-Agent: Mutt/1.4.1i
Reply-To: cygwin AT cygwin DOT com

--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Feb 20, 2004 at 10:02:38AM -0600, Cliff Geschke wrote:
>Are you trying to tell me that I can only call setjmp from the main
>program?

I don't recall saying that.  What I'm saying is that longjmp is always
supposed to be jumping to a location earlier in the call stack.

>I don't know what man page you are reading, but you are
>misunderstanding what it says.  Setjmp/longjmp does not trash (or is
>not supposed to trash) the call stack.  It can trash the auto variables
>in the local routine ("stack context") that contains the setjmp call,
>but that is not an issue here.

 From SUSv3:

"The longjmp() function shall restore the environment saved by the most
recent invocation of setjmp() in the same thread, with the corresponding
jmp_buf argument.  If there is no such invocation, or if the function
                                                      ^^^^^^^^^^^^^^^
containing the invocation of setjmp() has terminated execution in the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
interim, or if the invocation of setjmp() was within the scope of an
^^^^^^^
identifier with variably modified type and execution has left that scope
in the interim, the behavior is undefined."
                ^^^^^^^^^^^^^^^^^^^^^^^^^

For instance, try the attached program on linux and you'll get a SEGV
because returning after the foo does not go to the right place.

This is basically what your test program seems to be doing.  It's possible
to get this to "work" by being very very careful with the stack but it
seems like fragile behavior to me.

For instance, the attached program "works" when there is no intervening
function call between the call to foo and the longjmp as can be
demonstrating by running the program with an argument.

cgf

--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="badlongjmp.c"

#include <stdio.h>
#include <setjmp.h>

jmp_buf bar;

void
foo ()
{
  if (setjmp (bar) == 0)
    return;
  printf ("hey I saw a longjmp\n");
  return;
}

void
blah (int a, int b, int c, char *s)
{
  printf ("a is %d, b is %d, c is %d, s is '%s'\n", a, b, c, s);
  return;
}

int
main (int argc, char **argv)
{
  static int i = 0;
  foo ();
  if (i++ == 0)
    {
      if (argc == 1)
	blah (0, 1, 2, "hello!");
      longjmp (bar, 2);
    }
   puts ("exiting");
}


--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/
--Qxx1br4bt0+wmkIi--