Re: undefined behavior in closeout, aggravated by libsigsegv

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bruno Haible on 11/22/2009 5:54 AM:
> Hi Eric,
> 
>>>     http://www.haible.de/bruno/gnu/libsigsegv-2.8-pre1.tar.gz
>> I have confirmed that, with --enable-EFAULT, the latest libsigsegv.git
>> passes on both cygwin 1.5 and 1.7.
> 
> Thanks for re-testing!
> 
>> Without --enable-EFAULT, then a build 
>> of m4 1.4.12 on cygwin 1.5 with the latest libsigsegv still has the same
>> bug that sparked this thread.
> 
> How can I reproduce it? The recipe that you gave in
>   <http://lists.gnu.org/archive/html/bug-gnulib/2009-07/msg00034.html>
> is:
>   $ echo hi > file
>   $ build/src/m4 >&- file
>   build/src/m4: internal error detected; please report this bug to 
> <address@hidden>: Segmentation fault
> 
> But on Cygwin 1.5.25, with libsigsegv-2.8-pre1 compiled without 
> --enable-EFAULT,
> and with m4-1.4.12 configured with --with-libsigsegv-prefix=/usr/local/cygwin,
> I see
>   $ echo hi > file
>   $ ./m4 >&- file
>   ./m4: write error: Bad file descriptor

Sorry for the confusion, I was going off my notes rather than an actual
compilation.  It turns out that there was some change in newlib between
cygwin 1.5 and 1.7 (although I haven't pinpointed it yet) which makes
fflush of a closed stream behave differently between the two releases:
http://cygwin.com/ml/cygwin/2009-07/msg00659.html

The particular m4 bug that sparked this thread had three cooperating
causes - fix any one of the three, and the crash goes away (so, in true
open source fashion, I fixed all three of the problems, through three
different projects).  newlib's fflush used to blindly grab a lock (causing
a fault if the lock was bogus), but now checks for a valid file first.
Gnulib's error was calling fflush(stdout) without checking if it was
valid.  And libsigsegv was intercepting the fault handling before cygwin
had a chance to ignore it.
http://cygwin.com/ml/cygwin-talk/2009-q3/msg00021.html

But since cygwin 1.5 did not experience the internal fault, and it has
already been patched in current CVS cygwin 1.7, the only way to reproduce
the bug that sparked this thread is to revert to an older snapshot of
cygwin 1.7.

Meanwhile, I will try to spend some time inspecting cygwin source code to
see if I can find another example of an internal fault that cygwin expects
to handle, and where libsigsegv intercepting the fault can cause
observable behavior changes, beyond just EFAULT handling.

> 
> Now I'm really confused. Not only I cannot reproduce the problem you reported.
> Are you also saying that the change to error.c that you did in
>   <http://lists.gnu.org/archive/html/bug-gnulib/2009-07/msg00040.html>
> and that you said "fix the behavior of m4 on cygwin" was actually a red
> herring?

No, it was a real fix, but for a snapshot version of cygwin 1.7 that is no
longer posted on the web (although it can be rebuilt from sources).

> 
>> I think it is wrong for libsigsegv
>> to ever be compiled without --enable-EFAULT on cygwin
> 
> I'm not opposed against enabling --enable-EFAULT by default on Cygwin, but I'd
> like
>   1) to have a clear indication whether it's actually needed.

Yes - per cygwin's goal of being a POSIX emulation, cygwin MUST be given
first crack at handling faults, and libsigsegv should not react until a
fault signal handler is invoked.  The cygwin developers have agreed that
after cygwin 1.7.1 is released, it is time to start looking into
implementing sigaltstack, at which point cygwin will be indistinguishable
from other POSIX solutions, and libsigsegv will then be able to work
without having to inject a windows fault handler at all.

> With the current
>      confusion: Can you tell a reproducible case where Cygwin internally
>      produces a fault? Or can you point to a place in Cygwin's source code
>      where this happens?

I'm looking for one.

>   2) to know whether to apply this to Cygwin 1.5 or 1.7 or both?

Both.  Until cygwin 1.7 implements sigaltstack, libsigsegv needs to do
stack overflow handling via windows fault management.  And cygwin 1.5
development is frozen.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksKlQIACgkQ84KuGfSFAYCThwCgylY7ZntW0To0ljljg+3Kx9+O
tU8An0r7wS/KNK0lfyzUY8kaPtJJdRPT
=aq6c
-----END PGP SIGNATURE-----