[Bug stdio/15436] New: Don't close or flush stdio streams on abort

[Bug stdio/15436] New: Don't close or flush stdio streams on abort

[schwab@linux-m68k.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15436

             Bug #: 15436
           Summary: Don't close or flush stdio streams on abort
           Product: glibc
           Version: 2.18
            Status: NEW
          Severity: normal
          Priority: P2
         Component: stdio
        AssignedTo: unassigned@sourceware.org
        ReportedBy: schwab@linux-m68k.org
    Classification: Unclassified


POSIX doesn't require abort to close or flush any stdio streams, and doing so
will eventually run into locking problems, since fclose and fflush are not
async-signal-safe, while abort is required to be so.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug stdio/15436] Don't close or flush stdio streams on abort

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15436

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/15436] Don't close or flush stdio streams on abort

[zackw at panix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15436

Zack Weinberg <zackw at panix dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zackw at panix dot com

--- Comment #1 from Zack Weinberg <zackw at panix dot com> ---
Since glibc has flushed all open files on abort() for a very long time, we
probably ought to try to preserve a best-effort flush.

It appears that "stage 1" of abort() calls _IO_flush_all_lockp(0), which
attempts to flush all open files *without* doing any locking.  (This strikes me
as unsafe in a different manner, but at least it probably can't deadlock.) 
However, "stage 4" calls __fcloseall(), which does do locking.  Maybe that
should be swapped out for another call to _IO_flush_all_lockp(0)?  Actually
*closing* the files seems unnecessary since the only things after stage 4 are
an escalating chain of attempts to terminate the process.

-- 
You are receiving this mail because:
You are on the CC list for the bug.