This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] abort: Only flush file-based stdio streams before termination


On 08/18/2017 08:23 AM, Florian Weimer wrote:
> On 08/17/2017 05:52 PM, Florian Weimer wrote:
>> On 08/17/2017 05:31 PM, Carlos O'Donell wrote:
>>
>>> I'm OK with this change if we clearly document what we're doing in the
>>> glibc manual, and explain the alternative solution of flushing from the
>>> abort handler.
>>
>> The manual currently does not list abort as an action which flushes any
>> buffers:
>>
>> <http://www.gnu.org/software/libc/manual/html_node/Flushing-Buffers.html>
>>
>> I think you are making up an implementation constraint which does not
>> actually exist.
> 
> Furthermore, GCC performs dead store elimination on malloc'ed memory
> whichis incompatible with your made-up use case:
> 
> #include <stdlib.h>
> 
> void f (int i)
> {
>   int *p = malloc (sizeof (p));
>   *p = i;
>   abort ();
> }
> 
> f:
> 	subq	$8, %rsp
> 	call	abort
> 
> malloc is not an interface useful for persistent memory.

I agree that DSE is a general NVM problem that needs to be solved.

I don't agree that you can use this specific small example and problem
to refute that flushing an opem_memstream is not useful.

The open memstream is much more complicated than this, and I bet
you can't prove DSE like above to remove all of the stores to the memory
stream (not with the present compiler technology).

Do we have a technical objection to flushing the open memory streams?

I agree that we should do less work on abort(), you have convinced me
of that, but given the existing behaviour to flush streams, I want to
take make these changes conservative. Avoiding flushing user streams
is a good idea, so is removing the complex backtracing.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]