22672 - Quit on unmapped memory exception while loading page

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[A. Karl Kornel]

While attempting to access the link above from Mozilla's default home page, the
browser fails with an "Unmapped Memory Exception" error, breaking into MacsBug.
I pulled an StdLog on it and forced quit, which was successful.

Attempted to run this a second time, but resulted in the same error as above.  I
pulled another StdLog.

Attempted to run Mozilla, go to a web page (yahoo main page), and click on the
"Reference" link.  Everything came up properly, except for some rendering
problems (URL: http://www.yahoo.com/r/rf).

Attempted, for a third time, to go to the link specified above via the Mozilla
home page.  Closed the window showing the Yahoo page, and, WITHOUT quitting,
opened a new window.  Home page was brought up, and I clicked on the link.  The
same error came up for a third time.

Notes:
 1) Four files are attatched.  Three of them are the StdLog reports for the
three crashes.  The fourth is an Apple System Profiler report.
 2) This all occurred on build 19992111, Milestone 12, apprunner 5.0m12 Gecko
 3) Before clicking on the 'fatal' link, the browser window was re-sized, and
the home page (which was still showing) was successfully

Comment 1

[A. Karl Kornel]

Attachment: MacsBug StdLog report for crash 1

Comment 2

[A. Karl Kornel]

Attachment: MacsBug StdLog report for crash 2

Comment 3

[A. Karl Kornel]

Attachment: MacsBug StdLog report for crash 3

Comment 4

[A. Karl Kornel]

Attachment: Apple System Profiler Report in text form

Comment 5

[A. Karl Kornel]

Attachment: Same ASP report, but in easier-to-read (mac only) form.

Comment 6

[A. Karl Kornel]

Sory, but the text files have some extraneous computer data (Mac resource fork
info).  Just ignore it

Comment 7

[Michael Lowe]

networking?

Comment 8

[A. Karl Kornel]

Maybe, but it could also be a memory error.  What would something try to lock?

Possibly a process, memory, an internet socket?  Something (hopefully) worth

fixing by bet

Comment 9

[A. Karl Kornel]

Tried it again just now using the same procedure as before and the same apps
running, but no crash.

I tried once more, but made some small changes.  First, I made sure the window
was resized so the link took up two lines in the table cell, instead of one.
Secondly, I made sure that I clicked on the link while the page was still
loading.  Then a crash did come up!  I pulled an StdLog, which I am attatching.
It looks like the same error came up.  This is crash 4

I tried once again.  This time, I waited until everything was loaded.  I only
resized the window.  There was no crash, so the fact that I'm not waiting for
the home page to completely load must be the problem.  It certainly seems like a
networking problem.

To make sure that the bug wasn't restricted to that single page.  I did the
following.  Ignoring the window size, I typed in the address for the home page.
Before it finished loading, I pasted the address for the Yahoo! home page into
the URL space.  I then had it go to this new URL before the home page finished
loading.  As expected, I got the same crash.  This is crash 5, and I'm including
the StdLog for it, as well ( redundant, aren't I? 8-) ).

Notes:
 The 'page'/'home page' is the default Mozilla home page at
<http://www.mozilla.org/projects/seamonkey/release-notes/m12.html>.
 The 'link' is a link labelled "General Browser Issues" leading the the URL
listed as the problem URL in this bug file.
 The garbage text (resource fork info) shouldn't be in the 2 new StdLog f

Comment 10

[A. Karl Kornel]

Attachment: MacsBug StdLog report for crash 4

Comment 11

[A. Karl Kornel]

Attachment: MacsBug StdLog report for crash 5

Comment 12

[Gagan]

adding gordon on cc. list

Comment 13

[gordon]

This looks similar to a couple of other bugs I have.  I think listener object
passed to the DNS service may be going away before the lookup completes.  I'll
take this, and work it out with Rick.

Comment 14

[gordon]

We weren't ref counting the nsDNSListener that was passed into the DNS lookup,
which could cause a crash if it had been deallocated before the lookup completed.
I made the mListener field of nsDNSLookup a COMPtr, and no longer crash this way.

Comment 15

[Blake Ross]

*spam* changing qa contact from [e-mail] to me ([e-mail]) 
on 121 open or resolved (but not verified) bugs.  sorry for the spam everybody, 
but most of these bugs would just remain dormant and not checked by QA 
otherwise.  I'm not sure how so many bugs have nobody as their QA contact, but 
I suspect this is the fault of some sort of bugzilla corruption that happened 
at some point (most of these bugs are in the 20000-26000 range, and I don't see 
where in the activity log that QA contact explicitly changed to 
[e-mail])

Anyways, sorry again for spam.  If you really get annoyed, I'm usually 
available in #mozilla on IRC for torture.

Comment 16

[Blake Ross]

QA assigning to tever to verify

Comment 17

[Tom Everingham]

verified:
Mac os8.6  2001010209