Bug 1564794 - some picture viewer apps (gthumb, cheese) fail
Summary: some picture viewer apps (gthumb, cheese) fail
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gthumb
Version: 26
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Christian Krause
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-07 23:02 UTC by Eyal Lebedinsky
Modified: 2018-04-30 02:47 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-30 02:47:37 UTC
Type: Bug


Attachments (Terms of Use)
extract from /var/log/messages (7.92 KB, text/plain)
2018-04-07 23:02 UTC, Eyal Lebedinsky
no flags Details
a crash trace without nvidia (4.04 KB, text/plain)
2018-04-11 05:06 UTC, Eyal Lebedinsky
no flags Details

Description Eyal Lebedinsky 2018-04-07 23:02:12 UTC
Created attachment 1418708 [details]
extract from /var/log/messages

Description of problem:

When using some picture apps (gthumb, cheese) it aborts with an error.

Version-Release number of selected component (if applicable):

gthumb.i686   1:3.4.5-1.fc26
cheese.x86_64 2:3.24.0-1.fc26

How reproducible:

Happens every time

Steps to Reproduce:
1. Launch the program, e.g. 'gthumb -v' or 'cheese'
2.
3.

Actual results:

$ gthumb -v

(gthumb:5022): Gdk-ERROR **: The program 'gthumb' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 159 error_code 16 request_code 152 (DRI2) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap (core dumped)

$ cheese   

(cheese:5032): Gdk-ERROR **: The program 'cheese' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 159 error_code 16 request_code 152 (DRI2) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap (core dumped)

Expected results:

$ gthumb -v
gthumb 3.4.5, Copyright © 2001-2010 Free Software Foundation, Inc.

$ cheese
   A GUI window opens.

Additional info:

attached /var/log/messages extract.

The problem started recently after:
- the graphics card was upgraded:  NVIDIA GeForce 8600 GT -> NVIDIA GEFORCE GT 710
- vdpau was reinstalled (originally did not work due to bad installation) and started working.

Comment 1 Eyal Lebedinsky 2018-04-10 06:46:48 UTC
It was suggested it is worth mentioning the graphics driver:

akmod-nvidia.x86_64                               3:390.48-1.fc26         @rpmfusion-nonfree-updates
kmod-nvidia.x86_64                                3:390.48-1.fc26         @rpmfusion-nonfree-updates
kmod-nvidia-4.15.14-200.fc26.x86_64.x86_64        3:390.48-1.fc26         @@commandline             
nvidia-settings.x86_64                            390.48-1.fc26           @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia.x86_64                        3:390.48-1.fc26         @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-kmodsrc.x86_64                3:390.48-1.fc26         @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-libs.i686                     3:390.48-1.fc26         @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-libs.x86_64                   3:390.48-1.fc26         @rpmfusion-nonfree-updates

Comment 2 Eyal Lebedinsky 2018-04-10 12:35:19 UTC
I now find that google-earth-pro also fails but does not provide much information, no stack trace.

$ dnf list google-earth-pro-stable
Last metadata expiration check: 0:00:14 ago on Tue Apr 10 22:25:50 2018.
Installed Packages
google-earth-pro-stable.x86_64                    7.3.1.4507-0            @google-earth

====================

Also another test. If I do this I get a failure, but running local on e7 works OK.
e7 does not use nvidia and is also an up-to-date f26.

[eyal@e4 ~]$ ssh -X eyal@e7
[eyal@e7 ~]$ gthumb -v
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

** (gthumb:29178): CRITICAL **: Failed to parse arguments: Unable to initialize the Clutter backend: no available drivers found.
Segmentation fault (core dumped)

and on e7 I get this trace

Apr 10 22:28:02 e7 kernel: gthumb[29178]: segfault at d8 ip 00007f2d53752656 sp 00007ffc7a903eb0 error 4 in libcogl.so.20.4.2[7f2d53721000+b3000]
Apr 10 22:28:02 e7 kernel: audit: type=1701 audit(1523363282.110:37142): auid=500 uid=500 gid=500 ses=5108 pid=29178 comm="gthumb" exe="/usr/bin/gthumb" sig=11 res=1
Apr 10 22:28:02 e7 systemd[1]: Started Process Core Dump (PID 29218/UID 0).
Apr 10 22:28:02 e7 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@1-29218-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 10 22:28:02 e7 kernel: audit: type=1130 audit(1523363282.117:37143): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@1-29218-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 10 22:28:02 e7 systemd-coredump[29219]: Process 29178 (gthumb) of user 500 dumped core.

Stack trace of thread 29178:
#0  0x00007f2d53752656 _cogl_renderer_handle_native_event (libcogl.so.20)
#1  0x00007f2d56d87eb0 cogl_gdk_filter (libclutter-1.0.so.0)
#2  0x00007f2d55c6db0f gdk_event_apply_filters (libgdk-3.so.0)
#3  0x00007f2d55c6ddf9 _gdk_x11_display_queue_events (libgdk-3.so.0)
#4  0x00007f2d55c37ba0 gdk_display_get_event (libgdk-3.so.0)
#5  0x00007f2d55c6dba2 gdk_event_source_dispatch (libgdk-3.so.0)
#6  0x00007f2d549a6257 g_main_context_dispatch (libglib-2.0.so.0)
#7  0x00007f2d549a65f8 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
#8  0x00007f2d549a668c g_main_context_iteration (libglib-2.0.so.0)
#9  0x00007f2d54f5ff4a g_application_run (libgio-2.0.so.0)
#10 0x000056428b481cfe main (gthumb)
#11 0x00007f2d53e1788a __libc_start_main (libc.so.6)
#12 0x000056428b481d6a _start (gthumb)

Stack trace of thread 29179:
#0  0x00007f2d53efba5d poll (libc.so.6)
#1  0x00007f2d549a6579 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
#2  0x00007f2d549a668c g_main_context_iteration (libglib-2.0.so.0)
#3  0x00007f2d549a66d1 glib_worker_main (libglib-2.0.so.0)
#4  0x00007f2d549cd516 g_thread_proxy (libglib-2.0.so.0)
#5  0x00007f2d541d336d start_thread (libpthread.so.0)
#6  0x00007f2d53f07b4f __clone (libc.so.6)
Apr 10 22:28:02 e7 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@1-29218-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Comment 3 Eyal Lebedinsky 2018-04-11 05:06:38 UTC
Created attachment 1420161 [details]
a crash trace without nvidia

Looks identical to the same crash when nvidia driver was in use.

Comment 4 Eyal Lebedinsky 2018-04-11 05:13:22 UTC
 IMPORTANT NOTE

Stupid me, I should have tried this earlier. This mobo has on-board intel graphics, so I removed the nvidia card and booted into VGA (this is what the on-board facility provides). No nvidia module loaded.

I get the same gthumb failure, so it is not a simple issue due to a tainted kernel. See attachment.

HTH

Comment 5 Eyal Lebedinsky 2018-04-17 02:34:11 UTC
Some progress. I built gthumb from source
    https://git.gnome.org/browse/gthumb/snapshot/gthumb-3.6.1.tar.xz
and got version 3.6.1.

This version works.

'cheese' still fails, so there must be something more going on. Luckily I do not use 'cheese'.

google-earth-pro is also still failing, leaving an invisible 'initializing' window behind. I do use it and would like it fixed.

Running from the command line shows:

$ google-earth-pro 
Google Earth has caught signal 11.
We apologize for the inconvenience, but Google Earth has crashed.
 This is a bug in the program, and should never happen under normal
 circumstances. A bug report and debugging data have been written
 to this text file:

    /home/eyal/.googleearth/crashlogs/crashlog-5ad55c82.txt

Please include this file if you submit a bug report to Google.

Comment 6 Eyal Lebedinsky 2018-04-30 02:46:43 UTC
Fixed.

Running 'rpm --verify' on all packages included this:
    ....L....    /usr/lib64/libGL.so.1
    ....L....    /usr/lib/libGL.so.1
So I checked:

# ls -l /usr/lib*/libGL.so*
lrwxrwxrwx 1 root root     14 Nov 11 19:18 /usr/lib/libGL.so -> libGL.so.1.0.0
lrwxrwxrwx 1 root root     12 Apr 30 12:14 /usr/lib/libGL.so.1 -> libGL.so.1.2
-rwxr-xr-x 1 root root 404524 Nov 11 19:18 /usr/lib/libGL.so.1.0.0
-rwxr-xr-x 1 root root 452256 Jun 28  2008 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root     14 Nov 11 19:18 /usr/lib64/libGL.so -> libGL.so.1.0.0
lrwxrwxrwx 1 root root     12 Apr 30 12:14 /usr/lib64/libGL.so.1 -> libGL.so.1.2
-rwxr-xr-x 1 root root 581768 Nov 11 19:18 /usr/lib64/libGL.so.1.0.0
-rwxr-xr-x 1 root root 472368 Jun 28  2008 /usr/lib64/libGL.so.1.2

The old 'libGL.so.1.2' looks wrong, so it was removed and the 'libGL.so.1' symlink was fixed. Then 'ldconfig'.

Now 'cheese' and 'google-earth-pro'. All good.


Note You need to log in before you can comment on or make changes to this bug.