887587 - glib assertion failure when sending email

Status: RESOLVED WORKSFORME

(Thunderbird :: General, defect)

Description

[Colin Percival]

User Agent: Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36

Steps to reproduce:

I'm running thunderbird-17.0.6 on FreeBSD 9.1, with an up-to-date ports tree and packages.  Installed ports include gtk-2.24.19, glib-2.34.3, xorg-7.7, and kde-4.10.3.

I try to send email.


Actual results:

About 20% of the time when I click "Send", thunderbird core dumps after sending the email (I know that it is *after* because people have replied to these emails).

The following message is written to my .xsession-errors file (with varying pid numbers, of course):

(thunderbird:74517): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

The backtrace of the core dump is:

#0  0x00000008085099e7 in g_object_ref (_object=0x8150a8bc0) at gobject.c:2884
#1  0x00000008087b9a93 in g_slist_foreach (list=0x815c200c0, func=0x8085099a0 <g_object_ref>, user_data=0x0) at gslist.c:894
#2  0x000000080a16969c in IA__gdk_window_process_all_updates () at gdkwindow.c:5690
#3  0x0000000809899205 in gtk_container_idle_sizer (data=0x0) at gtkcontainer.c:1360
#4  0x000000080a1392e8 in gdk_threads_dispatch (data=0x826498c40) at gdk.c:512
#5  0x000000080879844b in g_idle_dispatch (source=0x81576cf80, callback=0x80a139290 <gdk_threads_dispatch>, user_data=0x826498c40) at gmain.c:4806
#6  0x0000000808795dfa in g_main_dispatch (context=0x80197ce40) at gmain.c:2715
#7  0x000000080879691d in g_main_context_dispatch (context=0x80197ce40) at gmain.c:3219
#8  0x0000000808796ad4 in g_main_context_iterate (context=0x80197ce40, block=1, dispatch=1, self=0x812515820) at gmain.c:3290
#9  0x0000000808796ba1 in g_main_context_iteration (context=0x80197ce40, may_block=1) at gmain.c:3351
#10 0x0000000803a0b43f in mozilla::places::History::InsertPlace () from /usr/local/lib/thunderbird/libxul.so
#11 0x0000000803a28d6a in mozilla::places::History::InsertPlace () from /usr/local/lib/thunderbird/libxul.so
#12 0x0000000803a28ea7 in mozilla::places::History::InsertPlace () from /usr/local/lib/thunderbird/libxul.so
#13 0x0000000803fbdde9 in XRE_AddStaticComponent () from /usr/local/lib/thunderbird/libxul.so
#14 0x0000000803f7efad in mozilla::hal_impl::GetCurrentNetworkInformation () from /usr/local/lib/thunderbird/libxul.so
#15 0x0000000803de7b60 in mozilla::ipc::DeserializeInputStream () from /usr/local/lib/thunderbird/libxul.so
#16 0x0000000803ff1027 in std::vector<int, std::allocator<int> >::operator= () from /usr/local/lib/thunderbird/libxul.so
#17 0x0000000803ff1039 in std::vector<int, std::allocator<int> >::operator= () from /usr/local/lib/thunderbird/libxul.so
#18 0x0000000803ff11da in std::vector<int, std::allocator<int> >::operator= () from /usr/local/lib/thunderbird/libxul.so
#19 0x0000000803a28847 in mozilla::places::History::InsertPlace () from /usr/local/lib/thunderbird/libxul.so
#20 0x000000080388138e in nsAlertsService::~nsAlertsService () from /usr/local/lib/thunderbird/libxul.so
#21 0x0000000802c9aa43 in XREMain::XRE_mainRun () from /usr/local/lib/thunderbird/libxul.so
#22 0x0000000802c9bb05 in XREMain::XRE_main () from /usr/local/lib/thunderbird/libxul.so
#23 0x0000000802c9bd51 in XRE_main () from /usr/local/lib/thunderbird/libxul.so
#24 0x000000000040264a in _start ()

In the first stack frame, it's clear why the assertion failed:

(gdb) p object
$1 = (GObject *) 0x8150a8bc0
(gdb) p *object
$2 = {g_type_instance = {g_class = 0xaaaaaaaaaaaaaaaa}, ref_count = 2863311530, qdata = 0xaaaaaaaaaaaaaaaa}

I don't know enough about glib/gtk to say for certain, but I'm guessing that objects are written over with 0xaa when they are destroyed.

Going up a frame, g_slist_foreach is just an iterator which calls a function on each member of a linked list.

Going up another frame, it looks like there's a list of windows being updated (redrawn?), and one of them is the destroyed object which causes the assertion failure.  This would fit with the fact that the assertion failure occurs within a few ms of the "compose" window being closed.  The fact that this only occurs occasionally suggests that there might be a race condition happening between window-drawing and window-destroying.

It's possible that this is a gtk bug rather than a thunderbird bug, but I'm not seeing it in any other applications.


Expected results:

Thunderbird should not have crashed.

Comment 1

[Karl Tomlinson (:karlt)]

This looks to be the same issue as bug 879373, but caught a little earlier, which is great thanks.

I don't know what is corrupting old_update_windows before
https://git.gnome.org/browse/gtk+/tree/gdk/gdkwindow.c?h=2.24.19#n5690

Possibly bad reference counting.
I would try GTK+ 2.24.17.

Comment 2

[Colin Percival]

I agree, it definitely looks like the same as bug 879373.  Sorry I didn't notice that bug report before submitting this one -- I was only looking at thunderbird crashes, not firefox.

I'll try downgrading to gtk 2.24.17 and report back (unfortunately since this is not consistently repeatable it may take a few days).

Thanks!

Comment 3

[Colin Percival]

After downgrading to gtk 2.24.17 four days ago I haven't seen this crash recur; so I think you're correct that it's related to some change in gtk.

I can't see anything obvious in the diff between 2.24.17 and 2.24.18, but that's hopefully just because I don't know what to look for, having never used gtk...

Comment 4

[Karl Tomlinson (:karlt)]

I don't see anything wrong with either of these commits, but perhaps one of them might be interacting badly:
https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=4f2725630679966dd1148644105fd5592ac95ec8
https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=692a0e5906c5da7f85c16c9d6cbb0d3ed8b4a576

Comment 5

[Colin Percival]

I have found a way to reproduce this quickly: Holding down the "n" key brings up and sends away a large number of "Advance to next unread message in <folder name>?" windows and seems to trigger exactly the same "window going away" race condition within a few seconds (aka. a few dozen cycles of window appearing and disappearing).

Comment 6

[Colin Percival]

And I can now confirm that reverting https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=692a0e5906c5da7f85c16c9d6cbb0d3ed8b4a576 in GTK 2.24.19 makes the problem go away.  (No idea if this is a case of "GTK bug" or "long-standing Mozilla bug exposed by change in GTK" though.)

Comment 7

[Colin Percival]

Possibly relevant: When I hold down 'n' and see the Confirm windows flashing up, most of them have titles of "Confirm", but occasionally I see a "Confirm <2>".  Given that there should only be one Confirm window present at once, this makes me think that the window-closing isn't happening quite as synchronously as it should be.

Comment 8

[Wayne Mery (:wsmwk)]

Colin, can you still reproduce this?

Comment 9

[Colin Percival]

This bug went away for me when FreeBSD applied the aforementioned fix to GTK in our ports tree.  But that workaround was removed in November 2014 (https://svnweb.freebsd.org/ports?view=revision&revision=373199 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195312) and the problem hasn't come back so clearly it got fixed some time between July 2013 and November 2014, either in Thunderbird or in GTK.

I'd mark this as "fixed" but I don't seem to be able to do that.

Comment 10

[Wayne Mery (:wsmwk)]

Thanks Colin