52949 - Crash on simple JavaScript

Status: VERIFIED DUPLICATE of bug 52397

(Core :: Networking, defect, P3)

Description

[Bob Kanefsky]

Build id:  2000091304
Reproduced several times in a row.  Did not reboot Mac in between.

To try reproducing:
  1.  Save any state you might lose if your browser crashes.
  2.  Open the little JavaScript attachment.
  3.  Press OK on the alert box.

Comment 1

[Bob Kanefsky]

Attachment: MacsBug StdLog

Comment 2

[Bob Kanefsky]

Attachment: Test case (opening may crash browser)

Comment 3

[Bob Kanefsky]

Build id 2000091509 is the one the StdLog is from. 2000091304 also crashes.

It's 100% reproducible for me (on this machine, without rebooting),
but only with the original local copy of the file. When I open the
attachment I just put on the Bugzilla site, it works fine.

Comment 4

[Bob Kanefsky]

After a few times, I was forced to reboot my Mac with the button.
MacsBug started getting exceptions; even its rb command didn't work.
It's reproducible after booting.

To reproduce:
  Point at 09/16/00 16:52 attachment above.
  Get popup menu and select Save Link As...
  Type a filename, such as crash-mozilla-52949.html
  Open the file, e.g. by dragging it onto a Mozilla window.
  Click on OK.
  It should crash.

By the way, I could have sworn I saw PostEvaluateScript in the stack trace
from the "sc" command on the first crash, but when I reproduced it the first
time and saved the StdLog I posted, it didn't show up there.

Comment 5

[Jesse Ruderman]

Windows 98 - no crash on remote or local copy.

Comment 6

[Phil Schwartau]

Crashed on testcase using Mozilla tip build 2000-09-13 on Linux. 
Changing OS to "All". Will attach stack trace, which is almost
identical to the one I've just attached to bug 42624. 

Reassigning to Networking, as in the other bug -

Comment 7

[Phil Schwartau]

Attachment: Linux stack trace of crash -

Comment 8

[Phil Schwartau]

[SPAM] Changing OS and Platform; sorry -

Comment 9

[Bob Kanefsky]

Attachment: Another Mac stack trace, slightly different because it's via HTTP instead of file

Comment 10

[Darin Fisher]

Attachment: Stack dump (not from source of SEGV) that shows source of problem.

Comment 11

[Darin Fisher]

The stack dump (listed just above) shows the nsHTTPServerListener's
OnStopRequest() handler being called inside its OnDataAvailable()
handler.  The problem being that the OnStopRequest() handler free's
the mResponse and mChannel member variables, causing the SEGV in
the OnDataAvailable().  This problem is very similar to that
encountered in Bug 52734.

A possible fix (or perhaps it's just a hack) would be to delay the
NS_IF_RELEASE's at the end of the OnStopRequest() in the event that
we are within a call to OnDataAvailable().  Then we could take care
of the NS_IF_RELEASE's at the end of the OnDataAvailable() handler
instead.

Comment 12

[Darin Fisher]

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

Comment 13

[Tom Everingham]

verif. DUP

Comment 14

[Bob Kanefsky]

Test case now passes in 2000100608 on MacOS 9, even on local file.
Is it appropriate to leave as Verified Duplicate, or change to Verified Fixed?