Closed
Bug 282764
Opened 19 years ago
Closed 19 years ago
[FIX]crash when going Back in frameset page [@ nsWindow::UpdateIdle]
Categories
(Core Graveyard :: GFX: Gtk, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8beta2
People
(Reporter: MatsPalmgren_bugz, Assigned: bzbarsky)
References
()
Details
(Keywords: crash, regression)
Crash Data
Attachments
(3 files)
4.86 KB,
text/html
|
Details | |
1.25 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
1.78 KB,
patch
|
Details | Diff | Splinter Review |
crash when going Back in frameset page. STEPS TO REPRODUCE: 1. load URL 2. click "Test" in the combobox (a new page "Veranstaltungen im Wintersemester" should be loaded in the right frame) 3. scroll to section "Übungen:" and click on the "Web-Server" link (a directory listing should appear, in the right frame). 4. go Back twice repeat 2-4 until crash... PLATFORMS AND BUILDS TESTED: Mozilla 2005-02-17-12 (GTK1) on Linux - crash Mozilla 2005-01-20-06 (GTK1) on Linux - crash Mozilla 2005-01-19-06 and earlier (GTK1) on Linux - does not seem to crash I haven't been able to crash a GTK2 build so far, not even a debug build, although I do see a <select> being displayed in the right frame occassionally, which I don't think should occur.
Reporter | ||
Comment 1•19 years ago
|
||
Talkback: TB3786092G
Assignee | ||
Comment 2•19 years ago
|
||
Hmm... I can't get this to crash.... (either in my somewhat-hacked opt build, or my vanilla debug build from this morning). Mats, does the patch in bug 281157 help with this crash by any chance?
Reporter | ||
Comment 3•19 years ago
|
||
I can reproduce the crash in a local Opt GTK1 build, also with the patch for bug 281157. It is much harder to make it crash with that patch though. It does not crash at all if I use --enable-debug. (gdb) bt #0 0x405e5b71 in kill () from /lib/i686/libc.so.6 #1 0x401d6cf1 in pthread_kill () from /lib/i686/libpthread.so.0 #2 0x401d700b in raise () from /lib/i686/libpthread.so.0 #3 0x405e5904 in raise () from /lib/i686/libc.so.6 #4 0x405e6e8c in abort () from /lib/i686/libc.so.6 #5 0x40589305 in __cxxabiv1::__terminate(void (*)()) () from /usr/lib/libstdc++.so.5 #6 0x40589342 in std::terminate() () from /usr/lib/libstdc++.so.5 #7 0x40589855 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.5 #8 0x40c6f775 in nsWindow::UpdateIdle(void*) (data=0x0) at nsWindow.cpp:780 #9 0x403b295f in g_idle_dispatch () from /opt/gnome/lib/libglib-1.2.so.0 #10 0x403b170b in g_main_dispatch () from /opt/gnome/lib/libglib-1.2.so.0 #11 0x403b1d98 in g_main_iterate () from /opt/gnome/lib/libglib-1.2.so.0 #12 0x403b1ed4 in g_main_run () from /opt/gnome/lib/libglib-1.2.so.0 #13 0x402c040f in gtk_main () from /opt/gnome/lib/libgtk-1.2.so.0 #14 0x40c5dc8e in nsAppShell::Run() (this=0x8117bc0) at nsAppShell.cpp:293 #15 0x40c43275 in nsAppStartup::Run() () from /usr/moz/bug282764/mozilla/dist/bin/components/libappcomps.so #16 0x08050d28 in main1(int, char**, nsISupports*) () #17 0x080516eb in main () (gdb) fr 8 #8 0x40c6f775 in nsWindow::UpdateIdle(void*) (data=0x0) at nsWindow.cpp:780 780 window->Update(); (gdb) p window $6 = (nsWindow *) 0x0 (gdb) p it $7 = (GSList *) 0x81c1f40 (gdb) p *it $8 = {data = 0x874d240, next = 0x81c1f48} (gdb) p old_queue $9 = (GSList *) 0x401de940 (gdb) p *old_queue $10 = {data = 0x0, next = 0x0} The stack is always the same, with or without the patch, it's nsWindow::UpdateIdle with window=0 or 1.
Depends on: 281157
Summary: crash when going Back in frameset page → crash when going Back in frameset page [@ nsWindow::UpdateIdle]
Assignee | ||
Comment 4•19 years ago
|
||
So... what else is in old_queue? It confuses me that accessing the window in the first loop doesn't crash; the strong implication is that somehow the window is destroyed while traversing the second loop or something like that.... Does commenting out the UnsuppressAndInvalidate() call in nsPresShell at the end of ProcessReflowCommands() make the problem go away?
Reporter | ||
Comment 5•19 years ago
|
||
(In reply to comment #4) > It confuses me that accessing the window in the first loop doesn't crash; the > strong implication is that somehow the window is destroyed while traversing > the second loop or something like that.... Yes, that is what happens. loop1, window=0x86d35a0 (destroying=0, updating=1) loop1, window=0x86c2190 (destroying=0, updating=1) loop1, window=0x8631a28 (destroying=0, updating=1) loop1, window=0x8656280 (destroying=0, updating=1) loop1, window=0x835dc68 (destroying=0, updating=1) loop2, window=0x86d35a0 (destroying=0) loop2, window=0x86c2190 (destroying=1) <<< CRASH If I add "if (!window->mIsDestroying)" before the Update() call the crash goes away. > > Does commenting out the UnsuppressAndInvalidate() call in nsPresShell at > the end of ProcessReflowCommands() make the problem go away? Yes, but the new page does not appear unless I Reload, so I don't know how valid this test was.
Reporter | ||
Comment 6•19 years ago
|
||
Assignee | ||
Comment 7•19 years ago
|
||
So it looks like we have a draw queued for the frameset and the frame, while a new document is loading in the frame. When we paint the frameset we WillPaint() on the frame, which reflows, unsuppresses painting, and kills the old content viewer, with its widget and such. The simple fix is to not bother with the WillPaint() reflow if we have painting suppressed.... we're not really going to be painted anyway.
Assignee: blizzard → bzbarsky
Status: NEW → ASSIGNED
Attachment #174862 -
Flags: superreview?(roc)
Attachment #174862 -
Flags: review?(roc)
Assignee | ||
Comment 8•19 years ago
|
||
Mats, thanks for debugging this!
Priority: -- → P1
Summary: crash when going Back in frameset page [@ nsWindow::UpdateIdle] → [FIX]crash when going Back in frameset page [@ nsWindow::UpdateIdle]
Target Milestone: --- → mozilla1.8beta2
Assignee | ||
Comment 9•19 years ago
|
||
Attachment #174862 -
Flags: superreview?(roc)
Attachment #174862 -
Flags: superreview+
Attachment #174862 -
Flags: review?(roc)
Attachment #174862 -
Flags: review+
Assignee | ||
Comment 10•19 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Product: Core → Core Graveyard
Updated•13 years ago
|
Crash Signature: [@ nsWindow::UpdateIdle]
You need to log in
before you can comment on or make changes to this bug.
Description
•