Summary: | media-video/totem-2.22.2 - (totem:27645): GLib-GObject-CRITICAL **: g_signal_handler_disconnect: assertion `handler_id > 0' failed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED LATER | ||
Severity: | normal | CC: | gstreamer, hppa, media-video, x11 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | HPPA | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 218794, 268363, 269855 | ||
Attachments: | strace output from `strace -o totem.strace totem' [media-video/totem-2.22.2-r1] |
Description
Jeroen Roovers (RETIRED)
2008-09-08 03:26:08 UTC
I would have attached the file I created using `totem 2>&1 | tee totem.out', but then sort -u showed me it 4202 copies of the single message quoted in the Summary. could you provide a backtrace of running totem like this: $ G_DEBUG="fatal-criticals" gdb --args totem the execution should stop at first critical message. Created attachment 166181 [details]
strace output from `strace -o totem.strace totem' [media-video/totem-2.22.2-r1]
I tried the same in a debian sid chroot and there totem exhibits the exact same problem - it hangs and it keeps repeating the warning in the Summary. and what about the output of the command in comment #2 ? the strace doesn't look like it contains anything interesting. (In reply to comment #5) > and what about the output of the command in comment #2 ? the strace doesn't > look like it contains anything interesting. It hangs. gdb uses a fair chunk of CPU time but never displays any output. Or responds to commands, or a break, and can only be killed. I would have provided this information sooner if I had got anything useful. Maybe launching just gdb totem and then setting a breakpoint on g_log would work better. Use "thread apply all bt full" to get the backtrace if the break succeeds. Something like this (just an example of a different warning that is more innocent than the one you get): (gdb) break g_log Function "g_log" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (g_log) pending. (gdb) run Starting program: /usr/bin/totem [Thread debugging using libthread_db enabled] [New Thread 0x7f9dee1a8740 (LWP 9497)] [New Thread 0x40e75950 (LWP 9507)] [New Thread 0x4238a950 (LWP 9508)] [New Thread 0x42b8b950 (LWP 9509)] [New Thread 0x418eb950 (LWP 9510)] [Thread 0x4238a950 (LWP 9508) exited] [Thread 0x42b8b950 (LWP 9509) exited] [Switching to Thread 0x7f9dee1a8740 (LWP 9497)] Breakpoint 1, IA__g_log (log_domain=0x7f9dea725afc "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=0x7f9dea29eaa7 "%s: assertion `%s' failed") at gmessages.c:513 513 { (gdb) thread apply all bt full <extensive backtrace given splitdebug> could you try some 2.24 version ? I fear we can't help much without something tangible to debug with. Maybe taking this upstream would be simpler. @x11: Could you please tell which X11 library is responsible for passing window information to windowed applications? I am wondering if the problem lies there, as I am seeing other curious positioning problems as well. In both KDE and Xfce, buttons/panel applets move to the center of the panel instead of sticking to the right or to a custom defined position after a restart, as if the information is either passed on or remembered/written wrongly. (In reply to comment #9) > @x11: Could you please tell which X11 library is responsible for passing window > information to windowed applications? I am wondering if the problem lies there, > as I am seeing other curious positioning problems as well. In both KDE and > Xfce, buttons/panel applets move to the center of the panel instead of sticking > to the right or to a custom defined position after a restart, as if the > information is either passed on or remembered/written wrongly. Parsing the window hierarchy is part of the core protocol and is handled by libX11 directly. See XQueryTree(3). Don't really know what's going on there... Thanks You're kde/xfce problems are probably not related to X11 and more likely kde/xfce panels/etc bugs.. @jer: Is this problem still around with 2.24? What about 2.26? Why does it block bug 268363 since it's not a regression ? (In reply to comment #12) > @jer: Is this problem still around with 2.24? What about 2.26? Why does it > block bug 268363 since it's not a regression ? Yes, yes, it's a regression from -2.20. I've marked it stable for now. It doesn't appear that HPPA users or upstream are all that interested in this bug (which persists in 2.26.5, btw). The problem arises from totem trying to resize itself and failing to find or calculate the window dimensions and position properly, but where in the code it goes wrong is beyond me. To anyone who cares to investigate: Please reopen this bug report to let me know you do. |