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)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: MatsPalmgren_bugz, Assigned: bzbarsky)

References

()

Details

(Keywords: crash, regression)

Crash Data

Attachments

(3 files)

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.
Talkback: TB3786092G
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?
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]
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?
(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.
Attached patch FixSplinter Review
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)
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
Attachment #174862 - Flags: superreview?(roc)
Attachment #174862 - Flags: superreview+
Attachment #174862 - Flags: review?(roc)
Attachment #174862 - Flags: review+
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
Crash Signature: [@ nsWindow::UpdateIdle]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: