This is the mail archive of the libc-help@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: static fork strerror and how they interact.


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.

> thread using pthread_create, unshare the file descriptor table and whatever else
> stuff you need, do a lot of normally unsafe things, then vfork and then execve.

If you have working examples please publish them as best practice in blogs so
that we further the list of examples a google search produces.

> I'm not sure if it'd be safe to call strerror_r or not though. You'd have to
> know if strerror_r caches an open file descriptor to stuff for later use or not
> (because if the file descriptor table is unshared then the newly allocated file
> descriptor for a database wouldn't exist in the other threads' file descriptor
> table, likewise the reverse problem exists if a file descriptor database is
> opened by other threads concurrently and then cached.) It's probably simplest to
> just use a pipe to send the error to the process you fork from instead and let
> that process call strerror or strerror_r.

There are many solutions.

Cheers,
Carlos.
 


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