After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 465207 - Hangs with Nvidia Twinview and two screens of non-equal height
Hangs with Nvidia Twinview and two screens of non-equal height
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: Background
2.18.x
Other Linux
: Normal critical
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-08-09 22:34 UTC by Sven Arvidsson
Modified: 2007-08-16 17:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Description Sven Arvidsson 2007-08-09 22:34:08 UTC 
[ Forwarded from http://bugs.debian.org/428335 ]

"When TwinView is enabled with a proprietary NVIDIA driver, gnome-background-properties hangs on startup. It  displays the window correctly without any background images (it seams that they are being loaded), displaying a working/waiting cursor. It and gdm use a lot of CPU in the process. This was not the case in Gnome 2.14. This is not the case when I disable TwinView. GDM correctly displays the login screen on only one screen. XFCE has no problem with the setup."

The following error message is printed on the terminal;
(gnome-background-properties:11297): GdkPixbuf-CRITICAL **:
gdk_pixbuf_composite: assertion `src != NULL' failed

"After playing around with the NVIDIA X settings a bit, I have found the problem: gnome-background-settings cannot handle two screens of non-equal height (how did that happen ?) My default set-up uses a 1280x1024 and a 1680x1050 screen next to each other; if I change it to twice 1280x1024 or 1280x1024 & 1600x1024, it works."
Comment 1 Jens Granseuer 2007-08-11 13:25:08 UTC 
In the absence of hardware and drivers to reproduce, it would be very helpful to know where it hangs, which should be easy to find out with gdb.
Comment 2 Thomas Jollans 2007-08-15 17:20:56 UTC 
sorry for not replying earlier

+ Trace 155441

  • #0 __write_nocancel
    from /lib/libpthread.so.0
  • #1 g_log_default_handler
    from /usr/lib/libglib-2.0.so.0
  • #2 g_logv
    from /usr/lib/libglib-2.0.so.0
  • #3 g_log
    from /usr/lib/libglib-2.0.so.0
  • #4 gnome_wp_pixbuf_tile
    at gnome-wp-utils.c line 132
  • #5 gnome_wp_item_get_thumbnail
    at gnome-wp-item.c line 320
  • #6 wp_props_load_wallpaper
    at gnome-wp-capplet.c line 209
  • #7 g_hash_table_foreach
    from /usr/lib/libglib-2.0.so.0
  • #8 gnome_wp_load_stuffs
    at gnome-wp-capplet.c line 596
  • #9 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #10 ??
    from /usr/lib/libglib-2.0.so.0
  • #11 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #12 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #13 main
    at gnome-wp-capplet.c line 1146 


I stopped the loop (assertation failed (see above) in an aparent infinite loop) with ^C. Multiple tries yielded the same backtrace.
Comment 3 Jens Granseuer 2007-08-15 17:43:24 UTC 
Thanks. Any chance you could test with the new appearance capplet in 2.19? There was a similar problem in bug 403160 which I committed a preliminary fix for. Might help in this case, too.

Failing that, a "bt full" for a binary without optimizations is the very least we need.
Comment 4 Thomas Jollans 2007-08-15 19:55:51 UTC 
Just tested with gnome-control-center_1:2.19.5-2 of Debian experimental. It works nicely :)
Comment 5 Jens Granseuer 2007-08-16 17:40:38 UTC 
Great, thanks for testing.