This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: static fork strerror and how they interact.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc dot ca>, frank ernest <doark at mail dot com>, libc-help at sourceware dot org, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Mon, 16 Mar 2015 19:12:34 -0400
- Subject: Re: static fork strerror and how they interact.
- Authentication-results: sourceware.org; auth=none
- References: <fad997db4179 dot 545133ef at langara dot bc dot ca> <545146E9 dot 8040208 at redhat dot com> <87d2488y1k dot fsf at mid dot deneb dot enyo dot de>
On 03/16/2015 04:52 PM, Florian Weimer wrote:
> * Carlos O'Donell:
>
>> On 10/29/2014 02:37 PM, Steven Stewart-Gallus wrote:
>>> You have to use strerror_r. If you fork from a mullithreaded process you can't
>>> allocate memory safely though. An ugly hack to solve the problem is to spawn a
>>
>> You must not call async-signal-unsafe functions, and malloc
>> et. al. are async-signal unsafe. Therefore you can't allocate
>> memory, you must use a static buffer.
>
> We have to support malloc-after-fork as an extension, at the very
> least if the original program was not multi-threaded. Too many
> programs rely on that.
If the original program was not multi-threaded then everything is
much simpler and the AS-safe conditions don't have to be imposed,
since you can't be *in* malloc and *in* fork at the same time.
Cheers,
Carlos.