[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: undefined behavior in closeout, aggravated by libsigsegv
From: |
Bruno Haible |
Subject: |
Re: undefined behavior in closeout, aggravated by libsigsegv |
Date: |
Sun, 22 Nov 2009 13:54:19 +0100 |
User-agent: |
KMail/1.9.9 |
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
> 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
- Re: undefined behavior in closeout, aggravated by libsigsegv, Bruno Haible, 2009/11/22
- Re: undefined behavior in closeout, aggravated by libsigsegv, Eric Blake, 2009/11/22
- Re: undefined behavior in closeout, aggravated by libsigsegv, Bruno Haible, 2009/11/22
- Re: undefined behavior in closeout, aggravated by libsigsegv, Eric Blake, 2009/11/22
- Re: undefined behavior in closeout, aggravated by libsigsegv, Eric Blake, 2009/11/22
- Re: undefined behavior in closeout, aggravated by libsigsegv, Bruno Haible, 2009/11/22