Re: questions about bug 4737 (fork is not async-signal-safe)

[Jonathan Nieder <jrnieder at gmail dot com>]

Norbert van Bolhuis wrote:

> The problem is that it is a lot of work to move to a new glibc.

	git clone git://sourceware.org/git/glibc.git
	mkdir glibc-build
	cd glibc-build
	../glibc/configure --prefix=$HOME/opt/glibc
	make check
	make install
	LD_LIBRARY_PATH=$HOME/opt/glibc:/usr/local/lib:/usr/lib:/lib
	export LD_LIBRARY_PATH
	elf/ld.so /path/to/app arguments

> I'm just trying to fully understand the problem and then judge whether
> our app really needs this bug fixed.

I've enjoyed looking over the various stories you pointed to, so no
harm done.  But you haven't fully explained the problem you ran into
(for example by sending a testcase) so there's not much others can do
to help.

The report about fork deadlocks when called from from a signal handler
that you pointed to is about a situation in which the standard is
unclear.  OpenSolaris copes by making fork act like _Fork (meaning
skipping atfork handlers) when called from a signal handler.  Of
course, glibc does not even provide _Fork yet; I suspect providing it
would be a nice, uncontroversial improvement if someone wants to help
in this area.

The report from Wayne Badger about fork corrupting list_all_lock state
when the syscall fails looked to him like a silicon bug.  It was
highly CPU-specific.  It seems like a silicon or code generation bug
to me, too, since the source code does not ask to do what it was
observed to do.

The report about plash is not about glibc code.

Of course I'd be thrilled if you can make progress on any of the
above.

Kind regards,
Jonathan