217183 - Mozilla crashes frequently when SETI@home3.08 runs [@ MSVCRT.DLL - js_Execute ]

Status: RESOLVED EXPIRED

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

Description

[Ralf Hagen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.4) Gecko/20030624

Some time ago, I installed SETI@home 3.08 <http://setiathome.ssl.berkeley.edu/>
on my machine.
If I am working on it and forgot to minimize seti, it can be anticipated that
the computer runs slowly.
However, when starting up Mozilla from Quickstart, it frequently crashes; or
ceases to work until I minimize seti@home. The operation of Mozilla then
freezes; I can't switch to another Mozilla window (say, from Messenger to
Navigator). Other Windows work fine.
If I take seti@home to the foreground and minimize it, Mozilla at once resumes
working.

Has anybody had similar experiences using Mozilla and seti@home?

Reproducible: Always

Steps to Reproduce:
1. Running seti@home non-minimized (it is actually working) and starting Mozilla
from Quickstart
2. Writing Mails, eg, while running seti@home
Actual Results:  
1. Mozilla crashes
2. Mozilla may freeze for as long as seti@home is not minimized, while other
windows/processes do still work.

Expected Results:  
1. No crash
2. Mozilla should still work (if slower)

Comment 1

[Matthias Versen [:Matti]]

Do you use the text cliewnt or the screensaver ?

wfm with win2k and Seti3.03 textclient (running in the background as service).
Are you sure that your CPU is not overheated (do you use a AMD system) ?
That's usually the cause for something like this because seti use all free CPU
power and the cpu gets very hot.

Comment 2

[Bill Mason]

I run Mozilla and Seti screensaver side by side all day, no crashes.  WinXP.

Comment 3

[Adam Hauner]

WFM with SETI text-client 3.03 with trunk nightbuilds/W2K.

Comment 4

[Ralf Hagen]

Yes, I do have an AMD system. I just got ASUSprobe up to monitor its heat.
Thanks for the suggestion, should have thought of that.
I am using the screensaver variant.
In 24h, I will write as to which temperature the CPU climbs.
However, the second I minimize seti, everything resumes working at once. I also
observed that other network utilities tend to freeze, also (eMule); however,
only Mozilla outright crashes.

Comment 5

[Ralf Hagen]

Recorded heat on my system. No, heat is well into the normal parameters.
Nevertheless, Mozilla tends to crash, even when the screensaver is stopped.
Something strange going on... perhaps my talkback data will give a clue.

Comment 6

[Matthias Versen [:Matti]]

TB Id# ?

Comment 7

[Ralf Hagen]

Talkback ID#s:
TB23251613Y
TB23133636K
TB23045199Z
TB23045128Y
TB23024604K
TB23024518Q
TB22944657E
TB22872649K
This bug also seems to be connected with Quickstart; when Quickstart is no
longer running and Mozilla starts up "from scratch" every time, everything is fine.

Comment 8

[Simon Montagu :smontagu]

Stack from incident TB23251613Y:
MSVCRT.DLL + 0x1a66 (0x78001a66)
js_Execute [d:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 1057]
JS_ExecuteScript [d:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3375]
nsJSContext::ExecuteScript
[d:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 914]
nsXULDocument::ExecuteScript
[d:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 3465]
nsXULDocument::OnStreamComplete
[d:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 3375]
nsStreamLoader::OnStopRequest
[d:/builds/seamonkey/mozilla/netwerk/base/src/nsStreamLoader.cpp, line 144]
nsJARChannel::OnStopRequest
[d:/builds/seamonkey/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 653]
nsCOMPtr_base::assign_with_AddRef
[d:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 71]
nsInputStreamPump::OnStateStop
[d:/builds/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 484]
nsInputStreamPump::OnInputStreamReady
[d:/builds/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 325]
nsInputStreamReadyEvent::EventHandler
[d:/builds/seamonkey/mozilla/xpcom/io/nsStreamUtils.cpp, line 117]
PL_HandleEvent [d:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 660]
PL_ProcessPendingEvents [d:/builds/seamonkey/mozilla/xpcom/threads/plevent.c,
line 596]
_md_EventReceiverProc [d:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line
1396]
nsAppShellService::Run
[d:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 479]
main1 [d:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1284]
main [d:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1650]
WinMain [d:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1672]
WinMainCRTStartup()
KERNEL32.DLL + 0x87f5 (0x77e787f5) 

Comment 9

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Try running memtest86... it's possible that running SETI brings out memory
problems that your system has.

Comment 10

[Ralf Hagen]

memtest86 happens regularly, runs for about 24 hours (which has to be, with 1GB
RAM), and does not find any problems.
This seems not to be it.

Comment 11

[Adam Hauner]

Ralf Hagen: Could you still reproduce this bug with Mozilla 1.7.6 or Mozilla 1.8
beta 1 or actual nightbuild?

Comment 12

[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 13

[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.