Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 5 Aug 2014 19:47:21 +0200
From: Szabolcs Nagy <>
Subject: Re: openmp/pthreads and fork...

* Rich Felker <> [2014-08-05 12:51:37 -0400]:
> On Mon, Aug 04, 2014 at 10:56:51PM -0700, Isaac Dunham wrote:
> > Some programs that use BLAS will fork(); python is one of these.
> > With OpenBLAS, this had caused "random" segfaults due to use of threads
> > by the library both before and after the fork.
> > The OpenBLAS issue is here:
> >
> > 
> > They worked around this using pthread_atfork() to cleanup before the fork().
> This is unlikely to work. pthread_atfork is basically unable to do
> what it was designed for, since, after fork, the new thread in the
> child is not the owner of any mutexes that were obtained by the parent
> before forking, and thus cannot unlock them. It also cannot destroy
> and reinitialize them since they're locked.

> > -How correct, and how likely to work with musl, is the fix for libgomp
> > mentioned here:
> >
> Very unlikely since it's calling free which could run with malloc
> locks permanently deadlocked.

the gomp patch says that it only fixes the case when fork is called
when no gomp threads are running (by default the threads are
kept around holding locks, they should be shut down before fork)

in that case it is enough to check a single global flag before
the new thread pool is initialized (and the flag can be set from
pthread_atfork child handler reasonably safely)

now i see that the openblas issue has all sorts of comments with
invalid solutions and in the end their fix is

  pthread_atfork(BLASFUNC(blas_thread_shutdown), NULL, NULL);

which should work unless fork was called from a sig handler

otherwise i dont see any call to free in AS-safe context

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.