[DOGFOOD].test9 crashes

VERIFIED FIXED in M13

Status

()

P3
critical
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: mats, Assigned: pnunn)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT-], URL)

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
To repeat:
1. load test9 in the debug menu entitled "#9 Frames"
2. click on the links "frame1" and "frame2" repeatedly

It crashes after a few clicks using 1999-08-24-08-M10 on Solaris 2.6(sparc)
and 1999-08-26-17-M10 on Windows NT. Just before it crashes (on Solaris) I get
the following warnings:
Gtk-CRITICAL **: file gtkwidget.c: line 1394 (gtk_widget_destroy): assertion
`widget != NULL' failed.

Gtk-CRITICAL **: file gtkwidget.c: line 1394 (gtk_widget_destroy): assertion
`widget != NULL' failed.

Gtk-CRITICAL **: file gtkwidget.c: line 1394 (gtk_widget_destroy): assertion
`widget != NULL' failed.

Then it crashes.

Here is a stack trace picked up on Sun Solaris 2.6 (sparc):
shell> dbx viewer_gtk core
Reading symbolic information for viewer_gtk
[...some stuff deleted...]
(dbx) where
current thread: t@1
=>[1] 0x0(0x74629d, 0x0, 0x746200, 0xb01000, 0xb01c60, 0xb01), at 0xffffffff
  [2] GetDocument__C20nsGenericDOMDataNodeRP11nsIDocument(0xa6e818, 0xefffaadc,
0x0, 0xee340550, 0xeb, 0xb01ce0), at 0xecf3d6fc
  [3] GetDocument__C10nsTextNodeRP11nsIDocument(0xa6e800, 0xefffaadc,
0xecf5cc94, 0xa6e80c, 0xb01c00, 0xb01), at 0xecf5cc9c
  [4] GetDocument__11nsTextFrameP14nsIPresContext(0xac6480, 0x579100,
0xee3425dc, 0xefffc8dc, 0xa28480, 0xb01), at 0xecdde844
  [5]
PaintAsciiText__11nsTextFrameP14nsIPresContextR19nsIRenderingContextP15nsIStyleC
ontextRQ211nsTextFrame9TextStyleii(0xac6480, 0x579100, 0x8e7dc0, 0x8ea800,
0xefffc8b0, 0x0), at 0xecde16dc
  [6]
Paint__11nsTextFrameR14nsIPresContextR19nsIRenderingContextRC6nsRect17nsFramePai
ntLayer(0xac6480, 0x579100, 0x8e7dc0, 0x0, 0x2, 0xefffc8b0), at 0xecdded5c
  [7]
PaintChild__16nsContainerFrameR14nsIPresContextR19nsIRenderingContextRC6nsRectP8
nsIFrame17nsFramePaintLayer(0xac3200, 0x579100, 0x8e7dc0, 0xefffcb38, 0xac6480,
0x2), at 0xecdb7424
  [8]
PaintChildren__16nsContainerFrameR14nsIPresContextR19nsIRenderingContextRC6nsRec
t17nsFramePaintLayer(0xac3200, 0x579100, 0x8e7dc0, 0xefffcb38, 0x2, 0xecdb71dc),
at 0xecdb728c
  [9]
Paint__20nsHTMLContainerFrameR14nsIPresContextR19nsIRenderingContextRC6nsRect17n
sFramePaintLayer(0xac3200, 0x579100, 0x8e7dc0, 0xefffcb38, 0x2, 0xecdc2514), at
0xecdc2678
  [10]
PaintChild__16nsContainerFrameR14nsIPresContextR19nsIRenderingContextRC6nsRectP8
nsIFrame17nsFramePaintLayer(0x926e80, 0x579100, 0x8e7dc0, 0xefffccf0, 0xac3200,
0x2), at 0xecdb7424
  [11]
PaintChildren__12nsBlockFrameR14nsIPresContextR19nsIRenderingContextRC6nsRect17n
sFramePaintLayer(0x926e80, 0x579100, 0x8e7dc0, 0xefffccf0, 0x2, 0xecdb35dc), at
0xecdb3678
  [12]
Paint__12nsBlockFrameR14nsIPresContextR19nsIRenderingContextRC6nsRect17nsFramePa
intLayer(0x926e80, 0x579100, 0x8e7dc0, 0xefffccf0, 0x2, 0xecdb331c), at
0xecdb34d4
  [13]
PaintChild__16nsContainerFrameR14nsIPresContextR19nsIRenderingContextRC6nsRectP8
nsIFrame17nsFramePaintLayer(0x926e00, 0x579100, 0x8e7dc0, 0xefffcea8, 0x926e80,
0x2), at 0xecdb7424
  [14]
PaintChildren__12nsBlockFrameR14nsIPresContextR19nsIRenderingContextRC6nsRect17n
sFramePaintLayer(0x926e00, 0x579100, 0x8e7dc0, 0xefffcea8, 0x2, 0xecdb35dc), at
0xecdb3678
  [15]
Paint__12nsBlockFrameR14nsIPresContextR19nsIRenderingContextRC6nsRect17nsFramePa
intLayer(0x926e00, 0x579100, 0x8e7dc0, 0xefffcea8, 0x2, 0xecdb331c), at
0xecdb34d4
  [16]
PaintChild__16nsContainerFrameR14nsIPresContextR19nsIRenderingContextRC6nsRectP8
nsIFrame17nsFramePaintLayer(0x926d00, 0x579100, 0x8e7dc0, 0xefffd248, 0x926e00,
0x2), at 0xecdb7424
  [17]
PaintChildren__16nsContainerFrameR14nsIPresContextR19nsIRenderingContextRC6nsRec
t17nsFramePaintLayer(0x926d00, 0x579100, 0x8e7dc0, 0xefffd248, 0x2, 0xecdb71dc),
at 0xecdb728c
  [18]
Paint__20nsHTMLContainerFrameR14nsIPresContextR19nsIRenderingContextRC6nsRect17n
sFramePaintLayer(0x926d00, 0x579100, 0x8e7dc0, 0xefffd248, 0x2, 0xecdc2514), at
0xecdc2678
  [19] Paint__9PresShellP7nsIViewR19nsIRenderingContextRC6nsRect(0x91bd80,
0x926d80, 0x8e7dc0, 0xefffd248, 0xecdda9b8, 0xefffd250), at 0xecddaa48
  [20] Paint__6nsViewR19nsIRenderingContextRC6nsRectUiRi(0x926d80, 0x8e7dc0,
0xefffd248, 0x80, 0xefffd4ec, 0x80), at 0xed1c6730
  [21]
RenderView__13nsViewManagerP7nsIViewR19nsIRenderingContextRC6nsRectR6nsRectRi(0x
91bb80, 0x926d80, 0x8e7dc0, 0xefffd4f0, 0xadc364, 0xefffd4ec), at 0xed1d0390
  [22]
RenderViews__13nsViewManagerP7nsIViewR19nsIRenderingContextRC6nsRectRi(0x91bb80,
0x926900, 0x8e7dc0, 0xefffd4f0, 0xefffd4ec, 0xadc364), at 0xed1cecdc
  [23]
Refresh__13nsViewManagerP7nsIViewP19nsIRenderingContextPC6nsRectUi(0x91bb80,
0x926900, 0x8e7dc0, 0xefffd4f0, 0x1, 0x91c000), at 0xed1ce574
  [24] DispatchEvent__13nsViewManagerP10nsGUIEventR13nsEventStatus(0x91bb80,
0xefffd830, 0xefffd660, 0xed1d08c0, 0xefffd64c, 0xefffd648), at 0xed1d0b38
  [25] 0xed1c6020(0xefffd830, 0xed1c5fd4, 0x71b100, 0x0, 0xeb, 0xee343da8), at
0xed1c601f
  [26] DispatchEvent__8nsWidgetP10nsGUIEventR13nsEventStatus(0x71b100,
0xefffd830, 0xefffd74c, 0xee669920, 0xee33f310, 0xef65de88), at 0xee66998c
  [27] DispatchWindowEvent__8nsWidgetP10nsGUIEvent(0x71b100, 0xefffd830,
0x71b100, 0xee344600, 0xeb, 0x0), at 0xee66989c
  [28] OnPaint__8nsWindowR12nsPaintEvent(0x71b100, 0xefffd830, 0xee66c8c4, 0x82,
0x0, 0xefffdf30), at 0xee66c944
  [29] handle_expose_event__FP10_GtkWidgetP15_GdkEventExposePv(0x926980,
0x23c018, 0x71b100, 0x0, 0x0, 0x0), at 0xee65df44
  [30] gtk_marshal_BOOL__POINTER(0x926980, 0xee65def8, 0x71b100, 0xefffda60,
0x8c508, 0x1), at 0x8c518
  [31] 0x69f08(0x0, 0xefffd9c0, 0x926980, 0xefffda60, 0x0, 0x0), at 0x69f07
  [32] 0x690b4(0x926980, 0x19, 0xefffda60, 0x4, 0xefffddc0, 0x20001), at 0x690b3
  [33] gtk_signal_emit(0x926980, 0x19, 0x2ae384, 0xefffda60, 0x981560, 0x981),
at 0x66a68
  [34] gtk_widget_event(0x926980, 0x23c018, 0x0, 0x0, 0x0, 0x0), at 0x80ce4
  [35] gtk_main_do_event(0x23c018, 0x0, 0x49564, 0x0, 0x0, 0x0), at 0x49b78
  [36] 0xa8054(0x23c018, 0xefffdfc0, 0x0, 0x981578, 0x0, 0xefffdf30), at 0xa8053
  [37] 0xbf11c(0x104800, 0x104800, 0x104800, 0x104a54, 0xefffdfc0, 0x104a4c), at
0xbf11b
  [38] 0xbf72c(0x104800, 0x104800, 0x104800, 0x104a54, 0x104800, 0x1), at
0xbf72b
  [39] g_main_run(0x235480, 0x103400, 0x0, 0x111d60, 0x0, 0xef663520), at
0xbf8b4
  [40] gtk_main(0x1f, 0x1, 0xee658aa8, 0x111d60, 0xffffffff, 0x1), at 0x49330
  [41] Run__10nsAppShell(0x111ec0, 0xee658fe4, 0x111ec0, 0xefffe128, 0x6cc,
0xef65de88), at 0xee659168
  [42] Run__17nsNativeViewerApp(0x10b180, 0x3b414, 0x10b180, 0x368a0, 0x0,
0x10b201), at 0x3b43c
  [43] main(0x1, 0xefffe2c4, 0xefffe2cc, 0x105524, 0x0, 0x0), at 0x3b6b0
(dbx) quit

Updated

19 years ago
Assignee: don → troy
Component: Browser-General → Layout

Updated

19 years ago
Assignee: troy → trudelle
Component: Layout → XP Toolkit/Widgets

Comment 1

19 years ago
Looks like a widget problem. It's not a general layout problem

Updated

19 years ago
Assignee: trudelle → karnaze
Component: XP Toolkit/Widgets → HTMLFrames

Comment 2

19 years ago
Also crashes Win98. There's no XUL or XPToolkit widgets involved though, and
these same steps also crash Viewer. The only widget stuff going on here is the
native event handling, which you'll see on almost any stack. The warnings are a
known problem that only occurs on Unix -red herring. Since its an HTML frame
test that's crashing, I'm reassigning this to the HTMLFrames owner.

Updated

19 years ago
Assignee: karnaze → pollmann

Comment 3

19 years ago
Eric, this is probably not your bug, but please find out who to give it to.

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 4

19 years ago
Win32 build 1999090311 Apprunner doesn't crash anymore.
Marking WORKSFORME.
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 5

19 years ago
Bug is still present in apprunner 1999-09-05-12-M10 on Windows NT4SP5 and
viewer_gtk 1999-09-05-08-M11 on Sun/Solaris 2.6/sparc. I will attach NT dump.
(Reporter)

Updated

19 years ago
Resolution: WORKSFORME → ---
(Reporter)

Comment 6

19 years ago
Created attachment 1564 [details]
Windows NT4SP5 crash data

Updated

19 years ago
Status: REOPENED → ASSIGNED
Component: HTMLFrames → ImageLib

Comment 7

19 years ago
Well, I'm able to reproduce a different crash from the same user action.  This
makes three distinct reported stack traces for this, but here's what I got on
NT:

To reproduce, clicked on "frame1", "frame2", then "frame1" in rapid succession
under "Put test9b.html in:" list.

Stacktrace:

ReconnectHack
ImageNetContextImpl::GetURL
il_image_complete
ImgDCallbk::ImgDCBHaveImageAll
process_buffered_gif_input_data
gif_delay_time_callback
timer_callback
TimerImpl::Fire
TimerImpl::ProcessTimeouts
FireTimeout

The problem here was that in ReconnectHack, we get an ImageGroup, then check if
mListenerRequest is null, then dereference it.  In this crash example, it had
the value 0xdddddddd - leading me to believe it may have been NS_RELEASE'd.

This is caused byt a timer callback for the animated gif on this the page inside
of the iframe inside of this iframe, test2.html.

I've simplified this to a smaller test case that I'll attatch.

Comment 8

19 years ago
Created attachment 1584 [details]
Simplified test case

Updated

19 years ago
Assignee: pollmann → pnunn
Status: ASSIGNED → NEW

Comment 9

19 years ago
This test case has a button followed by two iframes. Inside each iframe is an
animated gif. By clicking on the button, the first iframe will be reloaded. This
should cause a crash.

On Windows NT, this always caused a crash for me on the first click.
On Linux, this frequently took a dozen clicks or more in rapid succession to
cause a crash.  In both cases, the stack trace is similar to the one above:

ReconnectHack
ImageNetContextImpl::GetURL
il_image_complete
ImgDCallbk::ImgDCBHaveImageAll
process_buffered_gif_input_data
gif_delay_time_callback
timer_callback
(more timer stuff)

This seems to be caused by an animated image/imagegroup being freed before it's
timer is being called.  Pam, can you take a look?
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 10

19 years ago
I just tried this on linux and it works for me.
Are you still seeing this bug on linux with an
up to date build?
-pn
(Assignee)

Updated

19 years ago
Summary: test9 crashes → [DOGFOOD].test9 crashes
Target Milestone: M11

Updated

19 years ago
Summary: [DOGFOOD].test9 crashes → [PDT+][DOGFOOD].test9 crashes
(Assignee)

Comment 11

19 years ago
I can duplicate the crash on windows.
Thanks for the attached test. It helps alot.
-p

Updated

19 years ago
Summary: [PDT+][DOGFOOD].test9 crashes → [DOGFOOD].test9 crashes
Whiteboard: [PDT-]
(Assignee)

Updated

19 years ago
Target Milestone: M11 → M13
(Assignee)

Comment 12

19 years ago
Here is what I found yesterday:
This bug only occurs if the same animated gif, with exactly the
same scaling is in both frames. In this case, only one image
container is created and used for both image requests. When one of
the frames is updated(and therefore unloaded), the image group context
is destroyed. Since the image container is still referenced, it is
not destroyed.
The error occurs when the timer kicks off for looping the image container,
before the image group context destruction is completed. The crash occurs
when the 'listener' is accessed after it has been destroyed.

I want to fix this bug, but I think it has lower priority than other
bugs which occur more frequently. This bug is framed by a very specific
scenerio. The two image requests must reference one image container. The
image must be animated. The timer kick must happen before the frame image
group has been destroyed.

Updated

19 years ago
Blocks: 17432

Updated

19 years ago
QA Contact: leger → elig

Comment 13

19 years ago
Resetting QA contact from leger.
(Assignee)

Comment 14

19 years ago
*** Bug 9906 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 15

19 years ago
See jazz/users/pnunn/publish/frametest/index.html
for test case developed for bug#9906.
-pn
(Assignee)

Comment 16

19 years ago
I've got a fix for this one.
Need review and ok to check in.
-pn
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

19 years ago
Just checked in a fix.
-pn

Comment 18

19 years ago
Hmm...on Mac OS/Win32, this works fine using the 2.07.00 AM build.

However, the Linux build of the same date won't even load the test9 page --- it 
draws partially, and then the entire UI ceases to respond.

Thus, marking as verified.
Status: RESOLVED → VERIFIED

Updated

18 years ago
No longer blocks: 17432
You need to log in before you can comment on or make changes to this bug.