Closed Bug 17572 Opened 25 years ago Closed 25 years ago

[DOGFOOD] crash trying to go back and forward

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
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 ago → 25 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.