From: Wolfgang S. <wol...@gm...> - 2013-08-19 17:17:42
|
Trying to provide additional and useful info to the problem, which is probably the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720109 i created ( with help of LStranger on irc ) this: % gdb lxpanel GNU gdb (GDB) 7.6 (Debian 7.6-5) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/lxpanel...Reading symbols from /usr/lib/debug/.build- id/56/4e2628c42d2c7d5efb72d376f0d7b9b21e3d4c.debug...done. done. (gdb) run Starting program: /usr/bin/lxpanel warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffed950700 (LWP 6900)] [New Thread 0x7fffec917700 (LWP 6901)] [Thread 0x7fffed950700 (LWP 6900) exited] ^C Program received signal SIGINT, Interrupt. __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 135 ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory. (gdb) bt full #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 No locals. #1 0x00007ffff5f0ef72 in _L_lock_1134 () from /lib/x86_64-linux- gnu/libpthread.so.0 No symbol table info available. #2 0x00007ffff5f0eef0 in __GI___pthread_mutex_lock (mutex=0x63f660) at pthread_mutex_lock.c:104 max_cnt = -1 __PRETTY_FUNCTION__ = "__pthread_mutex_lock" type = 4294966784 #3 0x00007ffff64e3291 in g_mutex_lock () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 No symbol table info available. #4 0x000000000040f618 in main (argc=1, argv=0x7fffffffe498, env=<optimized out>) at panel.c:1722 i = <optimized out> desktop_name = <optimized out> i hope this helps debugging. Additional info: fresh debian Sid (amd64), as of 2013-08-19, lxpanel started from minimal openbox session, also tried purging other lxde packages, especially lxde core and session stuff, clean $HOME, etc ... didn't change a thing. Wolfgang |
From: Andrej N. G. <an...@re...> - 2013-08-19 18:39:52
|
Hello! Wolfgang Scheicher has written on Monday, 19 August, at 19:17: >Trying to provide additional and useful info to the problem, >which is probably the same as >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720109 >i created ( with help of LStranger on irc ) this: >% gdb lxpanel >GNU gdb (GDB) 7.6 (Debian 7.6-5) >Copyright (C) 2013 Free Software Foundation, Inc. >License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> >This is free software: you are free to change and redistribute it. >There is NO WARRANTY, to the extent permitted by law. Type "show copying" >and "show warranty" for details. >This GDB was configured as "x86_64-linux-gnu". >For bug reporting instructions, please see: ><http://www.gnu.org/software/gdb/bugs/>... >Reading symbols from /usr/bin/lxpanel...Reading symbols from >/usr/lib/debug/.build- >id/56/4e2628c42d2c7d5efb72d376f0d7b9b21e3d4c.debug...done. >done. >(gdb) run >Starting program: /usr/bin/lxpanel >warning: Could not load shared library symbols for linux-vdso.so.1. >Do you need "set solib-search-path" or "set sysroot"? >[Thread debugging using libthread_db enabled] >Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >[New Thread 0x7fffed950700 (LWP 6900)] >[New Thread 0x7fffec917700 (LWP 6901)] >[Thread 0x7fffed950700 (LWP 6900) exited] >^C >Program received signal SIGINT, Interrupt. >__lll_lock_wait () at >../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 >135 ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or >directory. >(gdb) bt full >#0 __lll_lock_wait () at >../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 >No locals. >#1 0x00007ffff5f0ef72 in _L_lock_1134 () from /lib/x86_64-linux- >gnu/libpthread.so.0 >No symbol table info available. >#2 0x00007ffff5f0eef0 in __GI___pthread_mutex_lock (mutex=0x63f660) at >pthread_mutex_lock.c:104 > max_cnt = -1 > __PRETTY_FUNCTION__ = "__pthread_mutex_lock" > type = 4294966784 >#3 0x00007ffff64e3291 in g_mutex_lock () from /lib/x86_64-linux- >gnu/libglib-2.0.so.0 >No symbol table info available. >#4 0x000000000040f618 in main (argc=1, argv=0x7fffffffe498, env=<optimized out>) >at panel.c:1722 > i = <optimized out> > desktop_name = <optimized out> This is very strange. The corresponding line in 0.5.12 is gtk_main(); not g_mutex_lock(). It seems for me as if the packages are severely corrupted or stack is. :( >i hope this helps debugging. >Additional info: >fresh debian Sid (amd64), as of 2013-08-19, lxpanel started from minimal >openbox session, also tried purging other lxde packages, especially lxde core >and session stuff, clean $HOME, etc ... didn't change a thing. >Wolfgang Andriy. |
From: Jörg-Volker P. <jv...@we...> - 2013-08-21 10:07:50
|
Hello, Andrej N. Gritsenko wrote, on 08/19/2013 20:39: > Hello! > > Wolfgang Scheicher has written on Monday, 19 August, at 19:17: > >> Trying to provide additional and useful info to the problem, >> which is probably the same as >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720109 I submitted this report. I'm using lxpanel together with openbox (without lxsession). Meanwhile I tried also to deliver some additional information by starting lxpanel with ltrace. The last few lines before terminating the frozen panel with Ctrl-C are: XGetWindowProperty(0x1e01630, 333, 401, 0, 1) = 0 XFree(0x1f93690, 0x1f93698, -1, 1, 0x2001ac0) = 1 XChangeGC(0x1e01630, 0x20017d0, 1024, 0x7fff84eed830, 0x2001ac0) = 1 gtk_widget_set_app_paintable(0x1eca2d0, 1, 4, 0xe00001, 0x1e0847c) = 2 gdk_window_set_back_pixmap(0x1f28000, 0x1fc48d0, 0, 0, 0x1dfde80) = 1 g_object_unref(0x1fc48d0, 2, 4, 0x1de45a8, 0) = 2 gdk_window_invalidate_rect(0x1f28000, 0, 1, 0, 0x1e3ad20) = 0x1e16c60 gtk_socket_get_type(0x1f28000, 0, 1, 0, 0x1e12460) = 0x1ec39a0 g_type_check_instance_is_a(0x1eca2d0, 0x1ec39a0, 1, 0, 0x1e12460) = 0 gtk_container_get_type(0x1ec39a0, 0x1ec39a0, 1, 0, 0x1dfde80) = 0x1e00dd0 g_type_check_instance_is_a(0x1eca2d0, 0x1e00dd0, 1, 0, 0x1dfde80) = 1 gtk_container_foreach(0x1eca2d0, 0x41a120, 0x1e4f7a0, 0, 0x1dfde80 <unfinished ...> gtk_socket_get_type(0x1edfcf0, 0x1e4f7a0, 0x41a120, 0x1e4f7a0, 0x1dfde80) = 0x1ec39a0 g_type_check_instance_is_a(0x1edfcf0, 0x1ec39a0, 0x41a120, 0x1e4f7a0, 0x1dfde80) = 0 gtk_container_get_type(0x1ec39a0, 0x1ec39a0, 0, 0x1e4f7a0, 0x1e7b030) = 0x1e00dd0 g_type_check_instance_is_a(0x1edfcf0, 0x1e00dd0, 0, 0x1e4f7a0, 0x1e7b030) = 0 <... gtk_container_foreach resumed> ) = 0 g_free(0x1e4f050, 0x1e00dd0, 1, 0x1e4f7a0, 0x1e7b030) = 1873 g_slist_prepend(0, 0x1e4f7a0, 0x7fde6c195698, 0x1e4f7a0, 0) = 0x1ec0ea0 g_free(0x1e457b0, 1, 0x1ec0ea0, 0, 0) = 0 g_dir_read_name(0x1e46a50, 0xffffffff, 0x7fde6c195660, 0, 0) = 0 g_dir_close(0x1e46a50, 0x1e47048, 32768, -1, 0) = 0x1f93680 g_free(0x1e45600, 0, 0x7fde6c195648, 0x1f93680, 0) = 0x1e457a0 gdk_threads_enter(0x7fde6c195640, 3, 0x7fde6c195660, 0x1e457a0, 0 <unfinished ...> --- SIGINT (Interrupt) --- +++ killed by SIGINT +++ Before terminating lxpanel it won't react to any of the lxpanelctl commands. This was with package libglib2.0-0 version 2.36.3-3. Any idea? <snip> |
From: Henry G. <hsg...@gm...> - 2013-08-25 23:51:49
|
On Wed, Aug 21, 2013 at 12:07:30PM +0200, Jörg-Volker Peetz wrote: > Andrej N. Gritsenko wrote, on 08/19/2013 20:39: > > Wolfgang Scheicher has written on Monday, 19 August, at 19:17: > > > >> Trying to provide additional and useful info to the problem, > >> which is probably the same as > >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720109 > > I submitted this report. > I'm using lxpanel together with openbox (without lxsession). > > Meanwhile I tried also to deliver some additional information by starting > lxpanel with ltrace. The last few lines before terminating the frozen panel with > Ctrl-C are: > > ... > gdk_threads_enter(0x7fde6c195640, 3, 0x7fde6c195660, 0x1e457a0, 0 <unfinished ...> Seems like gdk_threads_enter() is called twice. Does Debian patch gtk_main() to call gdk_threads_enter()? Also, on the bug you say: > This was on another system with a single CPU. My main system has two cores. Does this mean it occurs on single-core machines only? Thanks, Henry |
From: Andrej N. G. <an...@re...> - 2013-08-26 01:30:16
|
Hello! Henry Gebhardt has written on Sunday, 25 August, at 19:51: >On Wed, Aug 21, 2013 at 12:07:30PM +0200, Jörg-Volker Peetz wrote: >> Andrej N. Gritsenko wrote, on 08/19/2013 20:39: >> > Wolfgang Scheicher has written on Monday, 19 August, at 19:17: >> >> Trying to provide additional and useful info to the problem, >> >> which is probably the same as >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720109 >> I submitted this report. >> I'm using lxpanel together with openbox (without lxsession). >> Meanwhile I tried also to deliver some additional information by starting >> lxpanel with ltrace. The last few lines before terminating the frozen panel with >> Ctrl-C are: >> ... >> gdk_threads_enter(0x7fde6c195640, 3, 0x7fde6c195660, 0x1e457a0, 0 <unfinished ...> >Seems like gdk_threads_enter() is called twice. Does Debian patch >gtk_main() to call gdk_threads_enter()? No, it doesn't. I'm afraid it may be something else, I've stepped into something similar when I wrote new lxshortcut. You might have some init callback which does gdk_threads_enter() and that callback blocks gtk_main from entering main loop because it never returns. I don't know how it is done in lxpanel but may be gdk_threads_enter() was missed in lxpanel's main() on purpose? I have left lxshortcut without that call on purpose. And I don't think lxpanel ever would need GDK threading support, I don't see many windows updated simultaneously in lxpanel so I would suggest to remove gdk_threads_init() and all that jazz. :) I think that would make it even faster because no locking and context switching will be involved. But as you wish, of course. (I mean only gdk_threads_init() removal, any gdk_threads_enter/gdk_threads_leave will just do nothing then) >Also, on the bug you say: >> This was on another system with a single CPU. My main system has two cores. >Does this mean it occurs on single-core machines only? I think on multi-core CPU some init function may be fast enough to slip critical section already. What again confirms the theory above may be right. >Thanks, >Henry Cheers! Andriy. |
From: Jörg-Volker P. <jv...@we...> - 2013-08-26 08:15:38
|
Henry Gebhardt wrote, on 08/26/2013 01:51: > On Wed, Aug 21, 2013 at 12:07:30PM +0200, Jörg-Volker Peetz wrote: >> Andrej N. Gritsenko wrote, on 08/19/2013 20:39: >>> Wolfgang Scheicher has written on Monday, 19 August, at 19:17: >>> >>>> Trying to provide additional and useful info to the problem, >>>> which is probably the same as >>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720109 >> >> I submitted this report. >> I'm using lxpanel together with openbox (without lxsession). >> >> Meanwhile I tried also to deliver some additional information by starting >> lxpanel with ltrace. The last few lines before terminating the frozen panel with >> Ctrl-C are: >> >> ... >> gdk_threads_enter(0x7fde6c195640, 3, 0x7fde6c195660, 0x1e457a0, 0 <unfinished ...> > > Seems like gdk_threads_enter() is called twice. Does Debian patch > gtk_main() to call gdk_threads_enter()? Yes, you're right. There is a patch called "fix_gtk_main.diff" without description which adds a "gdk_threads_enter();" before the line "gtk_main();" and a "gdk_threads_leave();" behind it in panel.c around line 1686. > Also, on the bug you say: >> This was on another system with a single CPU. My main system has two cores. > > Does this mean it occurs on single-core machines only? No, the problem occurs both on single and two core system. > Thanks, > Henry -- jvp |
From: Andrej N. G. <an...@re...> - 2013-08-26 10:45:38
|
Hello! Jörg-Volker Peetz has written on Monday, 26 August, at 10:15: >Henry Gebhardt wrote, on 08/26/2013 01:51: >> On Wed, Aug 21, 2013 at 12:07:30PM +0200, Jörg-Volker Peetz wrote: >>> Andrej N. Gritsenko wrote, on 08/19/2013 20:39: >>>> Wolfgang Scheicher has written on Monday, 19 August, at 19:17: >>>>> Trying to provide additional and useful info to the problem, >>>>> which is probably the same as >>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720109 >>> I submitted this report. >>> I'm using lxpanel together with openbox (without lxsession). >>> Meanwhile I tried also to deliver some additional information by starting >>> lxpanel with ltrace. The last few lines before terminating the frozen panel with >>> Ctrl-C are: >>> ... >>> gdk_threads_enter(0x7fde6c195640, 3, 0x7fde6c195660, 0x1e457a0, 0 <unfinished ...> >> Seems like gdk_threads_enter() is called twice. Does Debian patch >> gtk_main() to call gdk_threads_enter()? >Yes, you're right. There is a patch called "fix_gtk_main.diff" without >description which adds a "gdk_threads_enter();" before the line "gtk_main();" >and a "gdk_threads_leave();" behind it in panel.c around line 1686. Oh, yes, I was so naive and thought lxpanel 0.5.12 came into the sid without any external patches. And that patch is definitely the cause. It _is_ included into sid package. I hope Andrew Lee will fix it ASAP. With best regards. Andriy. |
From: Jörg-Volker P. <jv...@we...> - 2013-08-26 08:24:06
|
Jörg-Volker Peetz wrote, on 08/26/2013 10:15: > Henry Gebhardt wrote, on 08/26/2013 01:51: >> On Wed, Aug 21, 2013 at 12:07:30PM +0200, Jörg-Volker Peetz wrote: <snip> >>> gdk_threads_enter(0x7fde6c195640, 3, 0x7fde6c195660, 0x1e457a0, 0 <unfinished ...> >> >> Seems like gdk_threads_enter() is called twice. Does Debian patch >> gtk_main() to call gdk_threads_enter()? > > Yes, you're right. There is a patch called "fix_gtk_main.diff" without > description which adds a "gdk_threads_enter();" before the line "gtk_main();" > and a "gdk_threads_leave();" behind it in panel.c around line 1686. No, gtk_main() is not patched. I misread the patches. I referred to an older patch which is not applied in the current version of the debian package. Sorry for the confusion. <snip> -- jvp |
From: Jörg-Volker P. <jv...@we...> - 2013-08-27 14:47:38
|
Hello, Jörg-Volker Peetz wrote, on 08/26/2013 10:23: > Jörg-Volker Peetz wrote, on 08/26/2013 10:15: >> Henry Gebhardt wrote, on 08/26/2013 01:51: >>> On Wed, Aug 21, 2013 at 12:07:30PM +0200, Jörg-Volker Peetz wrote: > > <snip> > >>>> gdk_threads_enter(0x7fde6c195640, 3, 0x7fde6c195660, 0x1e457a0, 0 <unfinished ...> >>> >>> Seems like gdk_threads_enter() is called twice. Does Debian patch >>> gtk_main() to call gdk_threads_enter()? >> >> Yes, you're right. There is a patch called "fix_gtk_main.diff" without >> description which adds a "gdk_threads_enter();" before the line "gtk_main();" >> and a "gdk_threads_leave();" behind it in panel.c around line 1686. > > No, gtk_main() is not patched. I misread the patches. I referred to an older > patch which is not applied in the current version of the debian package. > Sorry for the confusion. > > <snip> However, it was patched. And I was very befuddled. Meanwhile, Andrew Lee has released a fixed the debian package with version 0.5.12-3 and lxpanel is working fine on my systems. Thanks to all and best regards, jvp |