175755 - GTK native themes crash on Solaris 2.6

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Thomas Leineweber]

On startup the browser crashes immediately after showing the window with the
following errors:

>[leineweb@theoden] ./mozilla
>X Error of failed request:  BadMatch (invalid parameter attributes)
>  Major opcode of failed request:  70 (X_PolyFillRectangle)
>  Serial number of failed request:  1899
>  Current serial number in output stream:  1918
>X Error of failed request:  BadMatch (invalid parameter attributes)
>  Major opcode of failed request:  70 (X_PolyFillRectangle)
>  Serial number of failed request:  1901
>  Current serial number in output stream:  1919
>[status 1]
>[leineweb@theoden]

It happens with the first interaction of the user with the window.

This happens on the actual compiled CVS version and the actual nightly build
for Solaris 2.6. I am using gtk-1.2.10.

Doing a search on the nightly builds for solaris-sparc-2.6, I found out, that
the build 2002101422 (directory 2002-10-14-21-trunk) is the last one, which does
not have this error.

Comment 1

[GavinS]

The latest nightly (Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2b)
Gecko/20021019, build 2002101922) crashes for me on startup too.

This is solaris 2.6, V1.2.10 of gtk

>X Error of failed request:  BadMatch (invalid parameter attributes)
>  Major opcode of failed request:  66 (X_PolySegment)
>  Serial number of failed request:  1321
>  Current serial number in output stream:  1336
>X Error of failed request:  BadMatch (invalid parameter attributes)
>  Major opcode of failed request:  66 (X_PolySegment)
>  Serial number of failed request:  1323
>  Current serial number in output stream:  1337

Comment 2

[Thomas Leineweber]

My further investigations with bonsai (checking for the checkins done these two
days), show me, that the checkin for "Enabling GTK native theme support
(bug 142334)" is the culprit. Undoing the checkin gives me a perfect stable
version of mozilla.

Comment 3

[GavinS]

So this is sort of a dupe of bug#164843 and bug#164581 maybe?

Comment 4

[Thomas Leineweber]

As we agree on the culprit -> change the summary

Comment 5

[timeless]

.

Comment 6

[Brian Ryner (not reading)]

Does anyone have a stack trace and/or talkback report for this crash?

Comment 7

[Christopher Blizzard (:blizzard)]

Might be mixing visual somewhere.

Comment 8

[Thomas Leineweber]

Attachment: Debugger Session with the crash

I made a debugging session with a debug-build. The complete transcript is
attached.

Comment 9

[Christopher Blizzard (:blizzard)]

#0  0xeee8a688 in exit () from /usr/lib/libc.so.1
#1  0xef029d98 in _XDefaultError () from /usr/openwin/lib/libX11.so.4
#2  0xecd6b624 in XIMErrorHandler (dpy=0x11c338, event=0xefff9590)
    at nsGtkIMEHelper.cpp:1182
#3  0xef01fbcc in _XError () from /usr/openwin/lib/libX11.so.4
#4  0xef011e74 in _XReply () from /usr/openwin/lib/libX11.so.4
#5  0xef016eec in XSync () from /usr/openwin/lib/libX11.so.4
#6  0xef14a91c in gdk_flush () at gdkevents.c:2291
#7  0xed375cd4 in nsNativeThemeGTK::DrawWidgetBackground (this=0x29d6f8, 
    aContext=0x3988f8, aFrame=0x325b24, aWidgetType=200 '�', 

Something to do with XIM?

Comment 10

[Roland Mainz]

Christopher Blizzard wrote:
> Something to do with XIM?

No, I guess XIM only registered an error handler for it's own work.

Comment 11

[Christopher Blizzard (:blizzard)]

That's exactly what I was guessing.  We might need to push the error handler for
XIM as well.  I didn't even realize that XIM was adding an error handler, for
that matter.

Comment 12

[Roland Mainz]

Christopher Blizzard wrote:
> I didn't even realize that XIM was adding an error handler, for
> that matter.

AFAIK the X font code, X input methods and Xprint use X error handlers.
X clipboard and code which accesses X atoms should use it, too (since access may
be restricted) - but I did not look at that since a long time...

Comment 13

[Brian Ryner (not reading)]

What blizzard says seems likely.  I just tested on Solaris 8 and didn't crash, fwiw.

Comment 14

[Roland Mainz]

Brian Ryner wrote:
> What blizzard says seems likely.  I just tested on Solaris 8 and didn't crash,
> fwiw

Note that not all Solaris locales have input methods enabled (you can change the
locale under "Options" in the CDE login screen).
For example "en_US" uses no IM while "en_US.UTF-8" has IM enabled (assuming the
XIM-releated packages were installed).

Comment 15

[Brian Ryner (not reading)]

Attachment: patch

On Solaris, the widget code (XIM in particular) installs a new error handler
that overrides gdk's error handler.  This means that gdk_error_trap_push/pop is
not having any effect.	What I've done instead is make a new error handler that
we install during the painting, then restore the old handler when we're done.

Could someone who is seeing this crash please try out this patch?

Comment 16

[Thomas Leineweber]

I have applied the patch to the plain 1.2b source and it does not crash anymore
with debugging disabled and optimization on.

As I had only a sourcetree for the 1.2b release at hand (the compilation time 
would have been very long), I could only test with that release. I will do another
test with HEAD.

Comment 17

[Thomas Leineweber]

I have now checked the patch with the trunk. It does not crash anymore.

Comment 18

[Christopher Blizzard (:blizzard)]

Comment on attachment 103940 [details] [diff] [review]
patch

add a comment about why we're using XSetErrorHandler() instead of pop/push and
you've got an r=blizzard

Comment 19

[Brian Ryner (not reading)]

Attachment: patch #2

Add a comment as blizzard suggested.

Comment 20

[Brian Ryner (not reading)]

Comment on attachment 104031 [details] [diff] [review]
patch #2

carrying over r=blizzard

Comment 21

[jag (Peter Annema)]

Comment on attachment 104031 [details] [diff] [review]
patch #2

sr=jag

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 104031 [details] [diff] [review]
patch #2

a=dbaron for trunk checkin

Comment 23

[Brian Ryner (not reading)]

Just wanted to note that "#include <gmodule.h>" is bogus and I'm removing it.

Comment 24

[Brian Ryner (not reading)]

checked in.

Comment 25

[Kenneth Herron]

*** Bug 175989 has been marked as a duplicate of this bug. ***

Comment 26

[srikanth Koneru]

*** Bug 176383 has been marked as a duplicate of this bug. ***