gthumb crash (after enabling vdpau?)

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

gthumb crash (after enabling vdpau?)

Eyal Lebedinsky
I recently replaced my graphics card (with NVIDIA GT 710).
A newer nvidia module was installed
        kmod-nvidia-340xx-4.15.7-200 -> kmod-nvidia-390.42-1
I also enabled VDPAU which was incorrectly installed until now.

I now have a failure of 'gthumb':

$ gthumb -v

(gthumb:7097): 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)

and /var/log/messages includes a trace:

Apr  2 15:03:32 e4 systemd-coredump[20472]: Process 20469 (gthumb) of user 500 dumped core.
Stack trace of thread 20469:
0  0x00007f4312e31e51 _g_log_abort (libglib-2.0.so.0)
1  0x00007f4312e344a1 g_log_writer_default (libglib-2.0.so.0)
2  0x00007f4312e329ee g_log_structured_array (libglib-2.0.so.0)
3  0x00007f4312e32ce7 g_log_structured (libglib-2.0.so.0)
4  0x00007f43140ec351 _gdk_x11_display_error_event (libgdk-3.so.0)
5  0x00007f43140f9813 gdk_x_error (libgdk-3.so.0)
6  0x00007f43103da9ba _XError (libX11.so.6)
7  0x00007f43103d78eb handle_error (libX11.so.6)
8  0x00007f43103d8a94 _XReply (libX11.so.6)
9  0x00007f430cb27f2b DRI2Connect (libGL.so.1)
10 0x00007f430cb274a8 n/a (libGL.so.1)
11 0x00007f430cb0b5c0 n/a (libGL.so.1)
12 0x00007f430cb07c60 glXQueryVersion (libGL.so.1)
13 0x00007f4311c1f153 _cogl_winsys_renderer_connect (libcogl.so.20)
14 0x00007f4311bd822d cogl_renderer_connect (libcogl.so.20)
15 0x00007f4315237824 clutter_backend_real_create_context (libclutter-1.0.so.0)
16 0x00007f4315250a13 _clutter_feature_init (libclutter-1.0.so.0)
17 0x00007f4315261ca9 clutter_init_real (libclutter-1.0.so.0)
18 0x00007f43155342f6 post_parse_hook (libclutter-gtk-1.0.so.0)
19 0x00007f4312e384f0 g_option_context_parse (libglib-2.0.so.0)
20 0x00005564d3a9661f gth_application_local_command_line (gthumb)
21 0x00007f43133e5e46 g_application_run (libgio-2.0.so.0)
22 0x00005564d3a1bcfe main (gthumb)
23 0x00007f431229d88a __libc_start_main (libc.so.6)
24 0x00005564d3a1bd6a _start (gthumb)
Stack trace of thread 20470:
0  0x00007f4312381a5d poll (libc.so.6)
1  0x00007f4312e2c579 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
2  0x00007f4312e2c68c g_main_context_iteration (libglib-2.0.so.0)
3  0x00007f4312e2c6d1 glib_worker_main (libglib-2.0.so.0)
4  0x00007f4312e53516 g_thread_proxy (libglib-2.0.so.0)
5  0x00007f431265936d start_thread (libpthread.so.0)
6  0x00007f431238db4f __clone (libc.so.6)


I see that the gthumb package was updated in 2017, dnf.log says:
        Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.3-1.fc24 will be upgraded
        Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.5-1.fc26 will be an upgrade
The update was part of a f24->f26 upgrade. There is no later version of gthumb but I do see
version 3.6.0 in f27.

I also see that this gthumb version is one year old:
        $ ls -l /usr/bin/gthumb
        -rwxr-xr-x 1 root root 988384 Apr 20  2017 /usr/bin/gthumb

The gthumb package depends on the libvdpau package so I suspect some incompatibility.
Reinstalling both packages does not improve the situation.

Is gthumb still maintained? https://github.com/GNOME/gthumb suggests perusing
https://wiki.gnome.org/Apps/gthumb which is not present.

Still, too many packages are involved, not the least X/nvidia ones.

Is anyone else seeing this problem? I do not want to log a bug if this is the result
of my system long update history, but I do want to resolve this.

I have another f26 machine that has no problems but does not use vdpau (or nvidia card).

TIA

--
Eyal Lebedinsky ([hidden email])
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: gthumb crash (after enabling vdpau?)

Ed Greshko-2
On 04/03/18 09:21, Eyal Lebedinsky wrote:
> I recently replaced my graphics card (with NVIDIA GT 710).
> A newer nvidia module was installed
>     kmod-nvidia-340xx-4.15.7-200 -> kmod-nvidia-390.42-1
> I also enabled VDPAU which was incorrectly installed until now.

I don't know what you mean by that.  I thought the nVidia drivers had VDPAU enabled
by default.

What do you get as the output of vpauinfo?  You may have to install it.


>
> I now have a failure of 'gthumb':
>
> $ gthumb -v
>
> (gthumb:7097): 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)
>
> and /var/log/messages includes a trace:
<snip>

> I see that the gthumb package was updated in 2017, dnf.log says:
>     Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.3-1.fc24 will be upgraded
>     Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.5-1.fc26 will be an upgrade
> The update was part of a f24->f26 upgrade. There is no later version of gthumb but
> I do see
> version 3.6.0 in f27.
>
> I also see that this gthumb version is one year old:
>     $ ls -l /usr/bin/gthumb
>     -rwxr-xr-x 1 root root 988384 Apr 20  2017 /usr/bin/gthumb
>
> The gthumb package depends on the libvdpau package so I suspect some incompatibility.
> Reinstalling both packages does not improve the situation.
>
> Is gthumb still maintained? https://github.com/GNOME/gthumb suggests perusing
> https://wiki.gnome.org/Apps/gthumb which is not present.
>
> Still, too many packages are involved, not the least X/nvidia ones.
>
> Is anyone else seeing this problem? I do not want to log a bug if this is the result
> of my system long update history, but I do want to resolve this.
>
> I have another f26 machine that has no problems but does not use vdpau (or nvidia
> card).
>
>
I am running F27 with the nvidia-390.42-1 drivers installed and a GeForce GTX 660 card.

[egreshko@meimei ~]$ gthumb -v
gthumb 3.6.0, Copyright © 2001-2010 Free Software Foundation, Inc.


--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.


_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: gthumb crash (after enabling vdpau?)

Eyal Lebedinsky
On 03/04/18 13:15, Ed Greshko wrote:
> On 04/03/18 09:21, Eyal Lebedinsky wrote:
>> I recently replaced my graphics card (with NVIDIA GT 710).
>> A newer nvidia module was installed
>>      kmod-nvidia-340xx-4.15.7-200 -> kmod-nvidia-390.42-1
>> I also enabled VDPAU which was incorrectly installed until now.
>
> I don't know what you mean by that.  I thought the nVidia drivers had VDPAU enabled
> by default.

Yes.

My problem was a bad installation due to the many updates for many years.

This is what I have now:

$ ls -l /usr/lib64/*vdpau*
lrwxrwxrwx  1 root root    17 Apr  3 15:43 /usr/lib64/libvdpau.so.1 -> libvdpau.so.1.0.0
-rwxr-xr-x  1 root root 15248 Feb 11  2017 /usr/lib64/libvdpau.so.1.0.0
lrwxrwxrwx  1 root root    19 Jun  5  2015 /usr/lib64/libvdpau_gallium.so.1 -> libvdpau_nouveau.so
lrwxrwxrwx  1 root root    27 Aug 26  2013 /usr/lib64/libvdpau_nouveau.so -> vdpau/libvdpau_nouveau.so.1
lrwxrwxrwx  1 root root    26 Apr  3 15:41 /usr/lib64/libvdpau_nvidia.so -> vdpau/libvdpau_nvidia.so.1
lrwxrwxrwx  1 root root    23 Sep  1  2013 /usr/lib64/libvdpau_trace.so -> vdpau/libvdpau_trace.so

/usr/lib64/vdpau:
total 23032
lrwxrwxrwx 1 root root      25 Nov 11 04:46 libvdpau_nouveau.so.1 -> libvdpau_nouveau.so.1.0.0
lrwxrwxrwx 1 root root      25 Nov 11 04:46 libvdpau_nouveau.so.1.0 -> libvdpau_nouveau.so.1.0.0
-rwxr-xr-x 4 root root 5656376 Nov 11 04:47 libvdpau_nouveau.so.1.0.0
lrwxrwxrwx 1 root root      25 Mar 20 02:11 libvdpau_nvidia.so.1 -> libvdpau_nvidia.so.390.42
-rwxr-xr-x 1 root root  893984 Mar  3 22:29 libvdpau_nvidia.so.390.42
lrwxrwxrwx 1 root root      22 Nov 11 04:46 libvdpau_r300.so.1 -> libvdpau_r300.so.1.0.0
lrwxrwxrwx 1 root root      22 Nov 11 04:46 libvdpau_r300.so.1.0 -> libvdpau_r300.so.1.0.0
-rwxr-xr-x 4 root root 5656376 Nov 11 04:47 libvdpau_r300.so.1.0.0
lrwxrwxrwx 1 root root      22 Nov 11 04:46 libvdpau_r600.so.1 -> libvdpau_r600.so.1.0.0
lrwxrwxrwx 1 root root      22 Nov 11 04:46 libvdpau_r600.so.1.0 -> libvdpau_r600.so.1.0.0
-rwxr-xr-x 4 root root 5656376 Nov 11 04:47 libvdpau_r600.so.1.0.0
lrwxrwxrwx 1 root root      26 Nov 11 04:46 libvdpau_radeonsi.so.1 -> libvdpau_radeonsi.so.1.0.0
lrwxrwxrwx 1 root root      26 Nov 11 04:46 libvdpau_radeonsi.so.1.0 -> libvdpau_radeonsi.so.1.0.0
-rwxr-xr-x 4 root root 5656376 Nov 11 04:47 libvdpau_radeonsi.so.1.0.0
lrwxrwxrwx 1 root root      23 Feb 11  2017 libvdpau_trace.so -> libvdpau_trace.so.1.0.0
lrwxrwxrwx 1 root root      23 Feb 11  2017 libvdpau_trace.so.1 -> libvdpau_trace.so.1.0.0
-rwxr-xr-x 1 root root   57520 Feb 11  2017 libvdpau_trace.so.1.0.0

I added the /usr/lib64/libvdpau_nvidia.so which was missing.

> What do you get as the output of vpauinfo?  You may have to install it.

Looks OK to me:

$ vdpauinfo
display: :0   screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library  390.42  Sat Mar  3 03:29:48 PST 2018

Video surface:

name   width height types
-------------------------------------------
420     4096  4096  NV12 YV12
422     4096  4096  UYVY YUYV

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                           0 65536  4032  4048
MPEG2_SIMPLE                    3 65536  4032  4048
MPEG2_MAIN                      3 65536  4032  4048
H264_BASELINE                  41 65536  4032  4080
H264_MAIN                      41 65536  4032  4080
H264_HIGH                      41 65536  4032  4080
VC1_SIMPLE                      1  8190  2048  2048
VC1_MAIN                        2  8190  2048  2048
VC1_ADVANCED                    4  8190  2048  2048
MPEG4_PART2_SP                  3  8192  2048  2048
MPEG4_PART2_ASP                 5  8192  2048  2048
DIVX4_QMOBILE                   0  8192  2048  2048
DIVX4_MOBILE                    0  8192  2048  2048
DIVX4_HOME_THEATER              0  8192  2048  2048
DIVX4_HD_1080P                  0  8192  2048  2048
DIVX5_QMOBILE                   0  8192  2048  2048
DIVX5_MOBILE                    0  8192  2048  2048
DIVX5_HOME_THEATER              0  8192  2048  2048
DIVX5_HD_1080P                  0  8192  2048  2048
H264_CONSTRAINED_BASELINE      41 65536  4032  4080
H264_EXTENDED                  41 65536  4032  4080
H264_PROGRESSIVE_HIGH          41 65536  4032  4080
H264_CONSTRAINED_HIGH          41 65536  4032  4080
H264_HIGH_444_PREDICTIVE       41 65536  4032  4080
HEVC_MAIN                      --- not supported ---
HEVC_MAIN_10                   --- not supported ---
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         16384 16384    y  Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8
R10G10B10A2      16384 16384    y  Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             y
DEINTERLACE_TEMPORAL_SPATIAL     y
INVERSE_TELECINE                 y
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         y
HIGH QUALITY SCALING - L1        y
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              y         1     4096
VIDEO_SURFACE_HEIGHT             y         1     4096
CHROMA_TYPE                      y
LAYERS                           y         0        4

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 y
CSC_MATRIX                       y
NOISE_REDUCTION_LEVEL            y      0.00     1.00
SHARPNESS_LEVEL                  y     -1.00     1.00
LUMA_KEY_MIN_LUMA                y
LUMA_KEY_MAX_LUMA                y


>> I now have a failure of 'gthumb':
>>
>> $ gthumb -v
>>
>> (gthumb:7097): 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)
>>
>> and /var/log/messages includes a trace:
>
> <snip>
>
>> I see that the gthumb package was updated in 2017, dnf.log says:
>>      Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.3-1.fc24 will be upgraded
>>      Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.5-1.fc26 will be an upgrade
>> The update was part of a f24->f26 upgrade. There is no later version of gthumb but
>> I do see
>> version 3.6.0 in f27.
>>
>> I also see that this gthumb version is one year old:
>>      $ ls -l /usr/bin/gthumb
>>      -rwxr-xr-x 1 root root 988384 Apr 20  2017 /usr/bin/gthumb
>>
>> The gthumb package depends on the libvdpau package so I suspect some incompatibility.
>> Reinstalling both packages does not improve the situation.
>>
>> Is gthumb still maintained? https://github.com/GNOME/gthumb suggests perusing
>> https://wiki.gnome.org/Apps/gthumb which is not present.
>>
>> Still, too many packages are involved, not the least X/nvidia ones.
>>
>> Is anyone else seeing this problem? I do not want to log a bug if this is the result
>> of my system long update history, but I do want to resolve this.
>>
>> I have another f26 machine that has no problems but does not use vdpau (or nvidia
>> card).
>>
>>
>
> I am running F27 with the nvidia-390.42-1 drivers installed and a GeForce GTX 660 card.
>
> [egreshko@meimei ~]$ gthumb -v
> gthumb 3.6.0, Copyright © 2001-2010 Free Software Foundation, Inc.

I am running F26 which has:

$ dnf list gthumb
Installed Packages
gthumb.x86_64                                1:3.4.5-1.fc26     @fedora

$ dnf list 'kmod-nvidia*'
Last metadata expiration check: 19 days, 2:35:35 ago on Thu Mar 15 14:29:34 2018.
Installed Packages
kmod-nvidia.x86_64                           3:390.42-1.fc26    @rpmfusion-nonfree-updates
kmod-nvidia-4.15.10-200.fc26.x86_64.x86_64   3:390.42-1.fc26    @@commandline
kmod-nvidia-4.15.12-201.fc26.x86_64.x86_64   3:390.42-1.fc26    @@commandline
kmod-nvidia-4.15.7-200.fc26.x86_64.x86_64    3:390.42-1.fc26    @@commandline

$ dnf list '*vdpau*'
Last metadata expiration check: 19 days, 2:30:09 ago on Thu Mar 15 14:29:34 2018.
Installed Packages
libvdpau.i686                                1.1.1-4.fc26      @fedora
libvdpau.x86_64                              1.1.1-4.fc26      @fedora
mesa-vdpau-drivers.x86_64                    17.2.4-2.fc26     @updates
vdpauinfo.x86_64                             1.0-6.fc26        @@commandline

I do not know why the i686 is installed but 82 other packages depend on it so I left it alone.

It may still be the case that the latest gthumb fixed an X API issue?

--
Eyal Lebedinsky ([hidden email])
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: gthumb crash (after enabling vdpau?)

Ed Greshko-2
On 04/03/18 14:08, Eyal Lebedinsky wrote:
> I do not know why the i686 is installed but 82 other packages depend on it so I
> left it alone.
>
> It may still be the case that the latest gthumb fixed an X API issue?


Well, gthumb on my system doesn't appear to use vdpau.

[egreshko@meimei vdpau]$ ldd -v /usr/bin/gthumb | grep vdpau
[egreshko@meimei vdpau]$

unlike mplayer

[egreshko@meimei vdpau]$ ldd -v /usr/bin/mplayer | grep vdpau
        libvdpau.so.1 => /lib64/libvdpau.so.1 (0x00007f48839ea000)
        /lib64/libvdpau.so.1:

Just for completeness

[egreshko@meimei lib64]$ pwd
/usr/lib64

[egreshko@meimei lib64]$ ll libvdpau.so.1*
lrwxrwxrwx. 1 root root    17 Oct 12 20:12 libvdpau.so.1 -> libvdpau.so.1.0.0
-rwxr-xr-x. 1 root root 15360 Oct 12 20:12 libvdpau.so.1.0.0

[egreshko@meimei lib64]$ ll vdpau/
total 936
lrwxrwxrwx. 1 root root     25 Mar 19 23:09 libvdpau_nvidia.so.1 ->
libvdpau_nvidia.so.390.42
-rwxr-xr-x. 1 root root 893984 Mar  3 19:29 libvdpau_nvidia.so.390.42
lrwxrwxrwx. 1 root root     23 Oct 12 20:12 libvdpau_trace.so -> libvdpau_trace.so.1.0.0
lrwxrwxrwx. 1 root root     23 Oct 12 20:12 libvdpau_trace.so.1 ->
libvdpau_trace.so.1.0.0
-rwxr-xr-x. 1 root root  57608 Oct 12 20:12 libvdpau_trace.so.1.0.0

--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.


_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: gthumb crash (after enabling vdpau?)

Rick Stevens-3
In reply to this post by Eyal Lebedinsky
On 04/02/2018 06:21 PM, Eyal Lebedinsky wrote:

> I recently replaced my graphics card (with NVIDIA GT 710).
> A newer nvidia module was installed
>     kmod-nvidia-340xx-4.15.7-200 -> kmod-nvidia-390.42-1
> I also enabled VDPAU which was incorrectly installed until now.
>
> I now have a failure of 'gthumb':
>
> $ gthumb -v
>
> (gthumb:7097): 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)
>
> and /var/log/messages includes a trace:
>
> Apr  2 15:03:32 e4 systemd-coredump[20472]: Process 20469 (gthumb) of
> user 500 dumped core.
> Stack trace of thread 20469:
> 0  0x00007f4312e31e51 _g_log_abort (libglib-2.0.so.0)
> 1  0x00007f4312e344a1 g_log_writer_default (libglib-2.0.so.0)
> 2  0x00007f4312e329ee g_log_structured_array (libglib-2.0.so.0)
> 3  0x00007f4312e32ce7 g_log_structured (libglib-2.0.so.0)
> 4  0x00007f43140ec351 _gdk_x11_display_error_event (libgdk-3.so.0)
> 5  0x00007f43140f9813 gdk_x_error (libgdk-3.so.0)
> 6  0x00007f43103da9ba _XError (libX11.so.6)
> 7  0x00007f43103d78eb handle_error (libX11.so.6)
> 8  0x00007f43103d8a94 _XReply (libX11.so.6)
> 9  0x00007f430cb27f2b DRI2Connect (libGL.so.1)
> 10 0x00007f430cb274a8 n/a (libGL.so.1)
> 11 0x00007f430cb0b5c0 n/a (libGL.so.1)
> 12 0x00007f430cb07c60 glXQueryVersion (libGL.so.1)
> 13 0x00007f4311c1f153 _cogl_winsys_renderer_connect (libcogl.so.20)
> 14 0x00007f4311bd822d cogl_renderer_connect (libcogl.so.20)
> 15 0x00007f4315237824 clutter_backend_real_create_context
> (libclutter-1.0.so.0)
> 16 0x00007f4315250a13 _clutter_feature_init (libclutter-1.0.so.0)
> 17 0x00007f4315261ca9 clutter_init_real (libclutter-1.0.so.0)
> 18 0x00007f43155342f6 post_parse_hook (libclutter-gtk-1.0.so.0)
> 19 0x00007f4312e384f0 g_option_context_parse (libglib-2.0.so.0)
> 20 0x00005564d3a9661f gth_application_local_command_line (gthumb)
> 21 0x00007f43133e5e46 g_application_run (libgio-2.0.so.0)
> 22 0x00005564d3a1bcfe main (gthumb)
> 23 0x00007f431229d88a __libc_start_main (libc.so.6)
> 24 0x00005564d3a1bd6a _start (gthumb)
> Stack trace of thread 20470:
> 0  0x00007f4312381a5d poll (libc.so.6)
> 1  0x00007f4312e2c579 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
> 2  0x00007f4312e2c68c g_main_context_iteration (libglib-2.0.so.0)
> 3  0x00007f4312e2c6d1 glib_worker_main (libglib-2.0.so.0)
> 4  0x00007f4312e53516 g_thread_proxy (libglib-2.0.so.0)
> 5  0x00007f431265936d start_thread (libpthread.so.0)
> 6  0x00007f431238db4f __clone (libc.so.6)
>
>
> I see that the gthumb package was updated in 2017, dnf.log says:
>     Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.3-1.fc24 will
> be upgraded
>     Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.5-1.fc26 will
> be an upgrade
> The update was part of a f24->f26 upgrade. There is no later version of
> gthumb but I do see
> version 3.6.0 in f27.
>
> I also see that this gthumb version is one year old:
>     $ ls -l /usr/bin/gthumb
>     -rwxr-xr-x 1 root root 988384 Apr 20  2017 /usr/bin/gthumb
>
> The gthumb package depends on the libvdpau package so I suspect some
> incompatibility.
> Reinstalling both packages does not improve the situation.
>
> Is gthumb still maintained? https://github.com/GNOME/gthumb suggests
> perusing
> https://wiki.gnome.org/Apps/gthumb which is not present.
>
> Still, too many packages are involved, not the least X/nvidia ones.
>
> Is anyone else seeing this problem? I do not want to log a bug if this
> is the result
> of my system long update history, but I do want to resolve this.
>
> I have another f26 machine that has no problems but does not use vdpau
> (or nvidia card).

Yes, for F27 the latest gthumb is 3.6.0-1 and the latest libvdpau is
1.1.1-6. I don't use gnome myself and don't even have gthumb installed
so I can't speak to its operation.

I'd go ahead and file a bugzilla with all the relevant data you have.
The maintainers will make a determination as to if it's legit or not.
I'd suggest upgrading to F27 if possible as it appears they aren't
backporting the changes to F26.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [hidden email] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-   NEWS FLASH! Intelligence of mankind decreasing!  Details at...   -
-     uh, when, uh, the little hand is, uh, on the...  Aw, NUTS!     -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: gthumb crash (after enabling vdpau?)

Eyal Lebedinsky
In reply to this post by Eyal Lebedinsky
If anyone is interested, this is now on redhat bugzilla
        https://bugzilla.redhat.com/show_bug.cgi?id=1564794

HTH

On 03/04/18 11:21, Eyal Lebedinsky wrote:

> I recently replaced my graphics card (with NVIDIA GT 710).
> A newer nvidia module was installed
>      kmod-nvidia-340xx-4.15.7-200 -> kmod-nvidia-390.42-1
> I also enabled VDPAU which was incorrectly installed until now.
>
> I now have a failure of 'gthumb':
>
> $ gthumb -v
>
> (gthumb:7097): 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)
>
> and /var/log/messages includes a trace:
>
> Apr  2 15:03:32 e4 systemd-coredump[20472]: Process 20469 (gthumb) of user 500 dumped core.
> Stack trace of thread 20469:
> 0  0x00007f4312e31e51 _g_log_abort (libglib-2.0.so.0)
> 1  0x00007f4312e344a1 g_log_writer_default (libglib-2.0.so.0)
> 2  0x00007f4312e329ee g_log_structured_array (libglib-2.0.so.0)
> 3  0x00007f4312e32ce7 g_log_structured (libglib-2.0.so.0)
> 4  0x00007f43140ec351 _gdk_x11_display_error_event (libgdk-3.so.0)
> 5  0x00007f43140f9813 gdk_x_error (libgdk-3.so.0)
> 6  0x00007f43103da9ba _XError (libX11.so.6)
> 7  0x00007f43103d78eb handle_error (libX11.so.6)
> 8  0x00007f43103d8a94 _XReply (libX11.so.6)
> 9  0x00007f430cb27f2b DRI2Connect (libGL.so.1)
> 10 0x00007f430cb274a8 n/a (libGL.so.1)
> 11 0x00007f430cb0b5c0 n/a (libGL.so.1)
> 12 0x00007f430cb07c60 glXQueryVersion (libGL.so.1)
> 13 0x00007f4311c1f153 _cogl_winsys_renderer_connect (libcogl.so.20)
> 14 0x00007f4311bd822d cogl_renderer_connect (libcogl.so.20)
> 15 0x00007f4315237824 clutter_backend_real_create_context (libclutter-1.0.so.0)
> 16 0x00007f4315250a13 _clutter_feature_init (libclutter-1.0.so.0)
> 17 0x00007f4315261ca9 clutter_init_real (libclutter-1.0.so.0)
> 18 0x00007f43155342f6 post_parse_hook (libclutter-gtk-1.0.so.0)
> 19 0x00007f4312e384f0 g_option_context_parse (libglib-2.0.so.0)
> 20 0x00005564d3a9661f gth_application_local_command_line (gthumb)
> 21 0x00007f43133e5e46 g_application_run (libgio-2.0.so.0)
> 22 0x00005564d3a1bcfe main (gthumb)
> 23 0x00007f431229d88a __libc_start_main (libc.so.6)
> 24 0x00005564d3a1bd6a _start (gthumb)
> Stack trace of thread 20470:
> 0  0x00007f4312381a5d poll (libc.so.6)
> 1  0x00007f4312e2c579 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
> 2  0x00007f4312e2c68c g_main_context_iteration (libglib-2.0.so.0)
> 3  0x00007f4312e2c6d1 glib_worker_main (libglib-2.0.so.0)
> 4  0x00007f4312e53516 g_thread_proxy (libglib-2.0.so.0)
> 5  0x00007f431265936d start_thread (libpthread.so.0)
> 6  0x00007f431238db4f __clone (libc.so.6)
>
>
> I see that the gthumb package was updated in 2017, dnf.log says:
>      Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.3-1.fc24 will be upgraded
>      Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.5-1.fc26 will be an upgrade
> The update was part of a f24->f26 upgrade. There is no later version of gthumb but I do see
> version 3.6.0 in f27.
>
> I also see that this gthumb version is one year old:
>      $ ls -l /usr/bin/gthumb
>      -rwxr-xr-x 1 root root 988384 Apr 20  2017 /usr/bin/gthumb
>
> The gthumb package depends on the libvdpau package so I suspect some incompatibility.
> Reinstalling both packages does not improve the situation.
>
> Is gthumb still maintained? https://github.com/GNOME/gthumb suggests perusing
> https://wiki.gnome.org/Apps/gthumb which is not present.
>
> Still, too many packages are involved, not the least X/nvidia ones.
>
> Is anyone else seeing this problem? I do not want to log a bug if this is the result
> of my system long update history, but I do want to resolve this.
>
> I have another f26 machine that has no problems but does not use vdpau (or nvidia card).
>
> TIA

--
Eyal Lebedinsky ([hidden email])
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: gthumb crash (after enabling vdpau?)

Ed Greshko
On 04/10/18 13:04, Eyal Lebedinsky wrote:
> If anyone is interested, this is now on redhat bugzilla
>     https://bugzilla.redhat.com/show_bug.cgi?id=1564794
>
>

I don't see in the BZ where you indicate you're using the nVidia binary drivers.  I
think you should mention that bit of information.  May save people a bit of time.


--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.


_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: gthumb crash (after enabling vdpau?)

John Pilkington-2
In reply to this post by Eyal Lebedinsky
On 10/04/18 06:04, Eyal Lebedinsky wrote:

> If anyone is interested, this is now on redhat bugzilla
>     https://bugzilla.redhat.com/show_bug.cgi?id=1564794
>
> HTH
>
> On 03/04/18 11:21, Eyal Lebedinsky wrote:
>> I recently replaced my graphics card (with NVIDIA GT 710).
>> A newer nvidia module was installed
>>      kmod-nvidia-340xx-4.15.7-200 -> kmod-nvidia-390.42-1
>> I also enabled VDPAU which was incorrectly installed until now.
I have no idea if this is relevant, but my nvidia GT710 card works well
with the latest driver from rpmfusion

nvidia-kmod-390.48-1.fc26...

 


_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: gthumb crash (after enabling vdpau?)

Eyal Lebedinsky
In reply to this post by Eyal Lebedinsky
On 03/04/18 11:21, Eyal Lebedinsky wrote:
> I recently replaced my graphics card (with NVIDIA GT 710).
> A newer nvidia module was installed
>      kmod-nvidia-340xx-4.15.7-200 -> kmod-nvidia-390.42-1
> I also enabled VDPAU which was incorrectly installed until now.
>
> I now have a failure of 'gthumb'

[trimmed details]

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.
The stack trace also looks identical.

See the bugzilla  item https://bugzilla.redhat.com/show_bug.cgi?id=1564794

HTH

--
--
Eyal Lebedinsky ([hidden email])
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: gthumb crash (after enabling vdpau?)

Eyal Lebedinsky
In reply to this post by Eyal Lebedinsky
On 03/04/18 11:21, Eyal Lebedinsky wrote:

> I recently replaced my graphics card (with NVIDIA GT 710).
> A newer nvidia module was installed
>      kmod-nvidia-340xx-4.15.7-200 -> kmod-nvidia-390.42-1
> I also enabled VDPAU which was incorrectly installed until now.
>
> I now have a failure of 'gthumb':
>
> $ gthumb -v
>
> (gthumb:7097): 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)

[trimmed]

For the record, I built gthumb-3.6.1 from source and this one works.
I cannot tell if gthumb has improved or the build used other resources that made it work.
'cheese' and 'google-earth-pro' still failing.

I wonder if some common change in the distro (API change?) required a rebuild of some packages,
which was not done?

HTH

--
Eyal Lebedinsky ([hidden email])
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]