Closed Bug 17572 Opened 25 years ago Closed 25 years ago

[DOGFOOD] crash trying to go back and forward

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED DUPLICATE of bug 18798

People

(Reporter: warrensomebody, Assigned: sdagley)

Details

(Whiteboard: [PDT+] 12/03)

Clicking the go back, go forward buttons repeatedly caused this crash (I was on the bugzilla query page): nsMenuDismissalListener::Rollup(nsMenuDismissalListener * const 0x02c0ec34) line 114 + 12 bytes nsWindow::WindowProc(HWND__ * 0x00580b2e, unsigned int 0x00000201, unsigned int 0x00000001, long 0x00420027) line 535 USER32! 77e71820() nsCOMPtr<nsIJSScriptObject>::assign_with_QueryInterface(nsISupports *, const nsID &, unsigned int *) line 642 + 39 bytes Sorry I don't have more info, but when it was crashed, cut & paste wouldn't work in the debugger! Must have locked up something about Windows.
Assignee: trudelle → saari
Target Milestone: M13
reassigning to saari, due to menu stuff on the stack.
Whiteboard: [PDT+]
Putting on PDT+ radar.
mass-moving all m13 bugs to m14
Target Milestone: M14 → M12
Moving this one to M12
*** Bug 17932 has been marked as a duplicate of this bug. ***
This seems to be a major stability problem, can we get this on M11?
We'll live this at M12 for now, as it's questionable how reproducible this is.
Severity: normal → critical
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
I'm going to need some better test cases or a another repro. This stack doesn't mean much to me, and I cannot repro the problem on my machine.
QA Contact: claudius → elig
QA Assigning to self for verification.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Hey, Saari --- I can reproduce this in about 20 seconds on the 1999111108 Win32 build on NT 4 just rapidly paging back and forward between www.mozilla.org and www.mozillazine.org. If it would help, I'd be happy to reproduce this for you in person at your convenience. See ya.
Cool, I'll come by and take a look at your convience. However... this is not a dogfood crash by my book. It isn't preventing functionality, unless you enjoy trying to give yourself RSI by clicking back and forward.
Nay, saari, at _your_ convenience. I insist. ;) [but, seriously, any time, just drop by.]
Whiteboard: [PDT+] → [PDT+] 11/26
Assignee: saari → sdagley
Status: REOPENED → NEW
reassigning to sdagley. Steve, please update the estimated completion date in the whiteboard.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] 11/26 → [PDT+] 12/03
Moved date to 12/03 as a WAG since I'm on vacation and for damn sure don't have a Winders build with me to look at
elig and I just looked at this on his Windows test machine and it doesn't seem to be happening now. He will do some more testing to see if he can reproduce it and narrow down a test case.
OS: Windows NT → All
Hardware: PC → All
[Correcting Platform/OS to 'All'; can reproduce in 3 clicks on today's Mac OS build. Win32 requires a lot more clicks.]
I haven't been able to reproduce this on my G3/400 with a debug build. I have noticed that if I load 3 or 4 pages to populate the history and then rapidly select back and forward I will lose some of the pages. This would lead me to suspect something in the history code. Who's working on that so we can ask them for comments?
radha is doing session history, there is a known problem where if a page doesn't load fully, it doesn't get put into the session history
the problem I'm seeing is that the pages _are_ in the session history when I start to bang on back/forward and then they disappear. My thinking is this disappearance is related to the crashing some people are seeing.
using this morning's optimized build, I'm still seeing the crash on Mac. I'd prefer to just show it to you, or I could refine the reproduction steps if you'd like. (came by your cube, but no dagley was in sight.)
I'm not disputing that on some systems a crash occurs. I'm simply stating that my debug build on my system doesn't crash but it does display a problem with session history that may be related to the crash. I'm hoping radha will comment on this since she owns session history (thanks for the pointer paulmac)
this may be a dupe of bug #18798 Eli, please take a look at the stack report in that bug and compare to what you're seeing in this report to see if this is the case
Grr, trying this again, not using Mozilla... ---- I believe that this is a duplicate. The stack signature of the crash is in the same location as 18798. But, they're both different from the stack crawl snippet in this bug; I wonder if it's fixed, and the bug I reproduced with identical symptoms is a different bug? Steve, please mark as duplicate if you concur: PowerPC illegal instruction at 039718D4 Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 0DA3E9D4 04520040 PPC 0DA3BB8C main+00114 0451FFC0 PPC 0DA3B65C main1(int, char**)+005D0 0451FED0 PPC 0B55CD50 nsAppShellService::Run()+00018 0451FE90 PPC 0B52BFE0 nsAppShell::Run()+00038 0451FE10 PPC 0B52C728 nsMacMessagePump::DoMessagePump()+0003C 0451FDC0 PPC 0B52C9FC nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00174 0451FD70 PPC 0DA7E874 Repeater::DoRepeaters(const EventRecord&)+00030 0451FD30 PPC 0B50ED10 nsMacNSPREventQueueHandler::RepeatAction(const EventRecord&)+000 20 0451FCF0 PPC 0C533D98 nsEventQueueServiceImpl::ProcessEvents()+00064 0451FCB0 PPC 0C547274 nsEventQueueImpl::ProcessPendingEvents()+00018 0451FC70 PPC 0D66B0AC PL_ProcessPendingEvents+0007C 0451FC20 PPC 0D66B148 PL_HandleEvent+00028 0451FBE0 PPC 0B887CCC nsStreamListenerEvent::HandlePLEvent(PLEvent*)+87CCC 0451FB90 PPC 0B888E58 nsOnDataAvailableEvent::HandleEvent()+88E58 0451FB40 PPC 0C373C50 nsHTTPResponseListener::OnDataAvailable(nsIChannel*, nsISupports *, nsIInputStream*, unsigned int, unsigned int)+73C50 0451FAB0 PPC 0D873424 nsChannelListener::OnDataAvailable(nsIChannel*, nsISupports*, ns IInputStream*, unsigned int, unsigned int)+00048 0451FA60 PPC 0B62A918 nsDocumentOpenInfo::OnDataAvailable(nsIChannel*, nsISupports*, n sIInputStream*, unsigned int, unsigned int)+2A918 0451FA20 PPC 0D872434 nsDocumentBindInfo::OnDataAvailable(nsIChannel*, nsISupports*, n sIInputStream*, unsigned int, unsigned int)+000C0 0451F9B0 PPC 0C2D5520 nsParser::OnDataAvailable(nsIChannel*, nsISupports*, nsIInputStr eam*, unsigned int, unsigned int)+D5520 0451F8B0 PPC 0C2D4AF8 nsParser::ResumeParse(nsIDTD*, int)+D4AF8 0451F860 PPC 0C2C9FBC CNavDTD::WillInterruptParse()+C9FBC 0451F820 PPC 0BB81EF0 HTMLContentSink::WillInterrupt()+81EF0 0451F7E0 PPC 0BB80B50 SinkContext::FlushTags()+80B50 0451F780 PPC 0BB8619C HTMLContentSink::NotifyAppend(nsIContent*, int)+ 8619C 0451F740 PPC 0BB8AF3C nsHTMLDocument::ContentAppended(nsIContent*, int)+ 8AF3C 0451F6F0 PPC 0BB50A94 nsDocument::ContentAppended(nsIContent*, int)+50A94 0451F690 PPC 0BB65CC8 PresShell::ContentAppended(nsIDocument*, nsIContent* , int)+65CC8 0451F630 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F5D0 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F570 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F510 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F4B0 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F450 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F3F0 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F390 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F330 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F2D0 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F270 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F210 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F1B0 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F150 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F0F0 PPC 0BE2F4EC FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4EC 0451F090 PPC 0BE2F4A0 FrameManager::RestoreFrameState(nsIPresContext*, nsIFrame*, nsIL ayoutHistoryState*)+2F4A0 Closing log
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → DUPLICATE
Now that 18798 is back on the [DOGFOOD] radar closing this bug as a dup. Note - closing in favor of the higher numbered bug do to the more extensive history and diagnosis in 18798. *** This bug has been marked as a duplicate of 18798 ***
Sorry about the late comment. I was out on vaction last week. I believe this is a dup of 18798. I made some checkins last week where partially loaded pages will stay in Session History.
Status: RESOLVED → VERIFIED
Rubber-stamping as Verified Duplicate. Warren, if you're able to reproduce a separate crash using a different stack crawl (or believe that there's a separate bug), please do re-open with your comments. Thanks!
You need to log in before you can comment on or make changes to this bug.