10225 - Cliking on Link text entry in link dialog caused seg fault.

Status: VERIFIED WORKSFORME

(Core :: DOM: Editor, defect, P2)

Description

[Michael Bedy]

Linux: build on pull as of 7-19-1999 around 11pm (EST).
GTK build (I think)

Do the following:
 1. Start apprunner.
 2. Open a blank page in the editor
 3. Type some garbage: eg. "I will crash"
 4. Highlight a portion of the garbage: eg. "will"
 5. Click on the link button in the toolbar to open the link dialog box.
 6. The link text field will have the text in it: e.g. "will"; Click on it.
 7. Look at the pretty core file :-)

  This was repeatable. Unfortunatly, it is a pain to get a stack trace off the
computer this happend on but I will try soon. (it's a dialup connection, and I
don't want to tie up the line during the day.)

  I looked at it for a time with ddd, and I found that it crashed in a function
(and this is from memory, so forgive me if it is a little off,) in nsLabelEntry.
Sorry, I can't remember the function name, but it was handleing the mouse click.
The seg fault was on a call to mContentFrame->SetFocus(stuff). The crash was
because the virtual function table pointer for mContentFrame was pointing to an
invalid memory location.

  At this point I was in over my head. I havn't yet learned much about Mozilla.

Comment 1

[Michael Bedy]

Program received signal SIGSEGV, Segmentation fault.
0x40df67a0 in nsLabelFrame::HandleEvent (this=0x8716770,
aPresContext=@0x82f6d70, aEvent=0xbffff628, aEventStatus=@0xbffff59c) at
nsLabelFrame.cpp:170
(gdb) where
#0  0x40df67a0 in nsLabelFrame::HandleEvent (this=0x8716770,
aPresContext=@0x82f6d70, aEvent=0xbffff628, aEventStatus=@0xbffff59c) at
nsLabelFrame.cpp:170
#1  0x40d1d324 in PresShell::HandleEvent (this=0x85c3fe0, aView=0x87570e8,
aEvent=0xbffff628, aEventStatus=@0xbffff59c) at nsPresShell.cpp:2241
#2  0x41028673 in nsView::HandleEvent (this=0x87570e8, event=0xbffff628,
aEventFlags=8, aStatus=@0xbffff59c, aHandled=@0xbffff540) at nsView.cpp:833
#3  0x41028604 in nsView::HandleEvent (this=0x853bdb0, event=0xbffff628,
aEventFlags=28, aStatus=@0xbffff59c, aHandled=@0xbffff540) at nsView.cpp:817
#4  0x41031b33 in nsViewManager::DispatchEvent (this=0x84920d8,
aEvent=0xbffff628, aStatus=@0xbffff59c) at nsViewManager.cpp:1734
#5  0x410266e7 in HandleEvent (aEvent=0xbffff628) at nsView.cpp:66
#6  0x4022d205 in nsWidget::DispatchEvent (this=0x85cb768, event=0xbffff628,
aStatus=@0xbffff5d8) at nsWidget.cpp:1091
#7  0x4022cf23 in nsWidget::DispatchWindowEvent (this=0x85cb768,
event=0xbffff628) at nsWidget.cpp:963
#8  0x4022d2c4 in nsWidget::DispatchMouseEvent (this=0x85cb768,
aEvent=@0xbffff628) at nsWidget.cpp:1118
#9  0x4022df86 in nsWidget::OnButtonPressSignal (this=0x85cb768,
aGdkButtonEvent=0x83548dc) at nsWidget.cpp:1576
#10 0x4022ea6d in nsWidget::ButtonPressSignal (aWidget=0x8394b10,
aGdkButtonEvent=0x83548dc, aData=0x85cb768) at nsWidget.cpp:1943
#11 0x40622eb9 in   ()
#12 0x405e0ba5 in gtk_signal_remove_emission_hook ()
#13 0x405dff0e in gtk_signal_set_funcs ()
#14 0x405dde4f in gtk_signal_emit ()
#15 0x406193c8 in gtk_widget_event ()
#16 0x405ad902 in gtk_propagate_event ()
#17 0x405aca48 in gtk_main_do_event ()
#18 0x406615eb in gdk_wm_protocols_filter ()
#19 0x40691e02 in g_get_current_time ()
#20 0x4069246b in g_get_current_time ()
#21 0x40692621 in g_main_run ()
#22 0x405ac41b in gtk_main ()
#23 0x4021c469 in nsAppShell::Run (this=0x80b2638) at nsAppShell.cpp:241
#24 0x40148d58 in nsAppShellService::Run (this=0x80c0198) at
nsAppShellService.cpp:428
#25 0x804b0f0 in main (argc=1, argv=0xbffffc74) at nsAppRunner.cpp:717
(gdb)

Comment 2

[buster]

assigned to kevin.  kevin, can you do the first pass on this bug and see if it
is really a bug in nsLabelFrame, and not an editor bug?  Thanks.

Comment 3

[Kevin McCluskey (gone)]

I tried on on WIN32 and Linux with a Aug 2, 1999 build and it does not crash.

Comment 4

[sujay]

I can't reproduce this...marking verified in 8/3 build.