96808 - Mozilla won't start on IRIX: Gdk alloc error

Status: VERIFIED INVALID

(SeaMonkey :: UI Design, defect, P3)

Description

[Henri Sivonen (:hsivonen)]

Build ID: can't see the ID, but i suppose it is something like 20010823xx.

Reproducible: Always.

Steps to reproduce:
1) Try to run Mozilla.

Actual results:
A huge black window that fills the entire screen appear and the disappears.
mzoilla exits with this error:
Gdk-ERROR **: BadAlloc (insufficient resources for operation)
  serial 439 error_code 11 request_code 53 minor_code 0
Expected results:
Expected Mozilla to run fine.

Additional information:
I have been able to run earlier (in the spring 2001) builds successfully on the
same set up. The problem does not occur with Solaris Sparc build 2001082322.

Comment 1

[Oliver Klee]

Marking as blocker.

Comment 2

[sairuh (rarely reading bugmail)]

my durn O2 is still having issues... akk or mcafee, either of you have access to
Irix to test this out? thx!

Comment 3

[Henri Sivonen (:hsivonen)]

Build 2001082622 runs.

Resolving as WFM.

Comment 4

[Nick Blievers]

I have seen this bug since 0.9.2 but have failed (so far) to track it down. 

Basically, what seems to happen is that the X server grows (and grows and 
grows) until you run out of swap space, and you see this GDK error. I find it 
most noticable when running on one machine and displaying on another (I use an
Indy w/ 64 MB RAM and 128MBs of swap for testing this.... and on choffman's 
browser buster generally get about half an hour before running out of virtual 
memory -- NOTE: this is with mozilla running on a different box, but displaying 
on the Indy).

We have spent a lot of time checking the sgi X server for leaks, and have only 
recently concluded that it is not an X server problem. Some odd bits and pieces 
that we have picked up so far:
   -Running Mozilla on Linux (x86 Linux binary) but displaying on IRIX shows 
this problem.
   -Running Mozilla on IRIX but displaying on Linux does NOT seem to show this 
problem (or at least the problem is nowhere near as bad).
   -Running Mozilla on IRIX but displaying on Solaris does seem to show this 
problem.
   -Displaying on pretty much anything else that we've tried (XFree86 for 
windows, XWin32 for Windows) doesn't seem to show this problem.

   -Running the DEBUG build of mozilla seems to improve the problem!?

Please note: all of these tests are somewhat subjective, as the X server memory 
usuage is continually in flux, and sometimes it is not obvious if there is a 
problem or not.

You can always simply increase the amount of swap space on the client system, 
or play with virtual swap space (I haven't tried this.... virtual virtual 
memory... just sounds scary to me!), but this is not a long term solution.
The more memory and swap you have, the less likely you are to see this problem.

Comment 5

[Paul Chen]

Uhh, can someone WITH an IRIX box take this one, please?

Comment 6

[Paul Chen]

Since I don't have an irix box, marking p3, critical, and mozilla1.1. Someone
with an irix box should take this one over

Comment 7

[Henri Sivonen (:hsivonen)]

For the record: The problem as originally reported turned out to be a problem at
my end. (WFM now.) The problem described by Nick Blievers is another issue.

Comment 8

[Nick Blievers]

Since this issue is different to the one the bug was originally opened for,
should I create a new bug? 
Anyway, this problem still occurs in 0.9.5, and in fact, is far more noticable due
to the (cool!) tabbed browsing feature.

Comment 9

[Chris McAfee]

we should close this and file a new bug.

Comment 10

[Henri Sivonen (:hsivonen)]

Resolving per previous comments.

Comment 11

[sairuh (rarely reading bugmail)]

mass verification of Invalid bugs: to find all bugspam pertaining to this,
set your search string to "MagaritaLuisaChascarilloAvoidsInvalidBugs".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. where relevant, do check that it's actually still a problem with ***recent
trunk builds*** on the all appropriate platform[s]

b. provide clear, compelling reasons why this bug should be considered a valid one.