GNOME Bugzilla – Bug 618531
Process terminating with default action of signal 11 (SIGSEGV)
Last modified: 2010-07-10 01:29:08 UTC
Ubuntu 10.04 Linux 2.6.32-22-generic #33-Ubuntu SMP i686 GNU/Linux VLC media player 1.0.6 liborbit2 2.14.18-0.1 libc6 2.11.1-0ubuntu7 When closing vlc normally it exits with segv. Does this happen every time? Yes. (And also after a reboot) Other information: Valgrind output attached. Any more can be provided on request as this is easy to reproduce on my system. See also: https://trac.videolan.org/vlc/ticket/3619
Created attachment 160968 [details] basic valgrind output from a segv
This is really odd: ==13219== Invalid read of size 2 ==13219== at 0x417F914: getenv (getenv.c:84) ==13219== by 0x7661B46: g_get_charset (in /lib/libglib-2.0.so.0.2400.0) ==13219== by 0x7639759: g_log_default_handler (in /lib/libglib-2.0.so.0.2400.0) ==13219== by 0x7639BE9: g_logv (in /lib/libglib-2.0.so.0.2400.0) Caused by: static gboolean g_utf8_get_charset_internal (const char *raw_data, const char **a) { const char *charset = getenv("CHARSET"); Seems -really- hard to fault ;-) Of course, there are some simple ways to screw over glibc. First your app can use 'putenv(foo);' and then free foo ;-) [ which becomes part of the env ] - that might cause this. Or - second, you could just corrupt the heap nicely (perhaps less likely). Either way - certainly not an ORBit2 bug - sorry :-) check your app.
Well "my app" is the current official "stable" VLC version as released for ubuntu 10.04 LTS. The reason for ending up on this bugtracker is because people from the vlc bugtracker have read the valgrind dump and adviced me to go to the orbit bugtracker, as you can see here https://trac.videolan.org/vlc/ticket/3619 Are you saying it should be fixed by a vlc developer? If your answer is yes we are in a deadlock for this bug... Please clarify your finding. :-)
VLC does not use ORBit2. The VLC Qt4 UI loads some GNOME/GTK plugin(s) that then uses ORBit2. A plugin simply MUST NOT register exit handlers, which is what happens here. Either way, ORBit2, or the GNOME/GTK plugins for Qt4, it's a GNOME bug.
Ah yes, atexit(). (Here, actually g_atexit().) Such a good idea in the 70s, such a horrible and ill-defined idea in any modern OS. The g_atexit() use in ORBit2 caused some fun already back when porting ORBit2 to Windows, and I decided to just don't even try it on Windows. Should it be dropped on all platforms?
Oh - hmm; well - here is the problem. ORBit2 creates named sockets in /tmp/linc-$USER The atexit handler unlinks them. If you don't unlink them sometime, your machine will slowly slow to a crawl as that directory fills up with unique files ;-) That is not good. If VLC cleans up it's plugins as it shuts down [ as presumably it should ] then if it calls: CORBA_ORB_shutdown(); or perhaps more simply: bonobo_debug_shutdown(); Then - hopefully the atexit handler will do next to nothing, and all will be well. Failing that of course, we have a long term non-completed wish to implement anonymous sockets - which would also solve the problem, and get auto-cleaned by the kernel. HTH.
Not sure how this ended up in GTK+.