260719 2010-12-19 17:10:01 +0000 Vlc hangs on open file dialog 2013-03-02 16:19:52 +0000 1 1 8 I don't know kde general 4.6 Arch Linux Linux RESOLVED UPSTREAM NOR normal --- 1 the.sonda90 unassigned-bugs-null adawit alien andresbajotierra biasquez csw gabriello.ramirez keplicz kevin.kofler kybernetikkollektiv lcn.mustard linux.nerdy.kid nucleo rdieter remi rw sandy sergei.kasaurov spatz stitch sven.burmeister texstar thiago victorjss zanetu 101 oldest_to_newest 1061677 0 the.sonda90 2010-12-19 17:10:01 +0000 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. 1061720 1 andresbajotierra 2010-12-19 19:00:10 +0000 [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 1061748 2 the.sonda90 2010-12-19 19:40:20 +0000 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?) 1061754 3 andresbajotierra 2010-12-19 19:45:43 +0000 [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 1061762 4 the.sonda90 2010-12-19 20:05:31 +0000 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--- 1062639 5 andresbajotierra 2010-12-21 18:18:10 +0000 [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 1064608 6 the.sonda90 2010-12-27 13:47:27 +0000 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. 1065128 7 andresbajotierra 2010-12-29 00:51:56 +0000 [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 1067169 8 alien 2011-01-03 00:41:32 +0000 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. 1067171 9 alien 2011-01-03 00:46:50 +0000 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 1069852 10 sergei.kasaurov 2011-01-07 21:02:29 +0000 I can confirm this bug for my VLC and KDE 4.5.80+ (including the latest RC2). 1069899 11 sandy 2011-01-07 22:50:03 +0000 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 1069999 12 linux.nerdy.kid 2011-01-08 04:18:57 +0000 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. 1070116 13 biasquez 2011-01-08 13:37:02 +0000 i have this issue with kde 4.6 rc2 and vlc 1.1.5 and 1.2 1070123 14 biasquez 2011-01-08 13:49:13 +0000 #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 1070514 15 gabriello.ramirez 2011-01-09 06:15:38 +0000 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 1070589 16 dave.lepore 2011-01-09 13:01:14 +0000 *** This bug has been confirmed by popular vote. *** 1072094 17 sandy 2011-01-12 03:22:17 +0000 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. 1072103 18 sandy 2011-01-12 03:55:32 +0000 Also, if you use the "open file" dialog WHILE there is something already playing in VLC, it will work perfectly as well. 1076915 19 adawit 2011-01-22 00:33:34 +0000 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... 1076920 20 56310 adawit 2011-01-22 00:36:48 +0000 Created attachment 56310 vlc file open dialog backtrace... 1077317 21 remi 2011-01-22 21:35:28 +0000 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. 1077372 22 adawit 2011-01-23 01:28:34 +0000 (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 ? 1077416 23 remi 2011-01-23 09:37:21 +0000 (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. 1080876 24 texstar 2011-01-29 21:32:47 +0000 What is the solution? 1081062 25 stitch 2011-01-30 12:28:45 +0000 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. 1081113 26 remi 2011-01-30 13:51:01 +0000 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. 1082020 27 nucleo 2011-01-31 23:08:50 +0000 (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 1082035 28 texstar 2011-01-31 23:39:31 +0000 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? 1082131 29 adawit 2011-02-01 04:07:56 +0000 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... 1082134 30 adawit 2011-02-01 04:18:45 +0000 (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. 1082871 31 adawit 2011-02-02 18:54:54 +0000 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 1082878 32 kevin.kofler 2011-02-02 19:16:24 +0000 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. 1082884 33 adawit 2011-02-02 19:34:23 +0000 (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... 1082929 34 texstar 2011-02-02 21:26:02 +0000 (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. 1082932 35 nucleo 2011-02-02 21:29:34 +0000 (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 1082935 36 nucleo 2011-02-02 21:39:04 +0000 shared-mime-info.pc also included in Gentoo: http://www.portagefilelist.de/index.php/Special:PFLQueryTest?dir=x11-misc&package=shared-mime-info&version=0.90&searchpkgfiles=lookup&lookup=pkgfiles#result and in Ubuntu: http://packages.ubuntu.com/maverick/i386/shared-mime-info/filelist 1082943 37 alien 2011-02-02 21:48:16 +0000 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 1082947 38 kevin.kofler 2011-02-02 22:01:01 +0000 Then Slackware is broken. This file is not arch-dependent, I don't see why it's being installed into the multilibbed directories. 1082952 39 alien 2011-02-02 22:08:43 +0000 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 1082967 40 rw 2011-02-02 22:22:34 +0000 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." 1082968 41 kevin.kofler 2011-02-02 22:24:49 +0000 > 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. 1082969 42 kevin.kofler 2011-02-02 22:26:48 +0000 > 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. 1082971 43 rw 2011-02-02 22:32:08 +0000 (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 :-) 1082973 44 kevin.kofler 2011-02-02 22:38:25 +0000 So we agree that /usr/share/pkgconfig/shared-mime-info.pc should work on all distros (including Slackware)? 1082976 45 rw 2011-02-02 22:41:14 +0000 Yes, we can agree on that point. :-) 1083010 46 thiago 2011-02-02 23:16:21 +0000 (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. 1083012 47 kevin.kofler 2011-02-02 23:24:32 +0000 > What's more, there's no way of notifying the watcher thread to stop watching. Uhm, pthread_cancel? (But ugh!) 1083097 48 remi 2011-02-03 09:15:22 +0000 (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. 1083099 49 remi 2011-02-03 09:18:26 +0000 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. 1083109 50 thiago 2011-02-03 09:48:55 +0000 Rémi: continuing the discussion with you outside of bugzilla. 1083965 51 adawit 2011-02-05 00:36:53 +0000 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 1083979 52 adawit 2011-02-05 01:04:24 +0000 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 1101383 53 lcn.mustard 2011-03-26 12:40:44 +0000 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 1101479 54 keplicz 2011-03-26 15:33:49 +0000 Try VLC 1.1.7 or later. 1101522 55 adawit 2011-03-26 17:38:16 +0000 (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. 1101528 56 adawit 2011-03-26 17:54:14 +0000 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 1101556 57 lcn.mustard 2011-03-26 20:24:35 +0000 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! 1101564 58 lcn.mustard 2011-03-26 20:58:52 +0000 (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! 1109210 59 kybernetikkollektiv 2011-04-18 17:55:59 +0000 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) 1330952 60 faure 2013-01-11 08:47:15 +0000 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 56310 2011-01-22 00:36:48 +0000 2011-01-22 00:36:48 +0000 vlc file open dialog backtrace... vlc_file_open_dialog_bt.txt text/plain 6747 adawit VGhyZWFkIDQgKFRocmVhZCAweDdmZmZiOTBmODcwMCAoTFdQIDEyOTU3KSk6CiMwICAweDAwMDA3 ZmZmZjcyMjU2ZDMgaW4gc2VsZWN0ICgpIGZyb20gL2xpYi9saWJjLnNvLjYKIzEgIDB4MDAwMDdm ZmZkZmJmYWYxYSBpbiBxdF9zYWZlX3NlbGVjdChpbnQsIGZkX3NldCosIGZkX3NldCosIGZkX3Nl dCosIHRpbWV2YWwgY29uc3QqKSAoKSBmcm9tIC91c3IvbGliL2xpYlF0Q29yZS5zby40CiMyICAw eDAwMDA3ZmZmZGZiYWY1ZDggaW4gPz8gKCkgZnJvbSAvdXNyL2xpYi9saWJRdENvcmUuc28uNAoj MyAgMHgwMDAwN2ZmZmRmYmIwZTVlIGluID8/ICgpIGZyb20gL3Vzci9saWIvbGliUXRDb3JlLnNv LjQKIzQgIDB4MDAwMDdmZmZkZmI3MGY4MyBpbiBRUHJvY2Vzczo6d2FpdEZvckZpbmlzaGVkKGlu dCkgKCkgZnJvbSAvdXNyL2xpYi9saWJRdENvcmUuc28uNAojNSAgMHgwMDAwN2ZmZmI3NTIwOGRk IGluIEtNaW1lVHlwZVJlcG9zaXRvcnk6OnNoYXJlZE1pbWVJbmZvVmVyc2lvbiAodGhpcz0weGI4 ZGQ2MCkgYXQgL3Vzci9sb2NhbC9zcmMvS0RFL3RydW5rL2tkZWxpYnMva2RlY29yZS9zZXJ2aWNl cy9rbWltZXR5cGVyZXBvc2l0b3J5LmNwcDo2OTgKIzYgIDB4MDAwMDdmZmZiNzUxZWQzNSBpbiBL TWltZUdsb2JzRmlsZVBhcnNlcjo6cGFyc2VHbG9iRmlsZSAoZmlsZT0weDdmZmZiOTBmNDUwMCwg Zm9ybWF0PUtNaW1lR2xvYnNGaWxlUGFyc2VyOjpHbG9iczJXaXRoV2VpZ2h0LCBnbG9icz0uLi4p CiAgICBhdCAvdXNyL2xvY2FsL3NyYy9LREUvdHJ1bmsva2RlbGlicy9rZGVjb3JlL3NlcnZpY2Vz L2ttaW1lZ2xvYnNmaWxlcGFyc2VyLmNwcDo3NwojNyAgMHgwMDAwN2ZmZmI3NTFmNGI0IGluIEtN aW1lR2xvYnNGaWxlUGFyc2VyOjpwYXJzZUdsb2JGaWxlcyAoZ2xvYkZpbGVzPTx2YWx1ZSBvcHRp bWl6ZWQgb3V0PiwgcGFyc2VkRmlsZXM9Li4uKQogICAgYXQgL3Vzci9sb2NhbC9zcmMvS0RFL3Ry dW5rL2tkZWxpYnMva2RlY29yZS9zZXJ2aWNlcy9rbWltZWdsb2JzZmlsZXBhcnNlci5jcHA6NjUK IzggIDB4MDAwMDdmZmZiNzUxZjVmZCBpbiBLTWltZUdsb2JzRmlsZVBhcnNlcjo6cGFyc2VHbG9i cyAodGhpcz08dmFsdWUgb3B0aW1pemVkIG91dD4sIGdsb2JGaWxlcz08dmFsdWUgb3B0aW1pemVk IG91dD4pCiAgICBhdCAvdXNyL2xvY2FsL3NyYy9LREUvdHJ1bmsva2RlbGlicy9rZGVjb3JlL3Nl cnZpY2VzL2ttaW1lZ2xvYnNmaWxlcGFyc2VyLmNwcDo0NAojOSAgMHgwMDAwN2ZmZmI3NTFmNmEz IGluIEtNaW1lR2xvYnNGaWxlUGFyc2VyOjpwYXJzZUdsb2JzICh0aGlzPTB4N2ZmZmI5MGY0NjMw KSBhdCAvdXNyL2xvY2FsL3NyYy9LREUvdHJ1bmsva2RlbGlicy9rZGVjb3JlL3NlcnZpY2VzL2tt aW1lZ2xvYnNmaWxlcGFyc2VyLmNwcDozOAojMTAgMHgwMDAwN2ZmZmI3NTI0Y2FmIGluIEtNaW1l VHlwZVJlcG9zaXRvcnk6OnBhcnNlR2xvYnMgKHRoaXM9MHhiOGRkNjApIGF0IC91c3IvbG9jYWwv c3JjL0tERS90cnVuay9rZGVsaWJzL2tkZWNvcmUvc2VydmljZXMva21pbWV0eXBlcmVwb3NpdG9y eS5jcHA6NTg2CiMxMSAweDAwMDA3ZmZmYjc1MjUwMDcgaW4gS01pbWVUeXBlUmVwb3NpdG9yeTo6 ZmluZEZyb21GaWxlTmFtZSAodGhpcz0weGI4ZGQ2MCwgZmlsZU5hbWU9Li4uLCBwTWF0Y2hpbmdF eHRlbnNpb249MHgwKQogICAgYXQgL3Vzci9sb2NhbC9zcmMvS0RFL3RydW5rL2tkZWxpYnMva2Rl Y29yZS9zZXJ2aWNlcy9rbWltZXR5cGVyZXBvc2l0b3J5LmNwcDoxOTQKIzEyIDB4MDAwMDdmZmZi NzUxYzUyNyBpbiBLTWltZVR5cGU6OmZpbmRCeVVybEhlbHBlciAoX3VybD0uLi4sIG1vZGU9PHZh bHVlIG9wdGltaXplZCBvdXQ+LCBpc19sb2NhbF9maWxlPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0Piwg ZGV2aWNlPTB4MCwgYWNjdXJhY3k9MHgwKQogICAgYXQgL3Vzci9sb2NhbC9zcmMvS0RFL3RydW5r L2tkZWxpYnMva2RlY29yZS9zZXJ2aWNlcy9rbWltZXR5cGUuY3BwOjIwMgojMTMgMHgwMDAwN2Zm ZmI3NTFjYmE1IGluIEtNaW1lVHlwZTo6ZmluZEJ5VXJsICh1cmw9Li4uLCBtb2RlPTAsIGlzX2xv Y2FsX2ZpbGU9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCBmYXN0X21vZGU9PHZhbHVlIG9wdGltaXpl ZCBvdXQ+LCBhY2N1cmFjeT08dmFsdWUgb3B0aW1pemVkIG91dD4pCiAgICBhdCAvdXNyL2xvY2Fs L3NyYy9LREUvdHJ1bmsva2RlbGlicy9rZGVjb3JlL3NlcnZpY2VzL2ttaW1ldHlwZS5jcHA6MzEw CiMxNCAweDAwMDA3ZmZmYjc1MWNjYzIgaW4gS01pbWVUeXBlOjppY29uTmFtZUZvclVybCAoX3Vy bD0uLi4sIG1vZGU9MCkgYXQgL3Vzci9sb2NhbC9zcmMvS0RFL3RydW5rL2tkZWxpYnMva2RlY29y ZS9zZXJ2aWNlcy9rbWltZXR5cGUuY3BwOjQ0NQojMTUgMHgwMDAwN2ZmZmI4OGM3MDYxIGluIEtV cmxDb21ib0JveDo6S1VybENvbWJvQm94UHJpdmF0ZTo6Z2V0SWNvbiAodGhpcz08dmFsdWUgb3B0 aW1pemVkIG91dD4sIHVybD08dmFsdWUgb3B0aW1pemVkIG91dD4pCiAgICBhdCAvdXNyL2xvY2Fs L3NyYy9LREUvdHJ1bmsva2RlbGlicy9raW8va2ZpbGUva3VybGNvbWJvYm94LmNwcDo0MzAKIzE2 IDB4MDAwMDdmZmZiODhjODM1YiBpbiBLVXJsQ29tYm9Cb3g6OnNldFVybHMgKHRoaXM9MHhjZDRk ZjAsIF91cmxzPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgcmVtb3ZlPTx2YWx1ZSBvcHRpbWl6ZWQg b3V0PikKICAgIGF0IC91c3IvbG9jYWwvc3JjL0tERS90cnVuay9rZGVsaWJzL2tpby9rZmlsZS9r dXJsY29tYm9ib3guY3BwOjIyOQojMTcgMHgwMDAwN2ZmZmFmZjc4OTQxIGluIEtGaWxlV2lkZ2V0 UHJpdmF0ZTo6cmVhZFJlY2VudEZpbGVzICh0aGlzPTB4YmUwZGIwLCBjZz0uLi4pIGF0IC91c3Iv bG9jYWwvc3JjL0tERS90cnVuay9rZGVsaWJzL2tmaWxlL2tmaWxld2lkZ2V0LmNwcDoxOTAwCiMx OCAweDAwMDA3ZmZmYWZmN2YxNWMgaW4gS0ZpbGVXaWRnZXRQcml2YXRlOjpyZWFkQ29uZmlnICh0 aGlzPTB4YmUwZGIwLCBjb25maWdHcm91cD0uLi4pIGF0IC91c3IvbG9jYWwvc3JjL0tERS90cnVu ay9rZGVsaWJzL2tmaWxlL2tmaWxld2lkZ2V0LmNwcDoxODA1CiMxOSAweDAwMDA3ZmZmYWZmODFl ZDIgaW4gS0ZpbGVXaWRnZXQ6OktGaWxlV2lkZ2V0ICh0aGlzPTB4YzAyNDIwLCBfc3RhcnREaXI9 PHZhbHVlIG9wdGltaXplZCBvdXQ+LCBwYXJlbnQ9PHZhbHVlIG9wdGltaXplZCBvdXQ+KQogICAg YXQgL3Vzci9sb2NhbC9zcmMvS0RFL3RydW5rL2tkZWxpYnMva2ZpbGUva2ZpbGV3aWRnZXQuY3Bw OjU4MwojMjAgMHgwMDAwN2ZmZmIwMWNjZWQ0IGluIEtGaWxlTW9kdWxlOjpjcmVhdGVGaWxlV2lk Z2V0ICh0aGlzPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0Piwgc3RhcnREaXI9Li4uLCBwYXJlbnQ9MHg3 ZmZmYjkwZjVhZjApCiAgICBhdCAvdXNyL2xvY2FsL3NyYy9LREUvdHJ1bmsva2RlbGlicy9rZmls ZS9rZmlsZW1vZHVsZS5jcHA6MzYKIzIxIDB4MDAwMDdmZmZiODg5MmY2MiBpbiBLRmlsZURpYWxv Zzo6S0ZpbGVEaWFsb2cgKHRoaXM9MHg3ZmZmYjkwZjVhZjAsIHN0YXJ0RGlyPS4uLiwgZmlsdGVy PS4uLiwgcGFyZW50PTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgY3VzdG9tV2lkZ2V0PTB4MCkKICAg IGF0IC91c3IvbG9jYWwvc3JjL0tERS90cnVuay9rZGVsaWJzL2tpby9rZmlsZS9rZmlsZWRpYWxv Zy5jcHA6MjY5CiMyMiAweDAwMDA3ZmZmYjg4OTdhM2MgaW4gS0ZpbGVEaWFsb2dRdE92ZXJyaWRl OjpnZXRPcGVuRmlsZU5hbWVzIChwYXJlbnQ9MHgwLCBjYXB0aW9uPS4uLiwgZGlyPS4uLiwgZmls dGVyPS4uLiwgc2VsZWN0ZWRGaWx0ZXI9MHgwLCBvcHRpb25zPS4uLikKICAgIGF0IC91c3IvbG9j YWwvc3JjL0tERS90cnVuay9rZGVsaWJzL2tpby9rZmlsZS9rZmlsZWRpYWxvZy5jcHA6MTIyNAoj MjMgMHgwMDAwN2ZmZmUwNTg3YzI4IGluIFFGaWxlRGlhbG9nOjpnZXRPcGVuRmlsZU5hbWVzKFFX aWRnZXQqLCBRU3RyaW5nIGNvbnN0JiwgUVN0cmluZyBjb25zdCYsIFFTdHJpbmcgY29uc3QmLCBR U3RyaW5nKiwgUUZsYWdzPFFGaWxlRGlhbG9nOjpPcHRpb24+KSAoKQogICBmcm9tIC91c3IvbGli L2xpYlF0R3VpLnNvLjQKIzI0IDB4MDAwMDdmZmZlMGM0YzQ4MSBpbiBEaWFsb2dzUHJvdmlkZXI6 OnNob3dTaW1wbGVPcGVuKFFTdHJpbmcgY29uc3QmLCBpbnQsIFFTdHJpbmcgY29uc3QmKSAoKSBm cm9tIC91c3IvbGliL3ZsYy9wbHVnaW5zL2d1aS9saWJxdDRfcGx1Z2luLnNvCiMyNSAweDAwMDA3 ZmZmZTBjNGQwYTEgaW4gRGlhbG9nc1Byb3ZpZGVyOjphZGRGcm9tU2ltcGxlKGJvb2wsIGJvb2wp ICgpIGZyb20gL3Vzci9saWIvdmxjL3BsdWdpbnMvZ3VpL2xpYnF0NF9wbHVnaW4uc28KIzI2IDB4 MDAwMDdmZmZlMGQxYTlhMiBpbiBEaWFsb2dzUHJvdmlkZXI6OnF0X21ldGFjYWxsKFFNZXRhT2Jq ZWN0OjpDYWxsLCBpbnQsIHZvaWQqKikgKCkgZnJvbSAvdXNyL2xpYi92bGMvcGx1Z2lucy9ndWkv bGlicXQ0X3BsdWdpbi5zbwojMjcgMHgwMDAwN2ZmZmRmYmU4MzFmIGluIFFNZXRhT2JqZWN0Ojph Y3RpdmF0ZShRT2JqZWN0KiwgUU1ldGFPYmplY3QgY29uc3QqLCBpbnQsIHZvaWQqKikgKCkgZnJv bSAvdXNyL2xpYi9saWJRdENvcmUuc28uNAojMjggMHgwMDAwN2ZmZmUwMGI2YzQyIGluIFFBY3Rp b246OnRyaWdnZXJlZChib29sKSAoKSBmcm9tIC91c3IvbGliL2xpYlF0R3VpLnNvLjQKIzI5IDB4 MDAwMDdmZmZlMDBiNmUzYSBpbiBRQWN0aW9uOjphY3RpdmF0ZShRQWN0aW9uOjpBY3Rpb25FdmVu dCkgKCkgZnJvbSAvdXNyL2xpYi9saWJRdEd1aS5zby40CiMzMCAweDAwMDA3ZmZmZTAwYjZmYjcg aW4gUUFjdGlvbjo6ZXZlbnQoUUV2ZW50KikgKCkgZnJvbSAvdXNyL2xpYi9saWJRdEd1aS5zby40 CiMzMSAweDAwMDA3ZmZmZTAwYmQyYjQgaW4gUUFwcGxpY2F0aW9uUHJpdmF0ZTo6bm90aWZ5X2hl bHBlcihRT2JqZWN0KiwgUUV2ZW50KikgKCkgZnJvbSAvdXNyL2xpYi9saWJRdEd1aS5zby40CiMz MiAweDAwMDA3ZmZmZTAwYzFkY2EgaW4gUUFwcGxpY2F0aW9uOjpub3RpZnkoUU9iamVjdCosIFFF dmVudCopICgpIGZyb20gL3Vzci9saWIvbGliUXRHdWkuc28uNAojMzMgMHgwMDAwN2ZmZmRmYmQy ZTljIGluIFFDb3JlQXBwbGljYXRpb246Om5vdGlmeUludGVybmFsKFFPYmplY3QqLCBRRXZlbnQq KSAoKSBmcm9tIC91c3IvbGliL2xpYlF0Q29yZS5zby40CiMzNCAweDAwMDA3ZmZmZTAwZWY4ZDAg aW4gPz8gKCkgZnJvbSAvdXNyL2xpYi9saWJRdEd1aS5zby40CiMzNSAweDAwMDA3ZmZmZTAwZjBk ZDggaW4gPz8gKCkgZnJvbSAvdXNyL2xpYi9saWJRdEd1aS5zby40CiMzNiAweDAwMDA3ZmZmZTAw YzM5N2MgaW4gUUFwcGxpY2F0aW9uOjpub3RpZnkoUU9iamVjdCosIFFFdmVudCopICgpIGZyb20g L3Vzci9saWIvbGliUXRHdWkuc28uNAojMzcgMHgwMDAwN2ZmZmRmYmQyZTljIGluIFFDb3JlQXBw bGljYXRpb246Om5vdGlmeUludGVybmFsKFFPYmplY3QqLCBRRXZlbnQqKSAoKSBmcm9tIC91c3Iv bGliL2xpYlF0Q29yZS5zby40CiMzOCAweDAwMDA3ZmZmZTAxNWUwNWEgaW4gPz8gKCkgZnJvbSAv dXNyL2xpYi9saWJRdEd1aS5zby40CiMzOSAweDAwMDA3ZmZmZTAxNWU0YWYgaW4gPz8gKCkgZnJv bSAvdXNyL2xpYi9saWJRdEd1aS5zby40CiM0MCAweDAwMDA3ZmZmZTAxM2FkODQgaW4gUUFwcGxp Y2F0aW9uOjp4MTFQcm9jZXNzRXZlbnQoX1hFdmVudCopICgpIGZyb20gL3Vzci9saWIvbGliUXRH dWkuc28uNAojNDEgMHgwMDAwN2ZmZmUwMTYyNTAyIGluID8/ICgpIGZyb20gL3Vzci9saWIvbGli UXRHdWkuc28uNAojNDIgMHgwMDAwN2ZmZmYwZTE4YmYzIGluIGdfbWFpbl9jb250ZXh0X2Rpc3Bh dGNoICgpIGZyb20gL3Vzci9saWIvbGliZ2xpYi0yLjAuc28uMAojNDMgMHgwMDAwN2ZmZmYwZTE5 M2QwIGluID8/ICgpIGZyb20gL3Vzci9saWIvbGliZ2xpYi0yLjAuc28uMAojNDQgMHgwMDAwN2Zm ZmYwZTE5NjZkIGluIGdfbWFpbl9jb250ZXh0X2l0ZXJhdGlvbiAoKSBmcm9tIC91c3IvbGliL2xp YmdsaWItMi4wLnNvLjAKIzQ1IDB4MDAwMDdmZmZkZmJmZGYwZiBpbiBRRXZlbnREaXNwYXRjaGVy R2xpYjo6cHJvY2Vzc0V2ZW50cyhRRmxhZ3M8UUV2ZW50TG9vcDo6UHJvY2Vzc0V2ZW50c0ZsYWc+ KSAoKSBmcm9tIC91c3IvbGliL2xpYlF0Q29yZS5zby40CiM0NiAweDAwMDA3ZmZmZTAxNjIxYWUg aW4gPz8gKCkgZnJvbSAvdXNyL2xpYi9saWJRdEd1aS5zby40CiM0NyAweDAwMDA3ZmZmZGZiZDIy MzIgaW4gUUV2ZW50TG9vcDo6cHJvY2Vzc0V2ZW50cyhRRmxhZ3M8UUV2ZW50TG9vcDo6UHJvY2Vz c0V2ZW50c0ZsYWc+KSAoKSBmcm9tIC91c3IvbGliL2xpYlF0Q29yZS5zby40CiM0OCAweDAwMDA3 ZmZmZGZiZDI0N2MgaW4gUUV2ZW50TG9vcDo6ZXhlYyhRRmxhZ3M8UUV2ZW50TG9vcDo6UHJvY2Vz c0V2ZW50c0ZsYWc+KSAoKSBmcm9tIC91c3IvbGliL2xpYlF0Q29yZS5zby40CiM0OSAweDAwMDA3 ZmZmZGZiZDY5N2IgaW4gUUNvcmVBcHBsaWNhdGlvbjo6ZXhlYygpICgpIGZyb20gL3Vzci9saWIv bGliUXRDb3JlLnNvLjQKIzUwIDB4MDAwMDdmZmZlMGMzNWE3MSBpbiA/PyAoKSBmcm9tIC91c3Iv bGliL3ZsYy9wbHVnaW5zL2d1aS9saWJxdDRfcGx1Z2luLnNvCiM1MSAweDAwMDA3ZmZmZjc2YzNj YjAgaW4gc3RhcnRfdGhyZWFkICgpIGZyb20gL2xpYi9saWJwdGhyZWFkLnNvLjAKIzUyIDB4MDAw MDdmZmZmNzIyYmFlZCBpbiBjbG9uZSAoKSBmcm9tIC9saWIvbGliYy5zby42CiM1MyAweDAwMDAw MDAwMDAwMDAwMDAgaW4gPz8gKCkK