Date: Fri, 6 Dec 2002 18:21:38 -0500 (EST) From: Mikhail Teterin <mi@corbulon.video-collage.com> To: arch@FreeBSD.org Cc: riggs@rrr.de Subject: atexit(3), exit(3) vs. dlclose(3) et al Message-ID: <200212062321.gB6NLcEt052452@corbulon.video-collage.com>
next in thread | raw e-mail | index | archive | help
Hello! I've just reported what seems to be a bug in mplayer, but am still wondering, why it existed for so long. Mplayer was crashing in exit(3) (a silly place to crash, is not it?). Turns out, it dlopen(3)s some "back end" libraries, which may call atexit(3) to register their own callbacks, which remain registered even after the libraries themselves were dlclose(3)d. This usually causes the crash when exit(3) tries to call the callbacks one at a time... Don't call dlclose(3)? Kind of unclean... Why does it even exist -- even after a simple dlopen(3) a library's _init() can call atexit(3), and you will die exit(3)ing. There is no standard way to even query the __atexit list... May be, the dlopen/dlclose should monitor the atexit calls and arrange for the functions to be called at dlclose OR exit time -- whichever comes first? Or simply bump the reference count of the library to which the function being registered belongs? But they would have to distinguish the functions in the library being dlclosed from others, in order to not change the semantics... Why didn't the mplayer's authors notice until now? They develop on Linux, is Linux' handling of these functions substantially different? Ouch... Any comments? -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212062321.gB6NLcEt052452>