Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: atexit(), dlclose() and more atexit()



On Sun 28 Jun 2020 at 23:29:05 +0200, Joerg Sonnenberger wrote:
> On Sun, Jun 28, 2020 at 10:56:01PM +0200, Rhialto wrote:
> > The funny thing is that libavformat uses an atexit handler due to issues
> > with dynamic (un)loading (or so they claim). This is from their file
> > ffmpeg-4.2.2/libavformat/avisynth.c:
> > 
> > /* A conflict between C++ global objects, atexit, and dynamic loading requires
> >  * us to register our own atexit handler to prevent double freeing. */
> 
> It is fundamentally wrong to use a handler in a library that can be
> unloaded. Some systems hack around that problem by looping over all
> atexit handlers on dlclose, but that's exactly that, a costly hack. The
> most common way this triggers is a segfault, actually.

> The code should be using either a C dtor with the appropiate attribute
> or __cxa_atexit directly, but the former is preferable.

I've looked at __cxa_finalize a bit better, and it seems that the lock
mutex_lock(&__atexit_mutex); isn't just used to protect running the
atexit handlers, but even to protect looking at the list of handlers:
atexit_handler_stack.
So the fact that libavformat establishes a handler may be a red herring.
I will try to test this later today somehow.

This would make the chain of events:

1. In the original thread, it dlopen()s libavformat.
2. There is no 2.
3. The main thread starts a new thread, and registers an atexit()
   handler to clean up that thread.
4. main thread exit()s.
5. atexit() handler obtains its lock (which protects the handler list),
   and calls the handler established in 3.
6. said handler tells the new thread to clean up and finish. One of the last
   things the thread does, is to dlclose() libavformat.
7. __cxa_finalize() gets called on behalf of libavformat (as always
   happens when a library is unloaded), which tries to obtain the
   same lock that was already obtained, in a different thread, in step
   5.
8. deadlock.

In this case, the fault cannot be with libavformat, right?

-Olaf.
-- 
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___  Anyone who is capable of getting themselves made President should on
\X/  no account be allowed to do the job.       --Douglas Adams, "THGTTG"

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index