Message-ID: <4AD95908.9020208@gmail.com>
Date: Sat, 17 Oct 2009 06:41:28 +0100
From: Dave Korn <dave.korn.cygwin@googlemail.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: fork failure?
References: <4AD732C7.4020301@cwilson.fastmail.fm> <4AD73B83.9060505@gmail.com> <4AD74586.8070803@cwilson.fastmail.fm> <4AD752C8.2040908@gmail.com> <4AD7B135.6020401@cwilson.fastmail.fm> <4AD8220D.8000908@cwilson.fastmail.fm> <4AD8AD47.6010605@cwilson.fastmail.fm> <4AD8B90B.4040507@gmail.com> <4AD8CD8A.7010708@cwilson.fastmail.fm> <4AD8D490.2040000@gmail.com> <4AD8DAC3.2080709@cwilson.fastmail.fm> <4AD93CA2.6020002@cwilson.fastmail.fm>
In-Reply-To: <4AD93CA2.6020002@cwilson.fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Charles Wilson wrote:

> I have a hunch that an STC (okay, less-hellaciously-complicated test
> case) could be developed, using just GNU pth and avoiding all the
> libassuan/gnupg gobbledygook.

  Oh yuck.  So there's this alternative user-land pthreads library that runs a
scheduler within a single real machine thread, using some hairy sjlj hackery
to perform context switches?  That's kinda asking for trouble, isn't it?

  Anyway, look here: pth_mctx.c line ~ 514

> /*
>  * VARIANT 5: WIN32 SPECIFIC JMP_BUF FIDDLING
>  *
>  * Oh hell, Win32 has setjmp(3), but no sigstack(2) or sigaltstack(2).
>  * So we have to fiddle around with the jmp_buf here too...
>  */
> 
> #elif PTH_MCTX_MTH(sjlj) && PTH_MCTX_DSP(sjljw32)
> intern int
> pth_mctx_set(pth_mctx_t *mctx, void (*func)(void),
>                      char *sk_addr_lo, char *sk_addr_hi)
> {
>     pth_mctx_save(mctx);
> #if i386
>     mctx->jb[7] = (int)sk_addr_hi;
>     mctx->jb[8] = (int)func;
> #else
> #error "Unsupported Win32 architecture"
> #endif
>     sigemptyset(&mctx->sigs);
>     mctx->error = 0;
>     return TRUE;
> }

  Umm, yes.  Poking around directly inside a sigjmp_buf.  Wonder if the layout
is actually what that code expects it to be or not?  That's where I'd start
looking next, anyway, if I was wondering why maybe things were randomly
jumping to unexpected places ...

    cheers,
      DaveK


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