GNOME Bugzilla – Bug 350569
eog won't quit
Last modified: 2006-09-04 18:07:41 UTC
Eog won't quit after I viewed an image with it. 1. Open eog by running "eog" from a terminal 2. Close eog Now all works fine. 1. Open eog by running "eog" from a terminal 2. Open an image/directory (eg. from recently opened files list) 3. Close eog Now eog starts eating 100% CPU and the window doesn't close. After a while, metacity asks me if it should kill the window because it is not responding. Note that there's no output on the terminal window.
Running gdb on eog and interrupting during the 100% CPU usage gives me this (not sure if it's useful all): elin:~ > gdb eog GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /opt/gnome-2-16/bin/eog [Thread debugging using libthread_db enabled] [New Thread -1227368768 (LWP 15334)] [New Thread -1234310224 (LWP 15337)] [New Thread -1244619856 (LWP 15338)] Program received signal SIGINT, Interrupt. [Switching to Thread -1227368768 (LWP 15334)] IA__g_type_check_instance_is_a (type_instance=0x82afa40, iface_type=20) at gtype.c:3113 3113 check = node && node->is_instantiatable && iface && type_node_conforms_to_U (node, iface, TRUE, FALSE); (gdb) thread apply all bt
+ Trace 70125
Thread 1 (Thread -1227368768 (LWP 15334))
strace -p $(pidof eog) while eog is eating 100% cpu gives no output, btw.
*** Bug 350115 has been marked as a duplicate of this bug. ***
From bug 350115: "Opened by Brent Smith (smitten) (reporter, developer, points: 18) 2006-08-06 04:08 UTC [reply] I haven't been able to pin down exactly when this happens, but with CVS HEAD, eog seems to occassionally hang when trying to close it from the X in the titlebar. I did an strace and managed to reproduce it: Here are the last lines from the strace output before it hangs: poll([{fd=6, events=POLLIN}, {fd=11, events=POLLIN|POLLPRI, revents=POLLIN}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}], 4, -1) = 1 read(11, "GIOP\1\2\1\1$\0\0\0", 12) = 12 read(11, "p]\322\277\0\0\0\0\1\0\0\0\1\0\0\0\f\0\0\0\1\1\1\1\1\0"..., 36) = 36 gettimeofday({1154837164, 998841}, NULL) = 0 gettimeofday({1154837165, 3500}, NULL) = 0 gettimeofday({1154837165, 18857}, NULL) = 0 gettimeofday({1154837165, 21849}, NULL) = 0 gettimeofday({1154837165, 24521}, NULL) = 0 munmap(0xb46dd000, 1376256) = 0 "
Increasing severity... eog is unusable
I can see this as well with cvs head (gdb) bt full
+ Trace 71514
Increasing severity
Is it possible that you have a modified libgnomecanvas? Because I can only produce it with a libgnomecanvas from CVS. The problem is the following commit (which I think produces an infinite loop): http://cvs.gnome.org/viewcvs/libgnomecanvas/libgnomecanvas/gnome-canvas.c?r1=1.176&r2=1.177 I cannot reproduce it using a stock libgnomecanvas-2.14.0.
what is the relevance of the last question? three people could reproduce with cvs head. and the reporter is using 2.15 as it seems. I can see ultimate CPU usage as well which definitely means we have some kind of infinite loop.
Reverting the commit cited on comment #8 fixes the problem. This is actually a libgnomecanvas bug. Adding Herzi to CC.
Yes, I run all my libraries from HEAD...
The commit listed in #8 is clean. If Gnome Canvas breaks there, it looks like a reference counting bug (some piece of code keeps a reference on a GnomeCanvas item so it doesn't get disposed). Hints: 1. reproduce this bug 2. attach with gdb 3. set a break point on gnome_canvas_group_destroy() 4. enter "continue" (return) to resume eog 5. wait for the break point 6. check for the class that this item belongs to 7. kill eog And then there's 2 ways to go: -- THE UGLY -- 8. start eog from a gdb instance 9. add a conditional breakpoint on g_object_ref() and g_object_unref() with a condition on the parameter (so you get any reference change reported on objects of that class). 10. check which reference is leaked by stepping through the app -- THE GOOD -- 8. check manually for each reference on the class AND 9. make sure you also g_signal_connect(item, "destroy", g_object_unref, NULL); (replace unref by your custom cleanup function if necessary)
Created attachment 72208 [details] [review] Proposed Patch Found I think that's the reason. May I commit?
That fix is quite obvious. You should ask the release team for approval to get this patch into eog 2.16.0.1 and release 2.16.0.1 with GNOME 2.16.
the suggested fix works well for me, I haven't seen a regression so far.
(In reply to comment #10) > Reverting the commit cited on comment #8 fixes the problem. This is actually a > libgnomecanvas bug. Adding Herzi to CC. this is not a libgnomecanvas bug, the correct libgnomecanvas fix just exposes a sever bug in the eog canvas item implementations (which could have bee ntriggered under other scenarios as well). (In reply to comment #12) > The commit listed in #8 is clean. If Gnome Canvas breaks there, it looks like > a reference counting bug (some piece of code keeps a reference on a > GnomeCanvas item so it doesn't get disposed). this is not the case. but note that even if there was a dangling ref count on a canvas item, the item would just be leaked. item->::dispose is run regardless, this is ensured by the call to gtk_object_destroy() in: http://cvs.gnome.org/viewcvs/libgnomecanvas/libgnomecanvas/gnome-canvas.c?r1=1.176&r2=1.177 (In reply to comment #13) > Created an attachment (id=72208) [edit] > Proposed Patch > Found I think that's the reason. May I commit? this is definitely the right fix, failing to chain up from dispose or finalize is a severe bug in any GObject implementation. and as far as the canvas is concerned, an endless loop in gnome_canvas_group_destroy() is one of the logical outcomes of such an implementation bug (well spotted sven).
Applied! Thanks for the patch, Sven! Tim, this (oooold) gnome-canvas-based code can be considered obsolete as we already re-implemented the thumbnail pane based on GtkIconView in eog-ng branch. Thanks for your comments anyway. :-) 2006-09-04 Lucas Rocha <lucasr@gnome.org> * libeog/eog-canvas-pixbuf.c: fix infinite loop on canvas destruction (Fixes bug #350569). Patch from Sven Herzberg <herzi@gnome-de.org>.