On Sun 28 Jun 2020 at 22:39:28 +0200, Joerg Sonnenberger wrote: > On Sun, Jun 28, 2020 at 10:35:27PM +0200, Rhialto wrote: > > I have at hand a program (the current svn trunk of VICE, to be exact) > > which does the following: > > > > 1. In the original thread, it dlopen()s libavformat. > > 2. libavformat establishes an atexit() handler. > > 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, 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. libavformat's atexit handling gets called, which tries to obtain the > > same lock that was already obtained, in a different thread, in step > > 5. > > 8. deadlock. > > > > Who is in the wrong here? > > libavformat. Never use atexit() with a handler in a library that can be > closed.
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. */ > Joerg -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"
signature.asc
Description: PGP signature
