Crash on quit: 'The instruction at "0x642090db" referenced memory at "0x73736369".' [@nsBufferedInputStream::Fill]




17 years ago
7 years ago


(Reporter: fun, Assigned: hyatt)


({crash, helpwanted})

Windows NT
crash, helpwanted

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt3], crash signature)


(1 attachment)



17 years ago
From Bugzilla Helper:
BuildID:    2001092503

Ran Mozilla all day, eventually shut it down to go home. Right-click on turbo 
icon, go to 'Exit Mozilla'. Took a few seconds, then Windows gave the following 

The instruction at "0x642090db" referenced memory at "0x73736369". The
memory could not be "read".

Click on OK to terminate the application

I've never seen this before ... not sure what to do to reproduce it :-)

This bug report probably wouldn't be useful unless someone else has the same

Comment 1

17 years ago
did you send a talkback report back?

Comment 2

17 years ago
"did you send a talkback report back?"

No, the crash didn't trigger Talkback. Helpful, neh?

Comment 3

17 years ago

Is this reproducible in any way ?

Otherwise, we might mark this bug INVALID.

Comment 4

17 years ago
I saw something same on my WinNT4 with build 2001092403, but I can't simply
reproduce it on 2001092703. In my case Talkback didn't start too.

Comment 5

17 years ago
My Mozilla (2001092703-trunk) showed me several minutes ago after repeating same
as reporter this:

The instruction at "0x642039de" referenced memory at "0x00000014". The memory
could not be "read". Click on OK to terminate the application.

Talkback didn't start again.

Comment 6

17 years ago
Need a stacktrace or talkback id.
Severity: normal → critical
Keywords: crash, stackwanted

Comment 7

17 years ago
Just happened again with build 2001093008:

The instruction at "0x642090db" referenced memory at "0x000001f4". The memory could
not be "read".

No Talkback again.

Note that it's a different build, but the same instruction address. This is
Windows NT4sp6a on a Compaq Armada M300 notebook. PIII-600, 320MB memory.

I'm now using build 2001100203, but I have 2001093008 to hand (for now) if needed.

Comment 8

17 years ago
The instruction at "0x642090db" referenced memory at "0xffffffff". The memory
could not be "read". No Talkback again.

How to make a stacktrace?


Comment 9

17 years ago
I had a look in the Microsoft Support Knowledge Base. Check out the following: - "WD97: "The
Instruction at ... Referenced Memory at 0x00000000" When You Start Word with
Hyperlink from Internet Explorer" - "WD97: Error
Message After You Undo a Deletion of a Section Break" - "XL97: Excel
Quits Unexpectedly When You Paste Array Formulas into Merged Cells"

These are the only entries in the entire MSKB I could find with our error

I do have Office 97, though the only component running at the times of my crashes
was the Office toolbar - no preload (OSA.EXE), no Find Fast, etc.

At a guess, the error message looks like something the compiler (presumably they
use VC++ internally) leaves in the app in case of a reference to something you
shouldn't reference. I could be wrong, of course.

Comment 10

17 years ago
Oh, of course it's a compiler message.

Presumably getting something useful out of this would require a debug build
and my own copy of VC++, which of course I don't have, not being a developer ...

Comment 11

17 years ago
Using 20011008-trunk/WinNT - problem is still here:
0x642090db at 0x0070006a

Comment 12

17 years ago
Marking NEW.
Ever confirmed: true

Comment 13

17 years ago
Assignee: asa → law
Component: Browser-General → QuickLaunch (AKA turbo mode)
QA Contact: doronr → gbush

Comment 14

17 years ago
I get the same error message almost every time I close a browser tab in 0.9.5.
The referenced memory adress seems to be always 0x00000000 (so I'm not sure this
is really related to this bug). I was asked on mozillaZine to file the talkback
IDs under this bug, so here we go:


Comment 15

17 years ago
Almost every single Win32 crash will produce "The instruction at ..." type error
 messages.  I'm not sure the tabbed browser report is the same.

It could be that using turbo mode simply causes Mozilla to continue to run for
much longer, thus exposing a general problem.  Can somebody who sees this on a
regular basis try turning off Quick Launch and just leave a browser window open,

If a similar crash occurs when you finally close the last window at the end of
the day, then we'll know a bit more.

Setting target milestone out since we can't readily reproduce and reports don't
seem to be all that common.
Target Milestone: --- → mozilla1.0.1

Comment 16

17 years ago, can you still reproduce this? can anyone?

Comment 17

17 years ago
I am not presently using Windows, so haven't seen it, no ... it's the sort of
error that, er, pops up occasionally :-) I never did get anything to produce
it reliably.

(And no, I don't see it or anything like it on Debian :-)

No result from those three Talkbacks from before?

Comment 18

17 years ago
I didn't see this bug on my comp for long time.

Comment 19

17 years ago
w00t, just got it again, second time I ran 2002042006/1.0.0 on Win2k:

The instruction at "0x00235d9a" referenced memory at "0x88002301". The memory
could not be "read".

This is on Win2k, Athlon 1700+, 512MB memory. I had just /quit Chatzilla with
no other windows open, so the browser exited. Not in turbo (quicklaunch) mode.

No talkback produced, of course ... how annoying.

Crikey. Am I one of the very few this happens to? The only difference could be
my profile ... I created a new profile in 0.9.9-milestone, then installed this
build from the talkback .zip ... Would attaching a zip of my profile conceivably

Comment 20

17 years ago
As I asked before, did anyone have a look at those talkbacks reported before
in comment #14 ?


Those were a pretty old build (0.9.5), but may provide at least a smidgeon of
useful information for nailing this one ...

Comment 21

17 years ago
adding karen.  It looks like 144218 could be a dup of this and if it is then it
looks like Karen and Seth are seeing this on recent builds so adding nsbeta1
Keywords: nsbeta1
David Gerard,

>As I asked before, did anyone have a look at those talkbacks reported before
>in comment #14 ?

I looked those up, and they contained no data.  I'm not sure if that's because
they are old (0.9.5) or because the crash happens so late that we don't send

how did you generate talkback submissions with this crash?  Can you do it again?
*** Bug 144218 has been marked as a duplicate of this bug. ***
Created attachment 83548 [details]
huang's screen shot of the error dialog
It looks like those old talkback reports have been deleted:

"Incident ID #36716462 cannot be found. 
The incident you are looking for has either been deleted from the Talkback
database, or never existed in the first place. Please verify the number you have

Attachment #83548 - Attachment description: huang → huang's screen shot of the error dialog

Comment 26

17 years ago
<<how did you generate talkback submissions with this crash?  Can you do it

Not my talkbacks, but Daniel Lichtenberger's ( -
see comment 14. He is not on the cc: for this bug, however.

I have never managed to get a talkback out of this bug.

<<It looks like those old talkback reports have been deleted:>>

It's a pity no-one looked at the time, or in February.

Comment 27

17 years ago
nsbeta1+/adt3 per Nav triage team.
Keywords: nsbeta1 → helpwanted, nsbeta1+
Whiteboard: [adt3]

Comment 28

17 years ago
nsbeta1- per Nav team.
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla1.0.1 → mozilla1.1alpha

Comment 29

17 years ago
I am *not* using quicklaunch. When I shutdown Mozilla and start it again shortly
after (it's very easy to do this, trust me), I get an identical message. After a
lot of searching in Bugzilla, I found only this bug (all the other crash and
topcrash bugs are unrelated). If this one covers non-turbo configurations, then
it's priority should be raised and the component should be changed. Mozilla 1.0
cannot be released with a bug like this. Seeing it on RC2 and on trunk
(20020520), Win2K.
I am saying all the above because in my user experience so far I have
encountered numerous occasions of this bug. If there's already another bug id
for what I described, sorry for the spam.

Comment 30

17 years ago
I agree, this is not turbo or QuickLaunch related.  

I can reproduce easily after disabling QuickLaunch.  Start up Mozilla (I have 3
profiles so Profile Manager comes up), choose profile and launch- file/exit and
relaunch immediately.
you will see the 'instruction at xxxx reference memory at xxxx, memory could not
be read' error.

I am not sure how often users would close and relaunch in such fast succession??

Comment 31

17 years ago
While I was knowing nothing about this bug report, I had encountered this bug
many times. Perhaps because I start Mozilla from the "quicklaunch" section of
Windows taskbar (where only a single click is needed). Am I too fast, too
nervous. I don't know. But, imho, if the frequency of appearance of this bug is
more than 1 per week for the average user, then it's very important and it
should be fixed before a major product release.
The sad thing is that I tried hard to trigger a talkback, to no avail :-(

Comment 32

17 years ago
I too have this problem .
To reproduce it.
Open an instance of mozilla while another is shutting down.

i.e, after a long browsing session, close mozilla, try opening it immediately
(while the other session is in memory) by clicking on the shortcut. This is more
easy to notice on slower machines with lesser ram.

I am using win2k.
I Never use Turbo mode.

Comment 33

17 years ago
Well, at least I did triggered two talkbacks, using 2002052508. Unfortunately, I
erased the /bin directory just after the crash (silly me), so I cannot directly
provide you the incident IDs. But you can very easily identify those talkbacks
because they contain my email address and some comments about the bug. Please
take a look. I cannot recall  the very details of the condition during the above
two crashes but chances are we have exactly what we want.

Comment 34

17 years ago
adding Dimitrios' stack, removing stackwanted kw

Stack Signature  nsBufferedInputStream::Fill 385f5701
Email Address
Product ID MozillaTrunk
Build ID 2002052508
Trigger Time 2002-05-25 15:06:38
Platform Win32
Operating System Windows NT 5.0 build 2195
Module necko.dll
URL visited
User Comments second occurence of the infamous "crash on quit bug".
Trigger Reason Access violation
Source File Name nsBufferedStreams.cpp
Trigger Line No. 347
Stack Trace
nsBufferedInputStream::Fill [nsBufferedStreams.cpp, line 347]
nsBufferedInputStream::Read [nsBufferedStreams.cpp, line 286]
nsFastLoadFileReader::Read [nsFastLoadFile.cpp, line 569]
nsBinaryInputStream::Read32 [nsBinaryStream.cpp, line 361]
nsXULPrototypeElement::Deserialize [nsXULElement.cpp, line 5053]
nsXULPrototypeDocument::Read [nsXULPrototypeDocument.cpp, line 355]
nsXULPrototypeCache::GetPrototype [nsXULPrototypeCache.cpp, line 274]
nsChromeProtocolHandler::NewChannel [nsChromeProtocolHandler.cpp, line 627]
nsIOService::NewChannelFromURI [nsIOService.cpp, line 778]
NS_NewChannel [../../dist/include/necko\nsNetUtil.h, line 162]
nsDocShell::DoURILoad [nsDocShell.cpp, line 4843]
nsDocShell::InternalLoad [nsDocShell.cpp, line 4743]
nsDocShell::LoadURI [nsDocShell.cpp, line 667]
nsWindowWatcher::OpenWindowJS [nsWindowWatcher.cpp, line 694]
nsWindowWatcher::OpenWindow [nsWindowWatcher.cpp, line 453]
OpenWindow [nsAppRunner.cpp, line 409]
OpenWindow [nsAppRunner.cpp, line 393]
LaunchApplicationWithArgs [nsAppRunner.cpp, line 637]
HandleArbitraryStartup [nsAppRunner.cpp, line 775]
DoCommandLines [nsAppRunner.cpp, line 797]
main1 [nsAppRunner.cpp, line 1432]
main [nsAppRunner.cpp, line 1808]
WinMain [nsAppRunner.cpp, line 1826]
KERNEL32.DLL + 0x17d08 (0x77e97d08) 
Keywords: stackwanted

Comment 35

17 years ago
Assignee: law → hyatt
Component: QuickLaunch (AKA turbo mode) → XP Toolkit/Widgets: XUL
QA Contact: gbush → shrir
Summary: Crash on quit: "The instruction at "0x642090db" referenced memory at "0x73736369"." → Crash on quit: 'The instruction at "0x642090db" referenced memory at "0x73736369".' [@nsBufferedInputStream::Fill]

Comment 36

17 years ago

*** This bug has been marked as a duplicate of 142847 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 37

17 years ago
After applying the patch for bug 142847 into a relatively recent trunk tarball,
no crash on quit anymore. With this patch, you can't start Mozilla quickly after
shutting it down. It simply doesn't start (hourglass appears for a moment, then
diasppears) unless a short time interval has passed before trying to start it
again. I 'm not sure if that was intended but it's definitely better than before.

Comment 38

17 years ago
"you can't start Mozilla quickly after shutting it down. It simply doesn't start
(hourglass appears for a moment, then diasppears) unless a short time interval
has passed before trying to start it again."

A new bug :) ?

Comment 39

17 years ago
I don't think so. That patch doesn't seem to be the final one. Let's wait.

Comment 40

16 years ago
mass duplicate verifications . For filtering purposes, pls use keywd



10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
Crash Signature: [@nsBufferedInputStream::Fill]
You need to log in before you can comment on or make changes to this bug.