209013 - X_ChangeProperty BadAtom Browser crashes on inactive window when data is coming in (via proxy!?)

Status: RESOLVED EXPIRED

(Core Graveyard :: GFX: Gtk, defect)

Description

[Thijs]

User-Agent:       Mozilla/4.51C-ASML_1N06S [en] (X11; I; SunOS 5.8 sun4u)
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030530

When a page is loading via my http proxy address (on our local intranet this
does NOT happen!) and I move the cursor outside the browser window, the browser
crashes and shows the following text in my terminal window:

X Error of failed request:  BadAtom (invalid Atom parameter)
Major opcode of failed request:  18 (X_ChangeProperty)
Atom id in failed request:  0x0
Serial number of failed request:  82202
Current serial number in output stream:  82204


Reproducible: Always

Steps to Reproduce:
1. Setup sun solaris mozilla via proxy
2. Start browsing via http proxy (port 8080)
3. While data is coming in make browser window inactive (by moving the cursor
outside the browser window)

Actual Results:  
Crash

Expected Results:  
Continue browsing

Comment 1

[Thijs]

Kernel version: SunOS 5.8 Generic 108528-13 December 2001

Comment 2

[Thijs]

This _only_ happens when data is coming from the http proxy _and_ I move the
mouse cursor from the browser window to my NTRIGUE (Citrix 'Unix Integration
Service').

So moving the mouse cursor from the browser window to a non ntrigue window does
_not_ give the described problem/crash.

..hope this helps..

Comment 3

[timeless]

.

Comment 4

[Christopher Blizzard (:blizzard)]

???

I have no idea what might be causing this.  However, the mention of Citrix makes
my spider sense tingle.

Comment 5

[Damien Chrisment]

This bug seems to be the same as http://bugzilla.mozilla.org/show_bug.cgi?id=97090

Comment 6

[L.Drolez]

It seems that if you use OpenWindows instead of CDE, the bug is not triggered.

Anyway, Mozilla should behave properly when it receives the XError and not
segfault...

Comment 7

[Damien Chrisment]

Attachment: workaround with a rewrite of XChangeProperty (.so + source)

We (Ludovic Drolez and myself) have done tests on this bug.

This happens:
     - when proxy is used under Mozilla
     - with gtk 1.2 or 2.0
     - Citrix UIS 1.0b (Ntrigue, X11 protocol)
     - with CDE
     - when the Windows server CPU activity is high

This doesn't happen:
     - with Citrix ICA client
     - after a reboot of the Windows server
     - when Mozilla runs on SGI (Irix) and the display is exported 
       on the Solaris station

Analyse:

When the Windows server is heavily used, Ntrigue sends strange packets
to the X11 server which dispatche them to the other applications. 
X11R4 prints its error and Mozilla exit (no core dump). As this doesn't 
happen when Mozilla is run from an SGI Irix, its perhaps that it's X server 
see the strange packets and filtered them.
A workaround to this is to rewrite XChangeProperty function and load the 
new library with LD_PRELOAD. See the attached file called xcp.tar.gz for 
details. This solution works for us.
Another (better) solution would be that Mozilla behave properly when it
receives 
the XError...

Comment 8

[Christopher Blizzard (:blizzard)]

Boy, that's...uhh...brute force.

Comment 9

[Damien Chrisment]

(In reply to comment #8)
> Boy, that's...uhh...brute force.

Yes but it works pretty well... ;-)

Comment 10

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 11

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.