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 593249 - emacs and acroread don't work properly after upgrading to 2.17.9
emacs and acroread don't work properly after upgrading to 2.17.9
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
2.17.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
csw
: 593202 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-08-27 02:29 UTC by David Ronis
Modified: 2009-09-02 21:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description David Ronis 2009-08-27 02:29:16 UTC 
I build and run gnome in a garnome environment (which means that everything gets installed seperatly from the system's distribution files and are then used by playing with PATH and LD_LIBRARY_PATH).   For what follows this means it's easy to revert to the default system files (here, slackware-12.2).

Since upgrading from gtk+2.17.7 (I'm currently at 2.17.9) emacs and acroread don't work as expected.

acroread SIGSEGV's

emacs runs, but the menu tabs get corrupted.  Specifically, as soon as multiple buffers are opened, the menu entries don't change as the various buffers are accessed.  I've reported this on the emacs bug list at:

http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-08/msg00366.html

Both programs work properly if I break out of the garnome environment (which removes all the recent gnome directories from PATH and LD_LIBRARY_PATH).   Note that slackware no longer supports gnome, so what's installed there is pretty minimal.

I'm not sure that this is a gtk+ error, but I'm sure that it is related to gnome.
Comment 1 Christian Persch 2009-08-27 11:03:45 UTC 
Confirming that acroread segfaults.

Program received signal SIGSEGV, Segmentation fault.

+ Trace 217177

Thread 3042499136 (LWP 8484)

  • #0 gdk_window_get_geometry
    at gdkwindow.c line 7363
  • #1 _start 

It's because this new code in gdk_window_get_geometry() assumes x and y != NULL, contrarily to the documentation that explicitly allows NULL.

          if (parent && !gdk_window_has_impl (parent))
            {
              *x -= parent->abs_x;
              *y -= parent->abs_y;
            }
Comment 2 Alexander Larsson 2009-08-27 11:24:47 UTC 
I fixed the gdk_window_get_geometry crash.
Comment 3 Alexander Larsson 2009-08-27 11:34:14 UTC 
For the emacs thing, I can reproduce this here, but emacs does some pretty weird things in its Gtk+ integration that can conflict quite a lot with the new client-side window stuff in the later Gtk+.

Running with GDK_NATIVE_WINDOWS=1 in gtk+ >= 2.17.9 fixes this issue, although setting that in emacs may not be a good idea as it will propagate to apps launched by emacs. Instead I would recommend adding some code to emacs that calls gdk_x11_drawable_get_xid() on all "toplevel" Gtk+ widgets they put in the buffer window. This will ensure these windows get their own X window and should be totally backwards compat and safe on older versions of Gtk+.
Comment 4 David Ronis 2009-08-27 16:53:08 UTC 
Alexander,

Would you post the patch for comment #2?  I'm not building from git.

Thanks!

David
Comment 6 Alexander Larsson 2009-09-01 09:30:25 UTC 
*** Bug 593202 has been marked as a duplicate of this bug. ***
Comment 7 era+gnome 2009-09-02 18:40:49 UTC 
According to http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4122 Emacs 23 has been patched to fix this.
Comment 8 David Ronis 2009-09-02 21:46:09 UTC 
Indeed it has been fixed as mentioned in Comment 7.  Changing to resolved/fixed.