Bug 59532

Note: I would have preferred to file this against all three of the XFree86,
mozilla, and galeon packages, but I do not see any way to do so.

Description of Problem:
While doing normal browsing on several occasions I was unpleasantly surprised to
find my system swap-thrashing itself to death after trying to open Mozilla.

I took a while trying to pare down the exact problem.  Here are the results:

Issue occurs when Galeon is already running, and you try to start mozilla. 
Mozilla's browser window appears to open "inside" a Galeon window; i.e., you can
see the usual mozilla address bar, buttons, etc. but it is _within_ a larger
Galeon window.  Very bizarre.

This strange window usually (maybe always) opens to the following URL, no matter
what you are trying to do:

chrome://navigator/content/navigator.xul

Anyway, what happens next, is either a _huge_ gray window will open and smother
the whole screen, and the system will start thrashing uncontrollably/unescapably
(you can't Ctrl-Alt-BS, switch to a VC, can't do anything at all.. have to reset
the comp), or a small mozilla window will open.  In the latter case, if you hit
"Tabs/Customize Sidebar" on "My Sidebar" you will still end up with the huge
gray window.  And you will still get screwed.


So while trying to figure out what was going wrong, I logged into a VC before
causing the thrash.  If I am quick enough, I can switch to that console before
the system bogs down, and I can use top, ps, etc. on the console.  Doing so
revealed that swap was getting drained down to nothing, then getting freed
again, then repeating over and over.  The cause of this appears to be the X
process consuming massive amounts of memory (at least 659M, whereas I have 256M
RAM and 512M swap).

By using kill -9 against the X process, I was able to stabilize the system and
log into X again.

To work around the problem, I changed gdm.conf to use a shell wrapper for X to
apply some resource limits on the X process:

[servers]
0=/usr/local/bin/X.sh

$ cat /usr/local/bin/X.sh 
#!/bin/sh
ulimit -v 500000
exec /usr/bin/X11/X -nolisten tcp "$@"


This seems to be effective at keeping X from going out of control; the "huge
gray window" still opens up, but X does not hog memory, the system does not
thrash, and those errant windows can be closed.  (I can slide it over and there
is the usual set of window manager decorations on it, which still function.  I
suspect that without resource limits, this window may be trying to open to
infinite dimensions, but of course I cannot confirm that because the system
becomes unusable.)

The next step was to determine why some pages, while loaded in Galeon, would
cause this to happen, while other pages would not.  e.g., if Galeon is currently
at http://cr.yp.to/, mozilla will open normally in its own window and process. 
If Galeon is at http://www.netbsd.org/, the above problem will occur, and no
processes matching 'moz' (in ps output) will existat all.

The short version of that story is: it appears to be related to "<select>" tags
on sites.  I copied the html of www.netbsd.org and put it on my own site, and
edited different parts of it out until I found out what fixed it.  When I
removed the selector box from the site, the problem no longer occurred.


Version-Release number of selected component (if applicable):
kernel-2.4.9-21
XFree86-4.1.0-15
mozilla-0.9.2.1-2
galeon-0.11.3-2


Steps to Reproduce:
1. Start Galeon
2. Go to http://www.netbsd.org/ in that Galeon process
3. Start mozilla


Actual Results:
System becomes useless due to swap thrashing, X memory consumption.
Also the requested browser never opens.


Expected Results:
Browser will actually open in its own process, and X will not eat your system
alive..


Additional Information:
Note that the /usr/bin/mozilla shell wrapper does not appear to be at fault. 
This can also be reproduced on the command line like so:

/usr/lib/mozilla/mozilla-bin -remote 'openurl(about:blank,new-window)'

Also, to make sure it wasn't anything wrong with my configuration, I added a new
user to my machine and was able to reproduce the problem under that account,
with no ~/.mozilla or ~/.galeon or whatever present before-hand.