delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2004/02/18/17:44:20

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Wed, 18 Feb 2004 17:43: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: <20040218224324.GA4792@redhat.com>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20040217162718 DOT GB23084 AT redhat DOT com> <200402181635 DOT i1IGZqb15018 AT mx1 DOT redhat DOT com>
Mime-Version: 1.0
In-Reply-To: <200402181635.i1IGZqb15018@mx1.redhat.com>
User-Agent: Mutt/1.4.1i
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com

On Wed, Feb 18, 2004 at 10:31:03AM -0600, Cliff Geschke wrote:
>cygwin-1.5.7-1
>cygwin-SPLAT-cygwin-BOP-com

Please, avoid putting raw email addresses in messages.  They serve no
purpose and are spambot fodder.

>After doing what you asked, the crash still occurs, but is somewhat
>different.  Here is what I did.
>
>1. Loaded cygwin from CVS.  I see the relevant routines have all changed.
>2. ./configure
>3. make
>4. build failed for dumper.exe (will send separate email)
>5. Replaced  /usr/bin/cygwin1.dll with new-cygwin1.dll
>6. Reboot (just to be safe)
>7. Ran my test program.
>
>I am still seeing stackptr being corrupted.  I believe it happens
>after a setjmp/longjump.  See "do_jump" routine below.
>
>I think the problem is in the "call _set_process_mask" in sigreturn.
>That somehow winds up calling _sigbe with the thread stack empty.
>
>Look for "####" below for start of debug sections.
>
>I can supply the .exe test program if you wish.
>
>Good luck and thanks,

Thank you for providing an impressive amount of detail.  I have made
some changes to setjmp/longjmp.  I don't know if they fix your problems
but I did manage to write a very simple test case which illustrated a
problem with using setjmp/longjmp in signal handlers.

>________________________________________________________________________________
>#### Here is the program that I think triggers the problem
>
>
>static void do_jump(
>  Context_Control_overlay *currentp,
>  Context_Control_overlay *nextp
>)
>{
>  int status;
>
>  if (setjmp(currentp->regs) == 0) {    /* Save the current context */
>     longjmp(nextp->regs, 0);           /* Switch to the new context */
>     _Internal_error_Occurred(
>         INTERNAL_ERROR_CORE,
>         TRUE,
>         status
>       );
>  }
>}

I'd love to have a simple test case but the above isn't a program.  It
looks like a snippet of a program.  I'm not sure how to set this up to
duplicate your problem.

If you have a complete listing of a program which illustrates the problem,
please post it here.

In the meantime, I'd appreciate it if you would try the latest version from
CVS or the latest snapshot when it is available.  I'm regenning a new version
now with some fork changes that make inetd work better.

cgf

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019