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 <bug...@gnu.org>: 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 > I'm still not sure why anyone would ever > use libsigsegv on cygwin without --enable-EFAULT, because this entire bug > report was due to a fault that was both caused and handled internally by > cygwin. I.e. there was no invalid pointer passed in by the application; > rather, cygwin1.dll took a shortcut that the implicit fclose() during > exit() could try to lock stdout, even though that attempt will fault if > stdout has already been closed, and was gracefully handling the resulting > fault until the point that libsigsegv interfered. [in another mail] > I reported the bug because > libsigsegv intercepted a fault inside fclose, which was in turn invoked by > exit, _without the user passing any invalid pointer to any libc function_. > The fault came when cygwin was checking whether a pointer on the stack > might represent a valid lock object. But the important point is that > during normal operation, the fault was both caused and intercepted by > cygwin1.dll, so that the application never knew the fault was happening. > It wasn't until the application was _also_ linked with libsigsegv that the > fault turned into something that was intercepted by libsigsegv, aborting > the application instead of silently running to completion. 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? > 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. 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? 2) to know whether to apply this to Cygwin 1.5 or 1.7 or both? Bruno
