Closed
Bug 17572
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] crash trying to go back and forward
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
M12
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.
Updated•25 years ago
|
Assignee: trudelle → saari
Target Milestone: M13
Comment 1•25 years ago
|
||
reassigning to saari, due to menu stuff on the stack.
Comment 3•25 years ago
|
||
mass-moving all m13 bugs to m14
Updated•25 years ago
|
Target Milestone: M14 → M12
Comment 4•25 years ago
|
||
Moving this one to M12
Comment 6•25 years ago
|
||
This seems to be a major stability problem, can we get this on M11?
Comment 7•25 years ago
|
||
We'll live this at M12 for now, as it's questionable how reproducible this is.
Updated•25 years ago
|
Severity: normal → critical
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Comment 8•25 years ago
|
||
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.
Updated•25 years ago
|
QA Contact: claudius → elig
Comment 9•25 years ago
|
||
QA Assigning to self for verification.
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Updated•25 years ago
|
Resolution: WORKSFORME → ---
Comment 10•25 years ago
|
||
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.
Comment 11•25 years ago
|
||
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.
Comment 12•25 years ago
|
||
Nay, saari, at _your_ convenience. I insist. ;) [but, seriously, any time, just
drop by.]
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] 11/26
Updated•25 years ago
|
Assignee: saari → sdagley
Status: REOPENED → NEW
Comment 13•25 years ago
|
||
reassigning to sdagley. Steve, please update the estimated completion date in
the whiteboard.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [PDT+] 11/26 → [PDT+] 12/03
Assignee | ||
Comment 14•25 years ago
|
||
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
Assignee | ||
Comment 15•25 years ago
|
||
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.
Updated•25 years ago
|
OS: Windows NT → All
Hardware: PC → All
Comment 16•25 years ago
|
||
[Correcting Platform/OS to 'All'; can reproduce in 3 clicks on today's Mac OS
build. Win32 requires a lot more clicks.]
Assignee | ||
Comment 17•25 years ago
|
||
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?
Comment 18•25 years ago
|
||
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
Assignee | ||
Comment 19•25 years ago
|
||
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.
Comment 20•25 years ago
|
||
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.)
Assignee | ||
Comment 21•25 years ago
|
||
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)
Assignee | ||
Comment 22•25 years ago
|
||
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
Comment 23•25 years ago
|
||
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
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 24•25 years ago
|
||
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 ***
Comment 25•25 years ago
|
||
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.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 26•25 years ago
|
||
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.
Description
•