eog crashed with SIGSEGV in gdk_x11_window_get_xid()

StacktraceTop:
 gdk_window_has_impl (window=0x0) at /build/buildd/gtk+3.0-3.1.12/./gdk/gdkwindow.c:650
 _gdk_window_has_impl (window=0x0) at /build/buildd/gtk+3.0-3.1.12/./gdk/gdkwindow.c:651
 gdk_x11_window_get_xid (window=0x0) at /build/buildd/gtk+3.0-3.1.12/./gdk/x11/gdkwindow-x11.c:4753
 ?? () from /tmp/tmpLVgucY/usr/lib/libgrip.so.0
 ?? () from /tmp/tmpLVgucY/usr/lib/libgrip.so.0

Status changed to 'Confirmed' because the bug affects multiple users.

I was not loading an animated gif; just a normal png, when this crash occurred

I was not loading an animated gif; just a normal png, when this crash occurred

Can someone attach an image file that causes the crash? Or does this crash intermittently?

In my computer This crash occurr intermittenly

2011/9/28, Hans gogia <email address hidden>:
> I was not loading an animated gif; just a normal png, when this crash
> occurred
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (854359).
> https://bugs.launchpad.net/bugs/827958
>
> Title:
> eog crashed with SIGSEGV in gdk_x11_window_get_xid()
>
> Status in “libgrip” package in Ubuntu:
> Confirmed
> Status in “libgrip” source package in Oneiric:
> Confirmed
>
> Bug description:
> 1) Description: Ubuntu oneiric (development branch)
> Release: 11.10
>
> 2) eog:
> Instalados: 3.1.5-0ubuntu1
> Candidato: 3.1.5-0ubuntu1
> Tabla de versión:
> *** 3.1.5-0ubuntu1 0
> 500 http://mx.archive.ubuntu.com/ubuntu/ oneiric/main amd64
> Packages
> 100 /var/lib/dpkg/status
>
> 3) See an animated gif
> 4) Crash
>
> ProblemType: Crash
> DistroRelease: Ubuntu 11.10
> Package: eog 3.1.5-0ubuntu1
> ProcVersionSignature: Ubuntu 3.0.0-7.9-usernameeric 3.0.0
> Uname: Linux 3.0.0-7-generic x86_64
> NonfreeKernelModules: nvidia
> Architecture: amd64
> Date: Wed Aug 17 04:16:12 2011
> ExecutablePath: /usr/bin/eog
> InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64
> (20110803.1)
> ProcCmdline: eog
> /home/username/Diseno/Blender/Proyectos-Personales/2011/Nyan-Cat-2011ao16/Referencias/Cat-03.gif
> ProcEnviron:
> LANGUAGE=es_MX:es
> PATH=(custom, no user)
> LANG=es_MX.UTF-8
> SHELL=/bin/bash
> SegvAnalysis:
> Segfault happened at: 0x7fa71692c5d2: cmp 0x80(%rdi),%rdi
> PC (0x7fa71692c5d2) ok
> source "0x80(%rdi)" (0x00000080) not located in a known VMA region
> (needed readable region)!
> destination "%rdi" ok
> SegvReason: reading NULL VMA
> Signal: 11
> SourcePackage: eog
> StacktraceTop:
> ?? () from /usr/lib/libgdk-3.so.0
> gdk_x11_window_get_xid () from /usr/lib/libgdk-3.so.0
> ?? () from /usr/lib/libgrip.so.0
> ?? () from /usr/lib/libgrip.so.0
> ?? () from /usr/lib/libgrip.so.0
> Title: eog crashed with SIGSEGV in gdk_x11_window_get_xid()
> UpgradeStatus: No upgrade log present (probably fresh install)
> UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libgrip/+bug/827958/+subscriptions
>

--
Solidaridad es hacernos responsables unos de otros

Intermittent for me. There are some EOG-CRITICAL errors also. Relevant section of valgrind log attached.

Looks like it is triggered by some race condition when scanning a directory. I can reproduce by:

run gdb eog in a window
in another window cd to a directory with images in subdirectories and run the following command:

while true; do eog "$(find . -type d|sort -R |head -1|cut -f 1)"; done

It opens a random subdir every iteration but crashes quite quickly. You can try adding a little sleep:

while true; do eog "$(find . -type d|sort -R |head -1|cut -f 1)"; sleep 1; done

At a guess, could it be that eog is scanning the subdir (building thumbnails or something) and has not yet opened the gdk window. Another eog instance then gets launched, and there is now an invalid window pointer?

Chase, we keep getting eog segfaults about this and Oneiric is in hard freeze, is there any news on that?

This looks like the couple uses of GDK_WINDOW_XID in src/gripgesturemanager.c need to be guarded to protect against NULL.

Seb,

My impression, based on the reproduction scenario above, was that this was not hitting a lot of people. Now that I realize we are getting many crash reports, I am focusing our team's resources on it. Jussi and Stephen are working on it now, though I'll be on planes tomorrow and won't be back until Tuesday. Stephen has been able to reproduce it, so I'm hoping we may have a fix early next week.

Just to clarify: I have seen this crash several times in usual usage. The reproducible scenario that I posted above was obviously somewhat artificial, but since the backtrace appears to be the same as the "usual" crash it seemed likely that they may be caused by the same issue, and so it would be useful to post the details. However, it is possible that the "usual" crash is not exactly the same as the easily reproducible crash.

The proposed patch fixes a problem that could definitely (and only) occur any time two or more windows are opened in eog in fairly quick succession. If this is your usual usage, then it should fix the problem. If your regular usage is to just view a single picture at a time, there may still be an additional problem that requires further investigation.

> The reproducible scenario that I posted above was obviously somewhat artificial, but since the backtrace appears to be the same as the "usual" crash it seemed likely that they may be caused by the same issue

Well, one possible scenario is that the user use single click to open in nautilus and double click on an image

Thanks for working on this, we will review the patch soon!

Hello Gen, or anyone else affected,

Accepted libgrip into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I updated to -proposed, ran the looping eog test case and saw the following two crashes but did not see the gdk_x11_window_get_xid() crash. So these crashes may or may not be related to this particular bug.

The first crash happens if you have an empty sub directory, eg:

$ ls -R
.:
a/ b/

./a:
test.jpg

./b:

$ while true; do eog "$(find . -type d|sort -R |head -1|cut -f 1)"; done

(gdb) bt
#0 0x00007ffff6592f98 in gtk_tree_model_get_valist (tree_model=0x45da810, iter=0x7fffffffdd40,
    var_args=0x7fffffffdc28) at /build/buildd/gtk+3.0-3.2.0/./gtk/gtktreemodel.c:1768
#1 0x00007ffff659327c in gtk_tree_model_get (tree_model=0x45da810, iter=0x7fffffffdd40)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtktreemodel.c:1730
#2 0x0000000000427111 in eog_list_store_thumbnail_set (store=0x45da810, iter=0x7fffffffdd40) at eog-list-store.c:863
#3 0x00000000004335a9 in image_thumb_changed_cb (image=0x7fffe5403330, data=<optimized out>) at eog-window.c:802
#4 0x0000000000433748 in eog_window_display_image (window=0x7c1640, image=0x7fffe5403330) at eog-window.c:891
#5 0x00000000004342f5 in eog_job_load_cb (job=0x7fffe5303500, data=<optimized out>) at eog-window.c:1334
#6 0x00007ffff49670a4 in g_closure_invoke (closure=0x45cefe0, return_value=0x0, n_param_values=1,
    param_values=0x7fffe54220a0, invocation_hint=<optimized out>)
    at /build/buildd/glib2.0-2.30.0/./gobject/gclosure.c:774
#7 0x00007ffff497902a in signal_emit_unlocked_R (node=<optimized out>, detail=0, instance=0x7fffe5303500,
    emission_return=0x0, instance_and_params=0x7fffe54220a0) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3272
#8 0x00007ffff49826b1 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>,
    detail=<optimized out>, var_args=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3003
#9 0x00007ffff4982852 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
    at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3060
#10 0x00000000004238ac in notify_finished (job=0x7fffe5303500) at eog-job-queue.c:66
#11 0x00007ffff44a1a5d in g_main_dispatch (context=0x6ca3a0) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:2441
#12 g_main_context_dispatch (context=0x6ca3a0) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3011
#13 0x00007ffff44a2258 in g_main_context_iterate (context=0x6ca3a0, block=<optimized out>, dispatch=1,
    self=<optimized out>) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3089
#14 0x00007ffff44a2792 in g_main_loop_run (loop=0x7a8170) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3297
#15 0x00007ffff64a0e1d in gtk_main () at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkmain.c:1367
#16 0x00007ffff5c04a4e in g_application_run (application=0x7a3e60, argc=<optimized out>, argv=0x7fffffffe588)
    at /build/buildd/glib2.0-2.30.0/./gio/gapplication.c:1323
#17 0x000000000041ce8f in main (argc=1, argv=0x7fffffffe588) at main.c:168

The second crash happened when a lot of windows were opened by the test case, and I tried to close some of them.

(gdb) bt
#0 gdk_screen_get_monitor_geometry (screen=0x0, monitor_num=-1, dest=0x7fffffffde40)
    at /build/buildd/gtk+3.0-3.2.0/./gdk/...

I'm not sure how best to handle this. Neither crashes appear to be caused by libgrip based on the backtrace alone, but that's not really sufficient to be sure.

Chris, can you determine if you see these same crashes with the utouch patch commented out?

I think that the test case is just particularly harsh in showing up race conditions in window startup. I ran the test case with "sleep 1" added between the calls to eog, and did not see a single instance of this gdk_x11_window_get_xid() crash. Previously that would have been enough to trigger it. So, I would suggest that this particular bug has probably been fixed and the others are independent bugs in eog - it's possible that the test case is particularly aggressive and a normal user would never see them.

This looks like the -proposed package fixes the bug that it intended to fix; marking as verification-done.

This bug was fixed in the package libgrip - 0.3.2-0ubuntu3.1

---------------
libgrip (0.3.2-0ubuntu3.1) oneiric-proposed; urgency=low

  * Fix crash (detected in eog) due to incorrect widget registrations
    when a window is mapped (LP: #827958).
 -- Chase Douglas <email address hidden> Tue, 11 Oct 2011 16:37:09 +0100

I am still getting this bug:

(eog:23040): GRIP-CRITICAL **: register_internal: assertion `GRIP_IS_GESTURE_MANAGER (manager)' failed

Interestingly its only when I am logged in. Other users do not get it. I have tried deleting the eog config files in my account but this did not help. I have the latest up dates

Seems that the fix didnt quite catch all cases.

Right now, starting eog when logged in with user A works, but with user B eog explodes with a segmentation fault.

Running eog under strace gives the following output:

...
fstat(20, {st_mode=0600, st_size=0, ...}) = 0
fcntl(20, F_GETFL) = 0x2 (flags O_RDWR)
write(2, "\n(eog:11840): GRIP-CRITICAL **: "..., 104
(eog:11840): GRIP-CRITICAL **: register_internal: assertion `GRIP_IS_GESTURE_MANAGER (manager)' failed
) = 104
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

No idea why one user would have problems, when the other user doesnt.

Also see: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/872022, as that one looks a bit more appropriate.

Hi Jan,

Since you're seeing a slightly different issue, please open a new bug for it.

Thanks!