171394 - Lock up with high CPU usage on binary file download

Status: VERIFIED DUPLICATE of bug 187291

(SeaMonkey :: Download & File Handling, defect)

Description

[Tristan Miller]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910

Whenever I try to open or save a file that Mozilla can't view by itself, CPU
usage soars to near 100% and the program locks up.  I need to killall
mozilla-bin to regain control of the system.  This problem just started today,
after several days of relatively problem-free use of Mozilla 1.2a.  I haven't
changed my preferences lately, so I'm not sure why this would start happening
now.  Deleting my prefs.js file fixes this behaviour.  I can't see anything in
the original prefs.js bug which might cause this behaviour, so I will attach it
to this report.

I tried to reproduce the problem on a nightly build, but the installer won't run
for me. (Not sure if that's worth filing another bug report.)

Reproducible: Always

Steps to Reproduce:
1. Use the attached prefs.js file.
2. Go to any page which links to a file Mozilla must download the file or open
with a helper application.
3. Click on the link.  If Mozilla asks you whether to open with a helper
application or to save, choose either one.  If the file picker dialog pops up,
choose a location to save the file.  Just do whatever it takes to make it start
downloading the file. :)

Actual Results:  
Download window pops up, but Mozilla locks up immediately afterwards:

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
11970 psy       20   0 35944  34M 15764 R    96.5 13.6   0:26 mozilla-bin


Expected Results:  
Should have nicely downloaded the file (and possibly opened with a helper
application, if set).

May be related to bug 91232, except that this bug only occurs when the attached
prefs.js file is used.  Let me know if you need further attachments.

Comment 1

[Tristan Miller]

Attachment: prefs.js which causes the noted behaviour

Comment 2

[Tristan Miller]

I narrowed it down to the one line in prefs.js that causes the bug:
user_pref("browser.downloadmanager.behavior", 1);

Removing this line fixes everything.  Possible bug in Download Manager, then?

Comment 3

[R.K.Aa.]

Is the theme you use compatible with the version of Mozilla?
Use a prefs.js WITH the line user_pref("browser.downloadmanager.behavior", 1);

If you then rename the file XUL.mfasl in your profile dir (mozilla not running
at the time) Does the bug still trigger?

Comment 4

[Tristan Miller]

I no longer have the same version of Mozilla used to file the original bug
report.  I tried again with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a)
Gecko/20021212 and the bug did not trigger.  If this matter is still worth
pursuing, let me know and I'll be glad to render further assistance.

Comment 5

[R.K.Aa.]

The pref set to "1" should open a progress dialog.
Since it didn't open, but instead locked up, i suspect this is in effect a
duplicate of bug 169777. 

The same sympthoms you describe were reported in bug 187291 and bug 187705.
In those cases deleting XUL.mfl helped. Resolving as dup of bug 187291 for now.

*** This bug has been marked as a duplicate of 187291 ***

Comment 6

[Daniel Wang]

v