[gutsy] image viewer slow to start

Thanks for your comments. This does not appear to be a bug report as such. We appreciate the difficulties you are facing, but it would make more sense to raise your question in the support tracker. http://launchpad.net/support. dbus should be running, if it's not you have a local configuration issue

dbus *is* running so this IS a bug either with dbus (the way dpkg set it up) or
with eog

This problem is happening intermittently on closer investigation

to reproduce the bug stop dbus altogether, even without dbus something
like an image viewer should be immediately accessible regardless of
the status of another sub system, otherwise you are trying to make
a stack of cards that bug #1 is trying to avoid

an another way is to say that dbus should always be running since it's a basic component in the system nowadays

look I'm not being funny, but you really are missing the point!

eog should NOT be blocking while it waits for dbus, are you saying if dbus fails they
whole system should fail?

and by what reckoning do you make dbus a *vital* component
Ubuntu will run quite happily without it (except for very slow
starting of eog)

Watching dbus via qdbusviewer dbus is not used very much, yes useful to have
but applications should not grid to a halt without it

I can replicate this bug EVERY TIME by trying to open an SVG image
eog cannot access dbus until after a reboot and even restarting the
dbus deamon doesnt help

this BUG is a problem with eog and SVG images

this is problem with dbus has been confirmed on another machine
it involves SVG images

how does it involve svg images? I don't say that applications should block when dbus is not available (which should not happen though), the bug is likely a libdbus one though, do you similar issues with other softwares?

the svg issue you speak about is likely bug #119603 and has nothing to do with dbus

the svg issue is very possibly bug #119603 however it is the only way I can
reproduce the dbus bug

this bug effects all applications relying on dbus. dbus cease to respond properly
even after restart

EOG is the ONLY program that causes dbus to behave in this way
It could well be a dbus problem, however it is only shown up
by EOG

Have you tried to replicate this problem yourself?

i have same problem with *jpg images, so i dont think there is a problem with so tipe eog can't handel. It can't be missconfiguration ether, there is no self made configurations on my test machine and account.

ltrace eog image.jpg:
........
dbus_g_bus_get(2, 0xbfe5e828, 0xbfe5e828, 0xbfe5e944, 0xbfe5e838) = 0x8103b54
dbus_g_proxy_new_for_name(0x8103b54, 0x80a551c, 0x80a5531, 0x80a551c, 0xbfe5e838) = 0x8101990
dbus_g_proxy_call(0x8101990, 0x80a5547, 0xbfe5e828, 64, 0x80a5404) = 1
g_object_unref(0x8101990, 0x80a5547, 0xbfe5e828, 64, 0x80a5404) = 0
gdk_display_get_default(0x80b5698, 0x80a531f, 0xb7e22540, 2, 0xbfe5e944) = 0x80d6010
gdk_x11_display_get_user_time(0x80d6010, 0x80a531f, 0xb7e22540, 2, 0xbfe5e944) = 0
dbus_g_bus_get(2, 0xbfe5e894, 0xb7e22540, 2, 0xbfe5e944) = 0x8103b54
g_strv_length(0x80c7328, 0x80d3a51, 0, 0x80a643c, 0x8103b54) = 1
g_malloc0(4, 0x80d3a51, 0, 0x80a643c, 0x8103b54) = 0x810f4c0
gnome_vfs_make_uri_from_input_with_dirs(0x80c7318, 2, 0x810f4c0, 0x80a643c, 0x8103b54) = 0x810f3e8
dbus_g_proxy_new_for_name(0x8103b54, 0x80a5404, 0x80a5340, 0x80a5326, 0xbfe5e944) = 0x8101a48
g_strv_get_type(0x80a5326, 0x80a5404, 0x80a5340, 0x80a5326, 0xbfe5e944) = 0x81042f8
dbus_g_proxy_call(0x8101a48, 0x80a535e, 0xbfe5e894, 0x81042f8, 0x810f4c0
<-------------- at this place we will wait about 30 seconds !!!
) = 0
g_log(0, 16, 0x810ee60, 0x81042f8, 0x810f4c0
** (eog:19263): WARNING **: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
) = 0

Does anybody still get the issue and could describe easy steps to trigger it?

happens *every* and *any* attempt to open an svg here

1 right click an svg image in nautilus
2 select open with "image viewer"
3 open a console and issue
         eog

after a wait of approx 20-30 seconds you should see

** (eog:5965): WARNING **: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Segmentation fault (core dumped)

eog will now no longer work untill after a reboot, even if you restart dbus etc

interestingly I can open jpg's just fine here...

Does anybody has the issue without trying to open svg files? It's hanging with this format due to a bug which is fixed upstream and try to use the existing instance, that will be fixed with the next upload. If opening svg is the only buggy case the bug can probably be closed as duplicate

https://bugs.launchpad.net/ubuntu/+source/eog/+bug/134616/comments/11 ?

that comment has no steps to trigger the bug and no indication that there is no hanging eog already running due to a previous svg opening or something similar

I have a problem with jpgs, but only from a specific volume. It seems only ext3 is affected but not xfs, if that makes any sense. Or maybe that's not the problem at all, I don't know to be honest.

My delay is only about 3 seconds but I don't think it ever used to happen. Clearly something odd is at work.

Is this still an issue?

Yes, it is for me. My other file system/drive's images still take longer to come up.

thanks, xtknight may you forward this upstream since you're getting the bug? thanks you.

Was there a recent update to eog?

Just recently, I have trouble reproducing it. I don't think I should report it if I can never reproduce it again, but if I do figure out a way I will send the bug to GNOME BugZilla and link it to this report.

closing the bug for now then, feel free to reopen if you get the issue again