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

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

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.

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

Win32 build 1999090311 Apprunner doesn't crash anymore. Marking WORKSFORME.

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.

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.

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?

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

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

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.

Resetting QA contact from leger.

*** Bug 9906 has been marked as a duplicate of this bug. ***

See jazz/users/pnunn/publish/frametest/index.html for test case developed for bug#9906. -pn

I've got a fix for this one. Need review and ok to check in. -pn

Just checked in a fix. -pn

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.