243112 - crash when closing window from onblur [@ nsEventStateManager::PreHandleEvent]

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Christian Persch (GNOME) (away; not receiving bug mail)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040506

When opening a popup window which closes on blur, I get a crash. This is
reproducible in galeon, epiphany and TestGtkEmbed, using mozilla built from cvs
(on 2004-05-06 and 2004-05-07). It is *not* reproducible using mozilla 1.6 or
1.7 branch (compiled 2004-05-07). A build of mozilla trunk from 2004-04-19 is
also confirmed *not* to show this.

Reproducible: Always
Steps to Reproduce:
1. Start TestGtkEmbed
2. Open http://cvs.gnome.org/viewcvs/*checkout*/galeon/tests/popups.html
3. Click on "Testcase for bug 116256"
3. After the window opened, click in the url entry to trigger onblur

Actual Results:  
Crash.

Expected Results:  
Window closes without crash.

Unfortunately I don't have a debug build, but here's the trace anyway:

#0  0xa813a70e in ?? ()
#1  0x411476a0 in nsEventStateManager::PreHandleEvent () from
/mnt/opt/gnome2/lib/mozilla-1.8a/components/libgklayout.so
#2  0x40fd3cc0 in PresShell::HandleEventInternal () from
/mnt/opt/gnome2/lib/mozilla-1.8a/components/libgklayout.so
#3  0x40fd39cf in PresShell::HandleEvent () from
/mnt/opt/gnome2/lib/mozilla-1.8a/components/libgklayout.so
#4  0x412737f6 in nsViewManager::HandleEvent () from
/mnt/opt/gnome2/lib/mozilla-1.8a/components/libgklayout.so
#5  0x412730b7 in nsViewManager::DispatchEvent () from
/mnt/opt/gnome2/lib/mozilla-1.8a/components/libgklayout.so
#6  0x41289c77 in GlobalWindowImpl::Deactivate () from
/mnt/opt/gnome2/lib/mozilla-1.8a/components/libgklayout.so
#7  0x40026148 in EmbedPrivate::ChildFocusOut () from ./libgtkembedmoz.so
#8  0x40023438 in handle_child_focus_out () from ./libgtkembedmoz.so
#9  0x4039aac4 in _gtk_marshal_BOOLEAN__BOXED (closure=0x81a8ff0,
return_value=0xbfffe1c0, n_param_values=2, param_values=0xbfffe090,
invocation_hint=0xbfffe1e8, 
    marshal_data=0x0) at gtkmarshalers.c:82
#10 0x40659330 in g_closure_invoke (closure=0x82ed608, return_value=0x82ed330,
n_param_values=137286448, param_values=0x82ed330, invocation_hint=0x82ed330)
    at gclosure.c:437
#11 0x4066d365 in signal_emit_unlocked_R (node=0x80892a8, detail=0,
instance=0x82e90b0, emission_return=0xbfffe290, instance_and_params=0xbfffe2f0)
at gsignal.c:2436
#12 0x4066c0fe in g_signal_emit_valist (instance=0x82e90b0, signal_id=0,
detail=0, var_args=0xbfffe480 "\210���\210���") at gsignal.c:2205
#13 0x4066c624 in g_signal_emit (instance=0x82ed330, signal_id=137286448,
detail=137286448) at gsignal.c:2239
#14 0x40498ab7 in gtk_widget_event_internal (widget=0x82e90b0, event=0x8230da4)
at gtkwidget.c:3563
#15 0x404a6d57 in do_focus_change (widget=0x82e90b0, in=0) at gtkwindow.c:4324
#16 0x404a723e in gtk_window_real_set_focus (window=0x824f960, focus=0x81a88f8)
at gtkwindow.c:4510
#17 0x4066e55e in g_cclosure_marshal_VOID__OBJECT (closure=0x808fb00,
return_value=0x0, n_param_values=2, param_values=0xbfffe730,
invocation_hint=0xbfffe628, 
    marshal_data=0x404a7090) at gmarshal.c:636
#18 0x406596c7 in g_type_class_meta_marshal (closure=0x808fb00,
return_value=0x82ed330, n_param_values=137286448, param_values=0xbfffe730,
invocation_hint=0x82ed330, 
    marshal_data=0x82ed330) at gclosure.c:514
#19 0x40659330 in g_closure_invoke (closure=0x808fb00, return_value=0x82ed330,
n_param_values=137286448, param_values=0x82ed330, invocation_hint=0x82ed330)
    at gclosure.c:437
#20 0x4066cd95 in signal_emit_unlocked_R (node=0x808fb48, detail=0,
instance=0x824f960, emission_return=0x0, instance_and_params=0xbfffe730) at
gsignal.c:2474
#21 0x4066c327 in g_signal_emit_valist (instance=0x824f960, signal_id=0, detail=0, 
    var_args=0xbfffe8c0
"@2\a\b�2#\b����\224[T@`�$\b�\210\032\b�����\225I@`�$\b�\210\032\b") at
gsignal.c:2195
#22 0x4066c624 in g_signal_emit (instance=0x82ed330, signal_id=137286448,
detail=137286448) at gsignal.c:2239
#23 0x404a1de4 in _gtk_window_internal_set_focus (window=0x824f960,
focus=0x81a88f8) at gtkwindow.c:1196
#24 0x404995d9 in gtk_widget_real_grab_focus (focus_widget=0x81a88f8) at
gtkwidget.c:3906
#25 0x403358c9 in gtk_entry_grab_focus (widget=0x81a88f8) at gtkentry.c:1751
#26 0x4066d861 in g_cclosure_marshal_VOID__VOID (closure=0x80882d0,
return_value=0x0, n_param_values=1, param_values=0x82ed330,
invocation_hint=0xbfffea68, 
    marshal_data=0x403358a0) at gmarshal.c:77
#27 0x406596c7 in g_type_class_meta_marshal (closure=0x80882d0,
return_value=0x82ed330, n_param_values=137286448, param_values=0xbfffeb70,
invocation_hint=0x82ed330, 
    marshal_data=0x82ed330) at gclosure.c:514
#28 0x40659330 in g_closure_invoke (closure=0x80882d0, return_value=0x82ed330,
n_param_values=137286448, param_values=0x82ed330, invocation_hint=0x82ed330)
    at gclosure.c:437
#29 0x4066cd95 in signal_emit_unlocked_R (node=0x8088308, detail=0,
instance=0x81a88f8, emission_return=0x0, instance_and_params=0xbfffeb70) at
gsignal.c:2474
#30 0x4066c327 in g_signal_emit_valist (instance=0x81a88f8, signal_id=23,
detail=0, var_args=0xbfffecfc "�\001�A@\217.\b\001") at gsignal.c:2195
#31 0x4066c624 in g_signal_emit (instance=0x82ed330, signal_id=137286448,
detail=137286448) at gsignal.c:2239
#32 0x40499436 in gtk_widget_grab_focus (widget=0x81a88f8) at gtkwidget.c:3825
#33 0x40335204 in gtk_entry_button_press (widget=0x81a88f8, event=0x8230d58) at
gtkentry.c:1345
#34 0x4039aac4 in _gtk_marshal_BOOLEAN__BOXED (closure=0x8088670,
return_value=0xbfffee80, n_param_values=2, param_values=0xbfffefb0,
invocation_hint=0xbfffeea8, 
    marshal_data=0x40334f30) at gtkmarshalers.c:82
#35 0x406596c7 in g_type_class_meta_marshal (closure=0x8088670,
return_value=0x82ed330, n_param_values=137286448, param_values=0xbfffefb0,
invocation_hint=0x82ed330, 
    marshal_data=0x82ed330) at gclosure.c:514
#36 0x40659330 in g_closure_invoke (closure=0x8088670, return_value=0x82ed330,
n_param_values=137286448, param_values=0x82ed330, invocation_hint=0x82ed330)
    at gclosure.c:437
#37 0x4066cd95 in signal_emit_unlocked_R (node=0x80886c0, detail=0,
instance=0x81a88f8, emission_return=0xbfffef50, instance_and_params=0xbfffefb0)
at gsignal.c:2474
#38 0x4066c0fe in g_signal_emit_valist (instance=0x81a88f8, signal_id=0,
detail=0, var_args=0xbffff140 "H���H���") at gsignal.c:2205
#39 0x4066c624 in g_signal_emit (instance=0x82ed330, signal_id=137286448,
detail=137286448) at gsignal.c:2239
---Type <return> to continue, or q <return> to quit---
#40 0x40498ab7 in gtk_widget_event_internal (widget=0x81a88f8, event=0x8230d58)
at gtkwidget.c:3563
#41 0x40399062 in gtk_propagate_event (widget=0x81a88f8, event=0x8230d58) at
gtkmain.c:2344
#42 0x40397da6 in gtk_main_do_event (event=0x8230d58) at gtkmain.c:1582
#43 0x4058a8d5 in gdk_event_dispatch (source=0x82ed330, callback=0,
user_data=0x0) at gdkevents-x11.c:2133
#44 0x406b2052 in g_main_dispatch (context=0x80818e8) at gmain.c:1942
#45 0x406b3148 in g_main_context_dispatch (context=0x80818e8) at gmain.c:2492
#46 0x406b3480 in g_main_context_iterate (context=0x80818e8, block=1,
dispatch=1, self=0x8083430) at gmain.c:2573
#47 0x406b3ac3 in g_main_loop_run (loop=0x81ae948) at gmain.c:2777
#48 0x40397663 in gtk_main () at gtkmain.c:1172
#49 0x0804a28e in main ()

Comment 1

[Crispin Flowerday (not receiving bug mail)]

Another data point: a checkout using MOZ_CO_FLAGS="-D 2004-04-29" works fine.

(also note that galeon doesn't crash as it has a workaround for another problem)

Comment 2

[Crispin Flowerday (not receiving bug mail)]

MOZ_CO_DATE="2004-05-03" also works, but 2004-05-05 doesn't

Comment 3

[Crispin Flowerday (not receiving bug mail)]

I've narrowed this down to somewhere between "2004-05-03 12:00" and "2004-05-04
00:00"

checkins in this period: http://tinyurl.com/25lc5

My best guess would suggest that the patch for bug 242111 caused this crash.

Comment 4

[Christopher Blizzard (:blizzard)]

-> over to bryner

Comment 5

[Crispin Flowerday (not receiving bug mail)]

With some of the files built with debugging symbols:

#0  0xbd58540a in ?? ()
#1  0x413887df in nsEventStateManager::PreHandleEvent (this=0x83221e0,
    aPresContext=0x83222b0, aEvent=0xbfffeb50, aTargetFrame=0x833ad60,
    aStatus=0xbfffea88, aView=0x8322bc0) at nsEventStateManager.cpp:919
#2  0x411aa1d2 in PresShell::HandleEventInternal () at nsCOMArray.h:82
#3  0x411a9f51 in PresShell::HandleEvent () at nsCOMArray.h:82
#4  0x414f3e84 in nsViewManager::HandleEvent ()
   from /space/crispin/mozilla/dist/bin/components/libgklayout.so
#5  0x414f3721 in nsViewManager::DispatchEvent ()
   from /space/crispin/mozilla/dist/bin/components/libgklayout.so
#6  0x4150ff99 in GlobalWindowImpl::Deactivate ()
   from /space/crispin/mozilla/dist/bin/components/libgklayout.so
#7  0x400343ea in EmbedPrivate::ChildFocusOut (this=0x831add0)
    at EmbedPrivate.cpp:723
#8  0x40030662 in handle_child_focus_out (aWidget=0x831bb38,
    aGdkFocusEvent=0x82256b8, aEmbed=0x831ad80) at gtkmozembed2.cpp:781
#9  0x4042ec84 in _gtk_marshal_BOOLEAN__BOXED ()

Comment 6

[Crispin Flowerday (not receiving bug mail)]

Attachment: Possible fix

This patch appears to fix the crash for me. It looks like the focusController
is being totally unreffed between the time it is got, and the time it is used.

Comment 7

[Dan M]

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

Comment 8

[Dan M]

Attachment: testcase - crashes builds 20040504 and later

Local testcase. You're three clicks from crashing.

Comment 9

[Dan M]

Comment on attachment 148122 [details] [diff] [review]
Possible fix

Crash began after the deCOMtamination of PIDOMWindow. This patch backs out one
line of the deCOMtamination patch, reinstating the old refcount on the focus
controller. It also fixes the crash. r=danm

Comment 10

[Brian Ryner (not reading)]

Comment on attachment 148122 [details] [diff] [review]
Possible fix

Oops.  When I wrote this, I thought that the strong ref to |ourGlobal| would
ensure that the focus controller didn't go away.  It turns out that the DOM
window ownership model is the docshell ownership model, where children only
have a weak parent pointer.  Since the focus controller is owned by the root
DOM window (via nsWindowRoot), holding a strong ref to a child doesn't
necessarily cause the parent to stay alive.  That's my understanding anyway,
and it explains this bug.