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 dialogue: 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 problem.
did you send a talkback report back?
"did you send a talkback report back?" No, the crash didn't trigger Talkback. Helpful, neh?
Reporter, Is this reproducible in any way ? Otherwise, we might mark this bug INVALID.
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.
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.
Need a stacktrace or talkback id.
Severity: normal → critical
Keywords: crash, stackwanted
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.
The instruction at "0x642090db" referenced memory at "0xffffffff". The memory could not be "read". No Talkback again. How to make a stacktrace?
I had a look in the Microsoft Support Knowledge Base. Check out the following: http://support.microsoft.com/support/kb/articles/Q268/6/10.ASP - "WD97: "The Instruction at ... Referenced Memory at 0x00000000" When You Start Word with Hyperlink from Internet Explorer" http://support.microsoft.com/support/kb/articles/Q229/7/42.ASP - "WD97: Error Message After You Undo a Deletion of a Section Break" http://support.microsoft.com/support/kb/articles/Q264/8/64.ASP - "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 message. 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.
Oh, of course it's a compiler message. http://support.microsoft.com/support/kb/articles/Q196/7/55.ASP 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 ...
Using 20011008-trunk/WinNT - problem is still here: 0x642090db at 0x0070006a
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: asa → law
Component: Browser-General → QuickLaunch (AKA turbo mode)
QA Contact: doronr → gbush
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: TB36716462G TB36711589W TB36678735W
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, instead. 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
firstname.lastname@example.org, can you still reproduce this? can anyone?
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?
I didn't see this bug on my comp for long time.
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 help?
As I asked before, did anyone have a look at those talkbacks reported before in comment #14 ? TB36716462G TB36711589W TB36678735W Those were a pretty old build (0.9.5), but may provide at least a smidgeon of useful information for nailing this one ...
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 nomination.
David Gerard, >As I asked before, did anyone have a look at those talkbacks reported before >in comment #14 ? >TB36716462G >TB36711589W >TB36678735W 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 anything. 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. ***
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 typed."
17 years ago
Attachment #83548 - Attachment description: huang → huang's screen shot of the error dialog
<<how did you generate talkback submissions with this crash? Can you do it again?>> Not my talkbacks, but Daniel Lichtenberger's (email@example.com) - 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.
nsbeta1+/adt3 per Nav triage team.
Keywords: nsbeta1 → helpwanted, nsbeta1+
nsbeta1- per Nav team.
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
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.
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??
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 :-(
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.
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.
adding Dimitrios' stack, removing stackwanted kw Stack Signature nsBufferedInputStream::Fill 385f5701 Email Address firstname.lastname@example.org 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] WinMainCRTStartup() KERNEL32.DLL + 0x17d08 (0x77e97d08)
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]
*** This bug has been marked as a duplicate of 142847 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
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.
"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 :) ?
I don't think so. That patch doesn't seem to be the final one. Let's wait.
mass duplicate verifications . For filtering purposes, pls use keywd "massdupverification"
Status: RESOLVED → VERIFIED
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.