Bug 260719 - Vlc hangs on open file dialog
Summary: Vlc hangs on open file dialog
Status: RESOLVED UPSTREAM
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: 4.6
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-19 17:10 UTC by Marco Londero
Modified: 2013-03-02 16:19 UTC (History)
24 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
vlc file open dialog backtrace... (6.59 KB, text/plain)
2011-01-22 00:36 UTC, Dawit Alemayehu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Londero 2010-12-19 17:10:01 UTC
Version:           4.5 (using KDE 4.5.85) 
OS:                Linux

Vlc freezes when with Kde 4.6 beta 2, you click on Media - Open file, this is the shell output:
[marco@sondarch ~]$ vlc
VLC media player 1.1.5 The Luggage (revision exported)
Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS")
Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE")
Blocked: call to setlocale(6, "")
Blocked: call to sigaction(17, 0xb0ddf058, 0xb0ddf0e4)
Blocked: call to setlocale(6, "")
Blocked: call to putenv("LANGUAGE=")
KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work

Reproducible: Always

Steps to Reproduce:
Open Vlc and click on Media-Open file

Actual Results:  
Vlc hangs and I have to kill the application to stop it


It has been posted also in Vlc forum: http://forum.videolan.org/viewtopic.php?f=13&t=85408#p282713 and a developer answered that is a Kde's bug.
Comment 1 Dario Andres 2010-12-19 19:00:10 UTC
[Comment from a bug triager]
GDB could be attached to the VLC process to try to determine where it is hanging. However, as Arch doesn't distribute debuginfo process, the crash may be not complete; but you can try it.

- Run VLC and reproduce the hang
- Run Konsole
- Get the PID of the VLC instance
- On Konsole run "gdb -p PID"
- On the GDB prompt write "bt full" and press Enter
- Then copy the output of that command here

Thanks
Comment 2 Marco Londero 2010-12-19 19:40:20 UTC
Ok this is the output:

(gdb) bt full
#0  0xb78cb424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb77973fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
No symbol table info available.
#2  0xb7855193 in vlc_cond_wait () from /usr/lib/libvlccore.so.4
No symbol table info available.
#3  0xb78885f8 in ?? () from /usr/lib/libvlccore.so.4
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Comment 3 Dario Andres 2010-12-19 19:45:43 UTC
[Comment from a bug triager]
Mh, that doesn't look like a freeze.
Try this:

- After the "bt full": enter "c" on the GDB prompt and press enter 
VLC continues running
- 5 seconds after that press "Ctrl+C"
VLC is stopped again by GDB
- Enter "thread apply bt all" + Enter
- Enter "bt full" + Enter
- Copy here the output of that last command
Comment 4 Marco Londero 2010-12-19 20:05:31 UTC
This is the new ouput:

(gdb) thread apply bt all
(gdb) bt full
#0  0xb7873424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7742ea1 in pause () from /lib/libpthread.so.0
No symbol table info available.
#2  0xb72d093d in ?? () from /usr/lib/vlc/plugins/control/libsignals_plugin.so
No symbol table info available.
#3  0x00736c61 in ?? ()
No symbol table info available.
#4  0x6e676953 in ?? ()
No symbol table info available.
#5  0x00736c61 in ?? ()
No symbol table info available.
#6  0x65746e69 in ?? ()
No symbol table info available.
#7  0x63616672 in ?? ()
No symbol table info available.
#8  0x50000065 in ?? ()
No symbol table info available.
#9  0x5849534f in ?? ()
No symbol table info available.
#10 0x67697320 in ?? ()
No symbol table info available.
#11 0x736c616e in ?? ()
---Type <return> to continue, or q <return> to quit---
Comment 5 Dario Andres 2010-12-21 18:18:10 UTC
[Comment from a bug triager]
- Do other Qt-only applications crash when trying to show a file dialog ?
- Which widget style are you using ? Oxygen ? If it is Oxygen, try switching to another style. (or running VLC with another style, like "vlc -style plastique") and check if it hangs too.
Regargs
Comment 6 Marco Londero 2010-12-27 13:47:27 UTC
I haven't other Qt-only applications to try the open ile dialog. I changed Qt and Oxygen themes and Vlc still hangs, but if I wait for a minute it will open the dialog.
Comment 7 Dario Andres 2010-12-29 00:51:56 UTC
[Comment from a bug triager]
- Try installing another Qt-only app and checking it
- Is HAL running in your system ? If it is, try disabling it and checking again
Regards
Comment 8 Eric Hameleers 2011-01-03 00:41:32 UTC
I see the same issue on Slackware-current with KDE 4.5.90 while VLC works fine on KDE 4.5.4 (Qt version unchanged at 4.7.0 in both cases).
For completeness sake, VLC's file-open dialog works fine when running another DE like XFCE.

My locale is non-english: nl_NL.UTF-8, that may make a difference.

I have tested with HAL running and with HAL disabled. Also tested with compositing enabled as well as disabled. This makes no difference in the result.

In my case, VLC will crash almost every time when trying to open the file browser (using Ctrl-O or menu Media>Open File) when I am running KDE 4.5.90.

A backtrace when attaching gdb to the vlc process follows:

Blocked: call to setlocale(6, "")
Blocked: call to putenv("LANGUAGE=")
KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work 

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff1659710 (LWP 3265)]
0x00007ffff5b6314b in _int_malloc () from /lib64/libc.so.6
(gdb) thread apply bt all
(gdb) bt full
#0  0x00007ffff5b6314b in _int_malloc () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff5b6605e in malloc () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007fffee2dbeb9 in QString::realloc(int) () from /usr/lib64/libQtCore.so.4
No symbol table info available.
#3  0x00007fffeb9f5f54 in ?? () from /usr/lib64/libkdecore.so.5
No symbol table info available.
#4  0x00007fffeb9ed559 in ?? () from /usr/lib64/libkdecore.so.5
No symbol table info available.
#5  0x00007fffeb9ecaf1 in ?? () from /usr/lib64/libkdecore.so.5
No symbol table info available.
#6  0x00007fffeb961303 in KGlobal::setActiveComponent(KComponentData const&) ()
   from /usr/lib64/libkdecore.so.5
No symbol table info available.
#7  0x00007fffeb96391a in KComponentData::KComponentData(QByteArray const&, QByteArray const&, KComponentData::MainComponentRegistration) () from /usr/lib64/libkdecore.so.5
No symbol table info available.
#8  0x00007fffeba2b1a8 in KPluginFactory::KPluginFactory(char const*, char const*, QObject*) ()
   from /usr/lib64/libkdecore.so.5
No symbol table info available.
#9  0x00007fffe1d94239 in ?? () from /usr/lib64/kde4/kfilemodule.so
No symbol table info available.
#10 0x00007fffe1d943c8 in qt_plugin_instance () from /usr/lib64/kde4/kfilemodule.so
No symbol table info available.
#11 0x00007fffeba2e298 in KPluginLoader::factory() () from /usr/lib64/libkdecore.so.5
No symbol table info available.
#12 0x00007fffecce2e79 in ?? () from /usr/lib64/libkio.so.5
No symbol table info available.
#13 0x00007fffecce3051 in ?? () from /usr/lib64/libkio.so.5
No symbol table info available.
#14 0x00007fffecce4753 in KFileDialog::KFileDialog(KUrl const&, QString const&, QWidget*, QWidget*) () from /usr/lib64/libkio.so.5
No symbol table info available.
#15 0x00007fffecce928c in ?? () from /usr/lib64/libkio.so.5
No symbol table info available.
#16 0x00007fffeed678d8 in QFileDialog::getOpenFileNames(QWidget*, QString const&, QString const&, QString const&, QString*, QFlags<QFileDialog::Option>) () from /usr/lib64/libQtGui.so.4
No symbol table info available.
#17 0x00007fffef431247 in DialogsProvider::showSimpleOpen(QString const&, int, QString const&) ()
   from /usr/lib64/vlc/plugins/gui/libqt4_plugin.so
No symbol table info available.
#18 0x00007fffef432270 in DialogsProvider::addFromSimple(bool, bool) ()
   from /usr/lib64/vlc/plugins/gui/libqt4_plugin.so
No symbol table info available.
#19 0x00007fffef537a02 in DialogsProvider::qt_metacall(QMetaObject::Call, int, void**) ()
   from /usr/lib64/vlc/plugins/gui/libqt4_plugin.so
No symbol table info available.
#20 0x00007fffee39275f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) ()
   from /usr/lib64/libQtCore.so.4
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#21 0x00007fffee89d0b2 in QAction::triggered(bool) () from /usr/lib64/libQtGui.so.4
No symbol table info available.
#22 0x00007fffee89d2aa in QAction::activate(QAction::ActionEvent) ()
   from /usr/lib64/libQtGui.so.4
No symbol table info available.
#23 0x00007fffeecd2e53 in ?? () from /usr/lib64/libQtGui.so.4
No symbol table info available.
#24 0x00007fffeecd8dea in ?? () from /usr/lib64/libQtGui.so.4
No symbol table info available.
#25 0x00007fffee8f4d98 in QWidget::event(QEvent*) () from /usr/lib64/libQtGui.so.4
No symbol table info available.
#26 0x00007fffeecd9fdb in QMenu::event(QEvent*) () from /usr/lib64/libQtGui.so.4
No symbol table info available.
#27 0x00007fffee8a3734 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib64/libQtGui.so.4
No symbol table info available.
#28 0x00007fffee8a8a2a in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib64/libQtGui.so.4
No symbol table info available.
#29 0x00007fffee37d2ec in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
   from /usr/lib64/libQtCore.so.4
No symbol table info available.
#30 0x00007fffee8a4735 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () from /usr/lib64/libQtGui.so.4
No symbol table info available.
#31 0x00007fffee922244 in ?? () from /usr/lib64/libQtGui.so.4
No symbol table info available.
#32 0x00007fffee920709 in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib64/libQtGui.so.4
No symbol table info available.
#33 0x00007fffee947ba2 in ?? () from /usr/lib64/libQtGui.so.4
No symbol table info available.
#34 0x00007ffff2f058f3 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
No symbol table info available.
#35 0x00007ffff2f060d0 in ?? () from /usr/lib64/libglib-2.0.so.0
No symbol table info available.
#36 0x00007ffff2f0636d in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
No symbol table info available.
#37 0x00007fffee3a836f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
No symbol table info available.
#38 0x00007fffee94784e in ?? () from /usr/lib64/libQtGui.so.4
No symbol table info available.
#39 0x00007fffee37c682 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/libQtCore.so.4
No symbol table info available.
#40 0x00007fffee37c8cc in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/libQtCore.so.4
No symbol table info available.
#41 0x00007fffee380d8b in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#42 0x00007fffef418eb8 in ?? () from /usr/lib64/vlc/plugins/gui/libqt4_plugin.so
No symbol table info available.
#43 0x00007ffff7204d6b in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#44 0x00007ffff5bc9dcd in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb)


A note: in the cases where VLC does not crash immediately, it will take a long time before the file browser opens.

Eric.
Comment 9 Eric Hameleers 2011-01-03 00:46:50 UTC
I also tried a non-KDE Qt4 application: qmmp.

If I try to open the file-open dialog, the dialog appears instantaneously. No delays and no crash. The app works the way I expect it to work.
This is what the app shows in the terminal, around the time that I request the file browser:

QtFileDialogFactory::create()
KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work 
Visual::~Visual()
QtFileDialog::~QtFileDialog()

Regards; Eric
Comment 10 Sergei Kasaurov 2011-01-07 21:02:29 UTC
I can confirm this bug for my VLC and KDE 4.5.80+ (including the latest RC2).
Comment 11 Sandy Dolphinaura 2011-01-07 22:50:03 UTC
Im the poster of the question from the VLC forum (dolphinaura)

Currently, im at KDE 4.5.95, and still having the issue.

Could we get it fixed before KDE 4.6 release please?

Using QT 4.7.1 btw
Comment 12 Jesse Milette 2011-01-08 04:18:57 UTC
I too have this problem.  Affects vlc and VirtualBox.  I am using Kubuntu Maverick.  When vlc is run from terminal, it spits out this before freezing:
(I actually just noticed that the open file dialog will open up,


Blocked: call to putenv("LANGUAGE=")
KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work 
Warning: call to sigaction(13, 0xb73d30d4, (nil))


I noticed several "Blocked: call" type messages including:

Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS")
Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE")
Blocked: call to setlocale(6, "")
Blocked: call to sigaction(17, 0xb73d50d4, 0xb73d5048)
Blocked: call to setlocale(6, "")


My guess is that VLC is trying to figure out what translation to use and its dbus calls are getting blocked.  I have no idea though.  The CPU is not getting used abnormally.

Virtualbox only says

Qt WARNING: QProcess: Destroyed while process is still running.

when the freeze occurs.

I am going to see if this affects a new user account.
Comment 13 omega 2011-01-08 13:37:02 UTC
i have this issue with kde 4.6 rc2 and vlc 1.1.5 and 1.2
Comment 14 omega 2011-01-08 13:49:13 UTC
#0  do_sigwait (set=<value optimized out>, sig=0x7fff8a2ec9a4) at ../nptl/sysdeps/unix/sysv/linux/../../../../../sysdeps/unix/sysv/linux/sigwait.c:65
        ret = <value optimized out>
        tmpset = {__val = {5, 0, 140127350659944, 140127353512523, 140127362171908, 12943520, 140735511710176, 140735511710408, 2, 140127360321781, 0, 12, 
            139848012020768, 140735511710116, 140735511709968, 140735511709808}}
#1  __sigwait (set=<value optimized out>, sig=0x7fff8a2ec9a4) at ../nptl/sysdeps/unix/sysv/linux/../../../../../sysdeps/unix/sysv/linux/sigwait.c:100
        oldtype = 0
        result = -4
#2  0x0000000000401737 in main (i_argc=<value optimized out>, ppsz_argv=<value optimized out>) at vlc.c:225
        set = {__val = {81927, 0 <repeats 15 times>}}
        argv = 0x7fff8a2ec820
        argc = <value optimized out>
        i = <value optimized out>
        vlc = 0xc580a0
        self = 140127362254624
        signum = 17
Comment 15 Gabriel Ramirez 2011-01-09 06:15:38 UTC
The bug happens in Fedora 14 i686 with KDE 4.6 RC1 & RC2 qt-4.7.1-7.fc14.i686  vlc-1.1.5-1.fc14.i686 

previous kde 4.5.4 qt-4.7.1-5.fc14.i686 same vlc-1.1.5-1.fc14.i686 hasn't the delay to show the open dialog

Gabriel
Comment 16 Dave Lepore 2011-01-09 13:01:14 UTC
*** This bug has been confirmed by popular vote. ***
Comment 17 Sandy Dolphinaura 2011-01-12 03:22:17 UTC
A little note/workaround for users who still want to use vlc.
Click on View -> Playlist.
Right click on the playlist, and choose "add file". 
It doesn't freeze that way.
Comment 18 Sandy Dolphinaura 2011-01-12 03:55:32 UTC
Also, if you use the "open file" dialog WHILE there is something already playing in VLC, it will work perfectly as well.
Comment 19 Dawit Alemayehu 2011-01-22 00:33:34 UTC
I know the cause of this freeze problem, but I have not idea what the fix is at this point. The problem occurs because a QProcess started by KMimeTypeRepository::sharedMimeInfoVersion to determine the version number of the update-mime-database tool never finishes successfully. Instead it times out after the default 30 sec period on the waitForFinished call. After that there is an additional 30 sec. freeze because QProcess finds out it has still not finished running and attempts to wait yet again before it kills the process. 

We need to figure out what is causing such a simple command not finish executing, but I doubt that would be done before the 4.6 release. Anyhow, I have attached the relevant portion of the backtrace...
Comment 20 Dawit Alemayehu 2011-01-22 00:36:48 UTC
Created attachment 56310 [details]
vlc file open dialog backtrace...
Comment 21 Rémi Denis-Courmont 2011-01-22 21:35:28 UTC
In my opinion, the real problem is that Qt QProcess relies on a signal handler to watch for process exit. This is not cooperative... VLC has multiple threads in different components, that do create child processes. Yet there can be only one signal handler for SIGCHLD at a time and it will catch all process terminations.

The only portable thread-cooperative mechanism to be notified of the termination of a child process terminate is more or less:

    while (waitpid(pid, 0, &status) != pid);

Indeed, this is how VLC's own code waits for child processes.

Obviously, this would be difficult to integrate with a poll/select main loop. Then, something like this would be needed:
 - create a pipe,
 - create a thread (write end of the pipe and child process PID as parameters),
 - register the read end of the pipe to the main loop,
 - thread: call waitpid() from the thread entry,
 - thread: write the process exit status to the pipe,
 - main loop wakes up,
 - read the exit status from the pipe,
 - destroy the pipe and the thread.
This is admittedly not very straight forward nor very elegant. But I cannot think of any simpler yet safe approach.

Nevertheless as far as this particular bug is concerned, VLC freezes. That means the KDE code is waiting for the process synchronously. So there should be no need to integrate with the main loop.
Comment 22 Dawit Alemayehu 2011-01-23 01:28:34 UTC
(In reply to comment #21)
> In my opinion, the real problem is that Qt QProcess relies on a signal handler
> to watch for process exit. This is not cooperative... VLC has multiple threads
> in different components, that do create child processes. Yet there can be only
> one signal handler for SIGCHLD at a time and it will catch all process
> terminations.

Yes, the subtle problem with UNIX kernels only providing a non-flexiable signal mechanism to determine whether a process is still around is well known. You can see

> The only portable thread-cooperative mechanism to be notified of the
> termination of a child process terminate is more or less:
> 
>     while (waitpid(pid, 0, &status) != pid);

Not really. See Thiago's response to see what they are doing in QProcess itself:
http://lists.kde.org/?l=kde-core-devel&m=129572982213216&w=2

You can find the entire thread I started for this issue here:
http://lists.kde.org/?t=129572447500001&r=1&w=2

> Indeed, this is how VLC's own code waits for child processes.

> Obviously, this would be difficult to integrate with a poll/select main loop.
> Then, something like this would be needed:
>  - create a pipe,
>  - create a thread (write end of the pipe and child process PID as parameters),
>  - register the read end of the pipe to the main loop,
>  - thread: call waitpid() from the thread entry,
>  - thread: write the process exit status to the pipe,
>  - main loop wakes up,
>  - read the exit status from the pipe,
>  - destroy the pipe and the thread.
> This is admittedly not very straight forward nor very elegant. But I cannot
> think of any simpler yet safe approach.

I know the only simple and elegant solution would be for kernels to provide a better mechanism for being informed of child process terminations, but wouldn't the mechanism used in QProcess, as Thiago suggests, a viable solution for you in VLC ?
Comment 23 Rémi Denis-Courmont 2011-01-23 09:37:21 UTC
(In reply to comment #22)
> > The only portable thread-cooperative mechanism to be notified of the
> > termination of a child process terminate is more or less:
> > 
> >     while (waitpid(pid, 0, &status) != pid);
> 
> Not really. See Thiago's response to see what they are doing in QProcess
> itself:
> http://lists.kde.org/?l=kde-core-devel&m=129572982213216&w=2

That is NOT a solution. As I already said, and as is written in the VLC source code, any library that relies on setting its own signal handler in a multi-threaded application like VLC is BROKEN BY DESIGN.

(...)
> I know the only simple and elegant solution would be for kernels to provide a
> better mechanism for being informed of child process terminations, but
> wouldn't the mechanism used in QProcess, as Thiago suggests, a viable
> solution for you in VLC ?

There can only be one signal handler for SIGCHLD (or any other signal). It is only logical that VLC / the main() function takes care of it. Qt cannot rely on being able to override that. In fact, we cannot warrant that some *other* broken library will not attempt to override SIGCHLD too. And then it's back to square 1 for Qt: its signal handler won't get called.
Comment 24 Texstar 2011-01-29 21:32:47 UTC
What is the solution?
Comment 25 stitch 2011-01-30 12:28:45 UTC
I also have this problem with VLC and latest Opera on Linux.
The program hangs and after a minute it opens the dialog.
Was MUCH better on KDE 4.5, where it opened just immediately.

As this is really a PITA, i think this should get HIGH
priority.
Comment 26 Rémi Denis-Courmont 2011-01-30 13:51:01 UTC
VLC 1.1.7 blacklists the KDE GUI platform for Qt to bypass this bug as well as bug #234484. On the downside, it looks ugly.
Comment 27 nucleo 2011-01-31 23:08:50 UTC
(In reply to comment #26)
> VLC 1.1.7 blacklists the KDE GUI platform for Qt to bypass this bug as well as
> bug #234484. On the downside, it looks ugly.

Here message on vlc-devel about this:
http://mailman.videolan.org/pipermail/vlc-devel/2011-January/078770.html

I have build vlc 1.1.7. It still uses KDE GUI and hangs on open file dialog and then crashes when closing.

http://nucleo.fedorapeople.org/vlc-1.1.7.strace
http://nucleo.fedorapeople.org/vlc-1.1.7.gdb
Comment 28 Texstar 2011-01-31 23:39:31 UTC
Is there something I can take from kde 4.5.5 and put in 4.6.0 that would temporarily solve this issue until it is properly addressed?
Comment 29 Dawit Alemayehu 2011-02-01 04:07:56 UTC
First, let us not mix separate bugs into this report. The issue of the crash is something I canot duplicate with VLC 1.1.6 and stock KDE 4.6. Even if I could the crash is completely unrelated to the freeze in this case.

I have already researched and identified the cause of freeze. It just so happens that KDE is caught in the middle of this issue as a result of a decision made upstream by the library developers and downstream by the app developers. See the discussion at link below for the details:

http://lists.kde.org/?t=129572447500001&r=1&w=2.

I personally tried to workaround this issue in KDE KProcess by attempting to remove the signals VLC blocks, but that was unsuccessful ; so at this point there is unfortunately no easy fix for the freeze...
Comment 30 Dawit Alemayehu 2011-02-01 04:18:45 UTC
(In reply to comment #26)
> VLC 1.1.7 blacklists the KDE GUI platform for Qt to bypass this bug as well as
> bug #234484. On the downside, it looks ugly.

What exactly do you suggest we do about this ? The freeze happens because a code path that uses QProcess is encountered when the KFileDialog is invoked. The last I checked, QProcess is part of Qt. Anyhow, I agree with your earlier stance about relying on signals within a library, but it is not KDE that is doing this! It is Qt's QProcess and short of not using that class, for which we have no substitute, there is nothing we can do about this.
Comment 31 Dawit Alemayehu 2011-02-02 18:54:54 UTC
Git commit 449d49908ce610d9af4e8e3da89466f168f66bc3 by Dawit Alemayehu.
Committed on 02/02/11 at 16:55.
Pushed by adawit into branch 'master'.

Instead of using QProcess to determine the version number of the update-mime-database executable,
open it and read its contents directly to extract the version number. This should fix the freezing
issues exhibited in applications like VLC that block SIGCHLD, which QProcess needs to do its job.
See http://lists.kde.org/?t=129572447500001&r=1&w=2 for details on this issue.

BUG: 260719

M  +6    -9    kdecore/services/kmimetyperepository.cpp     

http://commits.kde.org/kdelibs/449d49908ce610d9af4e8e3da89466f168f66bc3
Comment 32 Kevin Kofler 2011-02-02 19:16:24 UTC
Scanning a binary for a string strikes me as an extraordinarily bad idea!

Can't we read the version from /usr/share/pkgconfig/shared-mime-info.pc instead? This is exactly what that file is installed for (and in fact other packages also use it at runtime, that's why that file is not relegated to a -devel package in Fedora, and I'd expect other distributions to also ship this in the runtime shared-mime-info package for that reason), and it'd be both much faster and less prone to trouble (e.g. scanning the executable breaks if somebody compresses it with upx!) than scanning the binary.
Comment 33 Dawit Alemayehu 2011-02-02 19:34:23 UTC
(In reply to comment #32)
> Scanning a binary for a string strikes me as an extraordinarily bad idea!
> 
> Can't we read the version from /usr/share/pkgconfig/shared-mime-info.pc
> instead? This is exactly what that file is installed for (and in fact other
> packages also use it at runtime, that's why that file is not relegated to a
> -devel package in Fedora, and I'd expect other distributions to also ship this
> in the runtime shared-mime-info package for that reason), and it'd be both much
> faster and less prone to trouble (e.g. scanning the executable breaks if
> somebody compresses it with upx!) than scanning the binary.

Yes, I know. The commit was caused by accidental git push which I have already reverted. See http://quickgit.kde.org/?p=kdelibs.git&a=commit&h=7fb75cb42a6d75d478655330861899f5efd9cb6e

Anyhow, I have reopened the ticket...
Comment 34 Texstar 2011-02-02 21:26:02 UTC
(In reply to comment #32)
> Can't we read the version from /usr/share/pkgconfig/shared-mime-info.pc
> instead? This is exactly what that file is installed for (and in fact other
> packages also use it at runtime, that's why that file is not relegated to a
> -devel package in Fedora, and I'd expect other distributions to also ship this
> in the runtime shared-mime-info package for that reason), and it'd be both much
> faster and less prone to trouble (e.g. scanning the executable breaks if
> somebody compresses it with upx!) than scanning the binary.

I can confirm Fedora, Mandriva, Opensuse and PCLinuxOS include the shared-mime-info.pc in their main shared-mime-info package. I haven't checked the Debian distributions as yet.
Comment 35 nucleo 2011-02-02 21:29:34 UTC
(In reply to comment #34)
> I can confirm Fedora, Mandriva, Opensuse and PCLinuxOS include the
> shared-mime-info.pc in their main shared-mime-info package. I haven't checked
> the Debian distributions as yet.

There is in Debian /usr/share/pkgconfig/shared-mime-info.pc:

http://packages.debian.org/lenny/i386/shared-mime-info/filelist
Comment 37 Eric Hameleers 2011-02-02 21:48:16 UTC
Slackware ships this file as:

/usr/lib64/pkgconfig/shared-mime-info.pc (64-bit)
/usr/lib/pkgconfig/shared-mime-info.pc (32-bit)

The directory is found by examining the paths listed in $PKG_CONFIG_PATH

Eric
Comment 38 Kevin Kofler 2011-02-02 22:01:01 UTC
Then Slackware is broken. This file is not arch-dependent, I don't see why it's being installed into the multilibbed directories.
Comment 39 Eric Hameleers 2011-02-02 22:08:43 UTC
Slackware is not broken. Who are you to determine that? The information contained in the pkg-config files is arch-dependent. Therefore an arch-dependent location is as good as any other location.
Anyway, the proper way to find the location of the .pc files is to examine the $PKG_CONFIG_PATH environment variable - not to take a wild guess as to the location of that directory.

Eroc
Comment 40 Robby Workman 2011-02-02 22:22:34 UTC
Oh, come on, Kevin - let's not derail the bug report with that sort of thing.  Slackware puts all of the pkgconfig files in one place, and /usr/share/pkgconfig is a symlink to $libdir/pkgconfig -- it might not fit your view of "how things should be," but it's a far cry from "broken."
Comment 41 Kevin Kofler 2011-02-02 22:24:49 UTC
> Slackware is not broken. Who are you to determine that? The information
> contained in the pkg-config files is arch-dependent.

No. Some pkg-config files contain arch-dependent information, others don't. That's exactly why there's /usr/lib*/pkgconfig on one hand and /usr/share/pkgconfig on the other.

The contents of this particular file are:
> prefix=/usr
>
> Name: shared-mime-info
> Description: Freedesktop common MIME database
> Version: 0.80
> Requires:
> Libs:
> Cflags:

Now tell me what in there is arch-dependent.

> Therefore an arch-dependent location is as good as any other location.

No. Putting everything into the arch-dependent /usr/lib*/pkgconfig is wrong. It means you're installing 2 copies of one and the same file, for no reason.

> Anyway, the proper way to find the location of the .pc files is to examine the
> $PKG_CONFIG_PATH environment variable

No. Wrong. The default path is hardcoded in pkg-config. The $PKG_CONFIG_PATH environment variable is NOT SET AT ALL in Fedora. Examining the empty string will lead you exactly nowhere.

> not to take a wild guess as to the location of that directory.

It's the best we can do without invoking pkg-config, which would mean using QProcess again.
Comment 42 Kevin Kofler 2011-02-02 22:26:48 UTC
> and /usr/share/pkgconfig is a symlink to $libdir/pkgconfig

Well, if /usr/share/pkgconfig is a symlink to where the file actually is, then hardcoding /usr/share/pkgconfig/shared-mime-info.pc will just work. So I don't know why there's any objection.

> it might not fit your view of "how things should be," but it's a far cry from
> "broken."

Having the arch-independent pkgconfig directory be a symlink to the arch-dependent one breaks multilib egregiously (makes me wonder why you're bothering with /usr/lib64 at all!), so yes, this is broken. But it's irrelevant to the issue at hand.
Comment 43 Robby Workman 2011-02-02 22:32:08 UTC
(In reply to comment #42)
> > and /usr/share/pkgconfig is a symlink to $libdir/pkgconfig
> 
> Well, if /usr/share/pkgconfig is a symlink to where the file actually is, then
> hardcoding /usr/share/pkgconfig/shared-mime-info.pc will just work. So I don't
> know why there's any objection.


There was no objection, other than to the "Slackware is broken" comment :-)

 
> > it might not fit your view of "how things should be," but it's a far cry from
> > "broken."
> 
> Having the arch-independent pkgconfig directory be a symlink to the
> arch-dependent one breaks multilib egregiously (makes me wonder why you're
> bothering with /usr/lib64 at all!), so yes, this is broken. But it's irrelevant
> to the issue at hand.


Irrelevant *and* wrong.  Multilib works fine on Slackware.  Thanks for your concern though.  Let's just end this - it's going nowhere :-)
Comment 44 Kevin Kofler 2011-02-02 22:38:25 UTC
So we agree that /usr/share/pkgconfig/shared-mime-info.pc should work on all distros (including Slackware)?
Comment 45 Robby Workman 2011-02-02 22:41:14 UTC
Yes, we can agree on that point.  :-)
Comment 46 Thiago Macieira 2011-02-02 23:16:21 UTC
(In reply to comment #21)
> In my opinion, the real problem is that Qt QProcess relies on a signal handler
> to watch for process exit. This is not cooperative... 

Sure it is. Anyone can install a SIGCHLD handler. They just need to invoke the other handlers in the chain when they are invoked.

The only problem is that you can't remove a SIGCHLD handler, unless you do it in perfect LIFO order.

> VLC has multiple threads
> in different components, that do create child processes. Yet there can be only
> one signal handler for SIGCHLD at a time and it will catch all process
> terminations.

That's where you're wrong. There can be multiple SIGCHLD handlers, like I explained above.

> The only portable thread-cooperative mechanism to be notified of the
> termination of a child process terminate is more or less:
> 
>     while (waitpid(pid, 0, &status) != pid);
> 
> Indeed, this is how VLC's own code waits for child processes.

You're again wrong, because Qt has a cooperative, efficient and thread-safe implementation. I'll explain it in a second.

The above code has two problems: it blocks (so no select/poll-based loop integration) and it waits for one single PID.

> Obviously, this would be difficult to integrate with a poll/select main loop.
> Then, something like this would be needed:
>  - create a pipe,
>  - create a thread (write end of the pipe and child process PID as parameters),
>  - register the read end of the pipe to the main loop,
>  - thread: call waitpid() from the thread entry,
>  - thread: write the process exit status to the pipe,
>  - main loop wakes up,
>  - read the exit status from the pipe,
>  - destroy the pipe and the thread.
> This is admittedly not very straight forward nor very elegant. But I cannot
> think of any simpler yet safe approach.

I can.

Your solution is to start one thread per PID we want to watch. That's probably thread-safe but extremely wasteful. What's more, there's no way of notifying the watcher thread to stop watching. This probably will lead to hangs-at-exit because not all threads have exited.

> Nevertheless as far as this particular bug is concerned, VLC freezes. That
> means the KDE code is waiting for the process synchronously. So there should be
> no need to integrate with the main loop.

There is. 

The reason why there's a loop integration is that the particular code is trying to read from the pipes connected to the child process. To do that, it waits on a select(2) with three pipes enabled: the two connected to the subprocess's stdout and stderr and a third pipe which notifies that the process has exited.

When a subprocess exits, the stdout and stderr pipes get closed, so we don't need to wait for them anymore. However, the pipes can be closed before the process exits, so they are not an indication that it has happened.

The third pipe's other end is connected to a thread which will do more or less what you described: it will waitpid on the PID and write a byte if it has successfully reaped the subprocess.

However, unlike your solution, there's only one such thread running and it uses the WNOHANG flag when calling waitpid(2). It checks all the PIDs launched from QProcess. That is is efficient and thread-safe.

All Qt needs is to know when to try and reap the processes. It needs an indication that a child process has exited. That's where SIGCHLD comes in.

The Qt system is efficient, correct, cooperative and thread-safe. It works on all Unix systems with purely cross-platform and entirely POSIX-compliant code. I will *NOT* change it unless it's for something better -- and there's no such thing today. 

The only thing I may do to "fix" this issue is to reinstall the SIGCHLD handler and unblock the signal -- that is, undo the damage that VLC did.

I would rather that VLC corrected its usage of SIGCHLD. You're starting from the wrong assumption that there can be only one handler. If you need help in fixing this issue or understanding more how to do it and how to cooperate with Qt's handler, please contact me directly by email.

PS: the glib code for gspawn does the *exact* same thing as Qt does, except that it forgets to chain to the previous SIGCHLD handler. I'll prepare a patch and submit to them.
Comment 47 Kevin Kofler 2011-02-02 23:24:32 UTC
> What's more, there's no way of notifying the watcher thread to stop watching.

Uhm, pthread_cancel? (But ugh!)
Comment 48 Rémi Denis-Courmont 2011-02-03 09:15:22 UTC
(In reply to comment #46)
> (In reply to comment #21)
> > In my opinion, the real problem is that Qt QProcess relies on a signal
> > handler to watch for process exit. This is not cooperative... 
> 
> Sure it is. Anyone can install a SIGCHLD handler. They just need to invoke
> the other handlers in the chain when they are invoked.

Oh yes. But that only works (safely) in single-threaded processes. Otherwise, chaining signal handlers is more likely to crash than anything.

> The only problem is that you can't remove a SIGCHLD handler, unless you do it
> in perfect LIFO order.

Exactly. And that you cannot promise in a multithreaded context like VLC.

> > VLC has multiple threads in different components, that do create child
> > processes. Yet there can be only one signal handler for SIGCHLD at a
> > time and it will catch all process terminations.
> 
> That's where you're wrong. There can be multiple SIGCHLD handlers, like I
> explained above.

No. There cannot, not in a multithread context. So it only safely works as long as ONLY Qt is does this, which makes Qt not cooperative.

> > The only portable thread-cooperative mechanism to be notified of the
> > termination of a child process terminate is more or less:
> > 
> >     while (waitpid(pid, 0, &status) != pid);
> > 
> > Indeed, this is how VLC's own code waits for child processes.
> 
> You're again wrong, because Qt has a cooperative, efficient and thread-safe
> implementation. I'll explain it in a second.

It's not thread-safe, it's conditionally thread-safe which is not thread-safe. That's a lying.

If it were thread-safe, this bug would not exist in the first place.

> The above code has two problems: it blocks (so no select/poll-based loop
> integration) and it waits for one single PID.

> > Obviously, this would be difficult to integrate with a poll/select main
> > loop.
> > Then, something like this would be needed:
> >  - create a pipe,
> >  - create a thread (write end of the pipe and child process PID as parameters),
> >  - register the read end of the pipe to the main loop,
> >  - thread: call waitpid() from the thread entry,
> >  - thread: write the process exit status to the pipe,
> >  - main loop wakes up,
> >  - read the exit status from the pipe,
> >  - destroy the pipe and the thread.
> > This is admittedly not very straight forward nor very elegant. But I cannot
> > think of any simpler yet safe approach.
> 
> I can.
> 
> Your solution is to start one thread per PID we want to watch.
> That's probably thread-safe but extremely wasteful.

The cost of thread, especially if the stack size is kept low, is peanuts to the cost of forking that QProcess fundamentally does.

> What's more, there's no way of notifying the watcher thread to stop watching.
> This probably will lead to hangs-at-exit because not all threads have exited.

That's not correct; waitpid() is a cancellation point. You just need to make sure the thread entry point has C linkage and no C++ objects.

But no matter what you do (SIGCHLD, waitpid, etc), "stop watching" will leak the zombie process until your own process exits, which is a rather bad idea. If you really want to abort a subprocess, it's generally a better idea to close its input pipe, or more radically to close its output pipe and/or kill() it.

Eventually, you'll need to wait for waitpid() anyway; you just have better chances that it won't block.

(...)
> However, unlike your solution, there's only one such thread running and it
> uses the WNOHANG flag when calling waitpid(2). It checks all the PIDs
> launched from QProcess. That is is efficient and thread-safe.

Unlike my solution, it fails miserably in thread-aware processes like VLC that use sigwait() for synchronous signal delivery.

> All Qt needs is to know when to try and reap the processes. It needs an
> indication that a child process has exited. That's where SIGCHLD comes in.
> 
> The Qt system is efficient, correct, cooperative and thread-safe. It works on
> all Unix systems with purely cross-platform and entirely POSIX-compliant code.
> I will *NOT* change it unless it's for something better -- and there's no such
> thing today. 

It is not thread-safe and therefore not cooperative. Please stop the lies.

> The only thing I may do to "fix" this issue is to reinstall the SIGCHLD
> handler and unblock the signal -- that is, undo the damage that VLC did.

That won't even work.

Contrary to your statement, VLC does not even install any signal handler on SIGCHLD. It just restores once SIG_DFL at the very beginning of main() in case the parent process had set SIG_IGN. Qt is initialized much much later. 

Contrarily also, VLC does not block SIGCHLD. Otherwise waitpid() wouldn't work as far as I know. It blocks it in all thread except the main() one to avoid unintended EINTR throughout the code base.

> I would rather that VLC corrected its usage of SIGCHLD. You're starting from
> the wrong assumption that there can be only one handler. If you need help in
> fixing this issue or understanding more how to do it and how to cooperate
> with Qt's handler, please contact me directly by email.

No, you are starting with the wrong assumption that VLC has a handler and removes Qt's own. It has *none* and it does not remove any.

The only signal handler VLC has is SIG_IGN for SIGPIPE for obvious reasons.
Comment 49 Rémi Denis-Courmont 2011-02-03 09:18:26 UTC
Small correction: in VLC 1.1.x, sigwait() is not in the main() thread, it's in the so-called signal thread (modules/control/signals.c).  But that makes no difference to the rest of the discussion: there's *one* thread where SIGCHLD is *not* blocked.
Comment 50 Thiago Macieira 2011-02-03 09:48:55 UTC
Rémi: continuing the discussion with you outside of bugzilla.
Comment 51 Dawit Alemayehu 2011-02-05 00:36:53 UTC
Git commit 7ca7e81303c50769e286897be0afe0793dabdf52 by Dawit Alemayehu.
Committed on 05/02/11 at 00:29.
Pushed by adawit into branch 'KDE/4.6'.

Workaround for the hang (freeze) when opening VLC's file dialog under KDE.
See http://git.reviewboard.kde.org/r/100539/ for the details.

BUG:260719
REVIEW:100539

M  +74   -19   kdecore/services/kmimetyperepository.cpp     

http://commits.kde.org/kdelibs/7ca7e81303c50769e286897be0afe0793dabdf52
Comment 52 Dawit Alemayehu 2011-02-05 01:04:24 UTC
Git commit 4d0569da8d362b6869158beb724319023e4c705a by Dawit Alemayehu.
Committed on 05/02/11 at 00:29.
Pushed by adawit into branch 'master'.

Workaround for the hang (freeze) when opening VLC's file dialog under KDE.
See http://git.reviewboard.kde.org/r/100539/ for the details.

BUG:260719
REVIEW:100539
(cherry picked from commit 7ca7e81303c50769e286897be0afe0793dabdf52)

M  +74   -19   kdecore/services/kmimetyperepository.cpp     

http://commits.kde.org/kdelibs/4d0569da8d362b6869158beb724319023e4c705a
Comment 53 lcn.mustard 2011-03-26 12:40:44 UTC
 This problem also happens in kde 4.6.1 . After installing kde4.6.1, the "open file dialog" still slow like a turtle. http://forum.videolan.org/viewtopic.php?f=13&t=89225&p=294114#p294114
Comment 54 Piotr Keplicz 2011-03-26 15:33:49 UTC
Try VLC 1.1.7 or later.
Comment 55 Dawit Alemayehu 2011-03-26 17:38:16 UTC
(In reply to comment #53)
>  This problem also happens in kde 4.6.1 . After installing kde4.6.1, the "open
> file dialog" still slow like a turtle.
> http://forum.videolan.org/viewtopic.php?f=13&t=89225&p=294114#p294114

Despite the insinuations in that forum response that this is somehow a KDE bug, there is nothing KDE can to fix it because the problem IS NOT in KDE! Until Qt's QProcess stops relying on SIGCHLD signals for the children processes it creates or VLC stops blocking the said signal, this problem will never be resolved. Period!

My previous patch only fixed one single code path that was using QProcess within kdelibs. That was possible because we could avoid the use of QProcess by using a workaround. However, that is not possible in every instance where QProcess is used within kdelibs and there are more than a few places where QProcess is indeed used.

I have tested VLC 1.1.7 and the problem is encountered because the code that checks for the presence of samba shares, KSambaShare, in the filedialog module uses QProcess! And there you have the problem. So until either the UPSTREAM or the DOWNSTREAM developers decide to do something about this, there is nothing we can do.
Comment 56 Dawit Alemayehu 2011-03-26 17:54:14 UTC
The closure status is incorrect. If I could have marked it both UPSTREAM AND DOWNSTREAM, I would have done so. Here are a couple of links for future reference:

http://forum.videolan.org/viewtopic.php?f=13&t=85408#p282713
http://lists.kde.org/?t=129572447500001&r=1&w=2
Comment 57 lcn.mustard 2011-03-26 20:24:35 UTC
Yes, I have samba shares and nfs, but in computer nº1 vlc 1.1.14 works great ( kubuntu lucid-kde 4.5.3) and in pc nº2  vlc 1.1.14 have this issue ( kubuntu maverick kde4.6.1) Right now, I dont use the " open file " dialog... I'm using Dolphin to open the files until it can be fix it. Thanks!
Comment 58 lcn.mustard 2011-03-26 20:58:52 UTC
(In reply to comment #54)
>Try VLC 1.1.7 or later.

Thanks a lot!! following your tip, and installing vlc 1.1.18, That issue has been resolved. And it's working OK now. Thanks!
Comment 59 Patrick 2011-04-18 17:55:59 UTC
I'm using KDE 4.6.1 and VLC 1.1.8 on Fedora 14 x86_64. I can make VLC crash by doing this: 1) start VLC 2) try to open a file. 

> VLC media player 1.1.8 The Luggage (revision exported)
> Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS")
> Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE")
> Blocked: call to setlocale(6, "")
> Blocked: call to setlocale(6, "")
> Blocked: call to putenv("LANGUAGE=")
> KGlobal::locale::Warning your global KLocale is being recreated with a valid > main component instead of a fake component, this usually means you tried to 
> call i18n related functions before your main component was created. You 
> should not do that since it most likely will not work 
> Speicherzugriffsfehler (Speicherabzug geschrieben)
Comment 60 David Faure 2013-01-11 08:47:15 UTC
Git commit e6adafef04a29f4509cb8bb9ab5ceea43fd1a3d8 by David Faure.
Committed on 11/01/2013 at 09:47.
Pushed by dfaure into branch 'KDE/4.10'.

Use "version" file from shared-mime-info >= 0.91, if available.

This is faster and more robust than the existing solutions
(pkgconfig, or QProcess("update-mime-database -v").

M  +15   -2    kdecore/services/kmimetyperepository.cpp

http://commits.kde.org/kdelibs/e6adafef04a29f4509cb8bb9ab5ceea43fd1a3d8