bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]