269585 - Trunk crash at nbc.com opening a new window [@ event_processor_callback - our_gdk_io_invoke]

Status: RESOLVED FIXED

(Core Graveyard :: GFX: Gtk, defect)

Description

[Max Alekseyev]

Mozilla linux build 2004111205

I've got a crash at nbc.com on attempt to open video clip. Talkback ID: TB1917444E
Although I'm unable to reproduce the bug intentionally.

Comment 1

[Andrew Schultz]

the video clip opens in a new window, right?  I've been getting similar crashes
recently, but not reproducibly.

Comment 2

[Max Alekseyev]

(In reply to comment #1)
> the video clip opens in a new window, right?  I've been getting similar crashes
> recently, but not reproducibly.

That's true.

Comment 3

[Andrew Schultz]

making a wild guess for a component

Comment 4

[Max Alekseyev]

I've got one more crash similar to this one and bug 269477 while openning a new
window at paypal.com 
Talkback ID: TB1957759H

Comment 5

[Jay Patel [:jay]]

Here's the reporter's incident:
Incident ID: 1917444
Stack Signature	event_processor_callback() 5911e1fd
Product ID	MozillaTrunk
Build ID	2004111205
Trigger Time	2004-11-12 20:51:16.0
Platform	LinuxIntel
Operating System	Linux 2.6.9
Module	libwidget_gtk.so + (0000bb22)
URL visited	
User Comments	
Since Last Crash	3 sec
Total Uptime	3 sec
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.
/builds/tinderbox/SeaMonkey-Release/Linux_2.4.2-2_Clobber/mozilla/widget/src/gtk/nsAppShell.cpp,
line 187
Stack Trace 	
event_processor_callback() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.2-2_Clobber/mozilla/widget/src/gtk/nsAppShell.cpp,
line 187]
our_gdk_io_invoke() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.2-2_Clobber/mozilla/widget/src/gtk/nsAppShell.cpp,
line 77]
libglib-1.2.so.0 + 0xea56 (0xb7c89a56)
libglib-1.2.so.0 + 0x1003d (0xb7c8b03d)
libglib-1.2.so.0 + 0x104f4 (0xb7c8b4f4)
libglib-1.2.so.0 + 0x10724 (0xb7c8b724)
libgtk-1.2.so.0 + 0xa025f (0xb7d7725f)
nsAppShell::Run() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.2-2_Clobber/mozilla/widget/src/gtk/nsAppShell.cpp,
line 304]
nsAppStartup::Run() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.2-2_Clobber/mozilla/xpfe/components/startup/src/nsAppStartup.cpp,
line 221]
main1() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.2-2_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 711]
main() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.2-2_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1802]
libc.so.6 + 0x157f8 (0xb7a547f8)

Comment 6

[timeless]

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

Comment 7

[sairuh (rarely reading bugmail)]

nominating blocker flag so that this can get fixed for tbird 1.0 (see bug
270064). this might've regressed when bug 234620 was fixed.

Comment 8

[Iain MacDonnell]

Incase it matters, I'm seeing this with recent thunderbird builds too:

(gdb)
#0  0x408c3781 in nanosleep () from /lib/i686/libc.so.6
#1  0x408c3649 in sleep () from /lib/i686/libc.so.6
#2  0x08071d1a in ah_crap_handler(int) (signum=11) at nsSigHandlers.cpp:135
#3  0x080729d1 in nsProfileLock::FatalSignalHandler(int) (signo=11)
    at nsProfileLock.cpp:209
#4  0x40641a6a in pthread_sighandler () from /lib/i686/libpthread.so.0
#5  <signal handler called>
#6  0x40c73a68 in event_processor_callback (source=0x87bdee8,
    condition=1086798408, data=0x87bde20) at nsAppShell.cpp:67
#7  0x40463089 in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0
#8  0x40444329 in g_main_dispatch () from /usr/lib/libglib-2.0.so.0
#9  0x40445329 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#10 0x40445643 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
#11 0x40445ce7 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#12 0x4019b7a7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x40c7415e in nsAppShell::Run() (this=0x80e4250) at nsAppShell.cpp:142
#14 0x40b5aa9f in nsAppShellService::Run() (this=0x80e1c90)
    at nsAppShellService.cpp:494
#15 0x0806146e in xre_main(int, char**, nsXREAppData const*) (argc=1,
    argv=0xbfffd1e4, aAppData=0x8078b0c) at nsAppRunner.cpp:1907
#16 0x0805a97e in main (argc=1, argv=0xbfffd1e4) at nsMailApp.cpp:58
#17 0x4083e4c2 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)

Comment 9

[Darin Fisher]

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

Comment 10

[Darin Fisher]

I just hit this in a debug build...

Apparently, the eventQueue parameter passed as the |data| parameter to
event_processor_callback has already been destroyed, or the memory it points to
is corrupt.

Interestingly enough, the fd corresponding to the GIOChannel passed to this
function is still referenced in sCountHashTable with a refcount of 1.  The
corresponding tag is also found under the same key (fd) in sQueueHashTable.

So, it would appear that nsAppShell::Spindown was not called for the nsAppShell
instance that should be keeping an owning reference to the nsIEventQueue in
question.

Oh, but ListenToEventQueue may also be called indirectly via the AppStartup
module.  See nsAppStartup::Observe.  When it receives a nsIEventQueueActivated
event, it passes the nsIEventQueue to ListenToEventQueue, and ListenToEventQueue
never AddRefs the interface pointer.  As a result, if the nsIEventQueue was a
temporary, child "native" event queue pushed to handle a modal dialog for
example, then we could easily hit this problem.

One solution to this crash would be to AddRef the nsIEventQueue in
ListenToEventQueue, and then Release it via a GDestroyNotify function.

Comment 11

[Darin Fisher]

By the way, I encountered this crash after seeing the security dialog for
transitioning from HTTP to HTTPS content.  That's consistent with my child event
queue theory.  Plus, the code in nsEventQueue creates native child event queues
from existing native event queues.

Patch coming up...

Comment 12

[Darin Fisher]

Attachment: v1 patch

Comment 13

[Darin Fisher]

The same patch is probably needed for widget/gtk as well.

Comment 14

[Scott MacGregor]

plussing for the aviary 1.0 branch for tbird

Comment 15

[Christopher Blizzard (:blizzard)]

Are we sure this doesn't create cycles?  I don't remember the ownership model
here, but it was kind of strange with event queues.

Comment 16

[Darin Fisher]

Hmm... you may be correct.  We depend on ListenToEventQueue(..., PR_FALSE) to be
called to trigger g_source_remove, which triggers the release of the event
queue.  But, ListenToEventQueue(..., PR_FALSE) won't happen until the event
queue's destructor runs.  Ok, the patch is invalid.  Perhaps this bug was caused
by ListenToEventQueue(..., PR_FALSE) not running?  Hmm...

Comment 17

[Darin Fisher]

Ah, something else:  looks like nsWindowWatcher also calls ListenToEventQueue.

Comment 18

[Darin Fisher]

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

Comment 19

[Darin Fisher]

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

Comment 20

[Darin Fisher]

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

Comment 21

[Darin Fisher]

Alternate fix for bug 234620 has been checked in.  Waiting to see if that fixed
this bug before resolving this one.

Comment 22

[Darin Fisher]

> Waiting to see if that fixed this bug before resolving this one.

To clarify, I meant that I think we'll have to keep an eye on talkback data to
determine if this crash has been resolved.

Comment 23

[Max Alekseyev]

I've just got a crach trying testcase for bug 271066 (which opens a new window).
Talkback ID: TB2089075H
Mozilla linux build 2004111905

Comment 24

[Andrew Schultz]

Max: Darin's patch went in after that.  You'll need to try yesterday's or
today's build.

Comment 25

[Asa Dotzler [:asa]]

We think this is looking good. no longer an a5 blocker.

Comment 26

[Darin Fisher]

marking fixed based on talkback data.

Comment 27

[Asa Dotzler [:asa]]

This looks good for Thunderbird branch builds as well. Thanks Darin.