849204 - crash in _dbus_watch_invalidate

Status: RESOLVED FIXED

(Core :: DOM: Geolocation, defect)

Description

[Scoobidiver (away)]

It's #7 top crasher in 19.0 on Linux.

Signature 	_dbus_watch_invalidate More Reports Search
UUID	af6eaa86-ac9a-4b99-840d-d579c2130303
Date Processed	2013-03-03 04:14:57
Uptime	13
Last Crash	19 seconds before submission
Install Age	2.8 hours since version was first installed.
Install Time	2013-03-03 01:24:36
Product	Firefox
Version	19.0
Build ID	20130227155931
Release Channel	release
OS	Linux
OS Version	0.0.0 Linux 3.5.0-25-generic #39-Ubuntu SMP Mon Feb 25 18:26:58 UTC 2013 x86_64
Build Architecture	amd64
Build Architecture Info	family 6 model 42 stepping 7
Crash Reason	SIGSEGV
Crash Address	0x4
User Comments	It crashes when I try to access my ownCloud calendar.
App Notes 	
OpenGL: ATI Technologies Inc. -- AMD Radeon HD 6900 Series  -- 4.2.12002 Compatibility Profile Context 9.012 -- texture_from_pixmap
Processor Notes 	sp-processor09.phx1.mozilla.com_30861:2008; exploitablity tool: ERROR: unable to analyze dump
EMCheckCompatibility	True

Frame 	Module 	Signature 	Source
0 	libdbus-1.so.3.7.2 	_dbus_watch_invalidate 	dbus-watch.c:171
1 	libdbus-1.so.3.7.2 	free_watches 	dbus-transport-socket.c:83
2 	libdbus-1.so.3.7.2 	socket_disconnect 	dbus-transport-socket.c:987
3 	libdbus-1.so.3.7.2 	_dbus_transport_disconnect 	dbus-transport.c:509
4 	libdbus-1.so.3.7.2 	_dbus_transport_queue_messages 	dbus-transport.c:1165
5 	libdbus-1.so.3.7.2 	_dbus_connection_get_dispatch_status_unlocked 	dbus-connection.c:4211
6 	libdbus-1.so.3.7.2 	dbus_connection_get_dispatch_status 	dbus-connection.c:4342
7 	libdbus-glib-1.so.2.2.2 	message_queue_prepare 	dbus-gmain.c:71
8 	libglib-2.0.so.0.3400.1 	g_main_context_prepare 	gmain.c:2986
9 	libglib-2.0.so.0.3400.1 	g_main_context_iterate 	gmain.c:3270
10 	libglib-2.0.so.0.3400.1 	g_main_context_iteration 	gmain.c:3351
11 	libxul.so 	nsAppShell::ProcessNextNativeEvent 	nsAppShell.cpp:135
12 	libxul.so 	nsBaseAppShell::DoProcessNextNativeEvent 	nsBaseAppShell.cpp:139
13 	libxul.so 	nsBaseAppShell::OnProcessNextEvent 	nsBaseAppShell.cpp:280
14 	libxul.so 	nsThread::ProcessNextEvent 	nsThread.cpp:600
15 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:238
16 	libxul.so 	mozilla::ipc::MessagePump::Run 	MessagePump.cpp:82
17 	libxul.so 	MessageLoop::Run 	message_loop.cc:208
18 	libxul.so 	nsBaseAppShell::Run 	nsBaseAppShell.cpp:163
19 	libxul.so 	nsAppStartup::Run 	nsAppStartup.cpp:290
20 	libxul.so 	XREMain::XRE_mainRun 	nsAppRunner.cpp:3823
21 	libxul.so 	XREMain::XRE_main 	nsAppRunner.cpp:3890
22 	libxul.so 	XRE_main 	nsAppRunner.cpp:4084
23 	firefox 	main 	nsBrowserApp.cpp:174
24 	libc-2.15.so 	libc-2.15.so@0x2176d 	
25 	libstdc++.so.6.0.17 	libstdc++.so.6.0.17@0x2ed5e0 	
26 	firefox 	firefox@0x26d0 	
27 	firefox 	firefox@0x2a30 	
28 	ld-2.15.so 	ld-2.15.so@0xf3ef

More reports at:
https://crash-stats.mozilla.com/report/list?signature=_dbus_watch_invalidate

Comment 1

[Chris Coulson]

See also this report, which is showing libdbus being used from a non-UI thread:

https://crash-stats.mozilla.com/report/index/c5b40e01-db11-4892-a993-50d8b2130305

0 	libdbus-1.so.3.7.2 	_dbus_watch_invalidate 	dbus-watch.c:171
1 	libdbus-1.so.3.7.2 	free_watches 	dbus-transport-socket.c:83
2 	libdbus-1.so.3.7.2 	socket_disconnect 	dbus-transport-socket.c:987
3 	libdbus-1.so.3.7.2 	_dbus_transport_disconnect 	dbus-transport.c:509
4 	libdbus-1.so.3.7.2 	_dbus_transport_queue_messages 	dbus-transport.c:1165
5 	libdbus-1.so.3.7.2 	do_reading 	dbus-transport-socket.c:851
6 	libdbus-1.so.3.7.2 	socket_do_iteration 	dbus-transport-socket.c:706
7 	libdbus-1.so.3.7.2 	_dbus_transport_do_iteration 	dbus-transport.c:976
8 	libdbus-1.so.3.7.2 	_dbus_connection_do_iteration_unlocked 	dbus-connection.c:1234
9 	libdbus-1.so.3.7.2 	_dbus_connection_block_pending_call 	dbus-connection.c:2415
10 	libdbus-1.so.3.7.2 	dbus_pending_call_block 	dbus-pending-call.c:748
11 	libdbus-1.so.3.7.2 	dbus_connection_send_with_reply_and_block 	dbus-connection.c:3530
12 	libxul.so 	mozilla::nsWifiScannerDBus::SendMessage 	nsWifiScannerDBus.cpp:80
13 	libxul.so 	mozilla::nsWifiScannerDBus::IdentifyDeviceType 	nsWifiScannerDBus.cpp:160
14 	libxul.so 	mozilla::nsWifiScannerDBus::SendMessage 	nsWifiScannerDBus.cpp:96
15 	libxul.so 	mozilla::nsWifiScannerDBus::IdentifyDevices 	nsWifiScannerDBus.cpp:126
16 	libxul.so 	mozilla::nsWifiScannerDBus::SendMessage 	nsWifiScannerDBus.cpp:94
17 	libxul.so 	mozilla::nsWifiScannerDBus::Scan 	nsWifiScannerDBus.cpp:35
18 	libxul.so 	nsWifiMonitor::DoScan 	nsWifiScannerDBus.cpp:324
19 	libxul.so 	nsWifiMonitor::Run 	nsWifiMonitor.cpp:149
20 	libxul.so 	nsThread::ProcessNextEvent 	nsThread.cpp:627
21 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:238
22 	libxul.so 	nsThread::ThreadFunc 	nsThread.cpp:265
23 	libnspr4.so 	_pt_root 	ptthread.c:156
24 	libpthread-2.15.so 	libpthread-2.15.so@0x6d4c 	
25 	libc-2.15.so 	libc-2.15.so@0xeed3e 	

I haven't had a proper look at these crashes yet, but this bug looks related (libdbus isn't thread safe by default):

https://bugs.freedesktop.org/show_bug.cgi?id=54972

... and ...

https://bugzilla.gnome.org/show_bug.cgi?id=683830

Comment 2

[Chris Coulson]

I guess a call to dbus_g_threads_init() will fix these, but this needs to be made quite early (before dbus is used)

Comment 3

[Scoobidiver (away)]

Here are correlations from March 10th:
  _dbus_watch_invalidate|SIGSEGV (11 crashes)
     82% (9/11) vs.  25% (115/468) {2e1445b0-2682-11e1-bfc2-0800200c9a66}
         82% (9/11) vs.  24% (110/468) 2012.10.12.beta
          0% (0/11) vs.   1% (5/468) 2012.11.20.beta
    100% (11/11) vs.  66% (308/468) [e-mail]
          0% (0/11) vs.   0% (1/468) 3.6.4
          0% (0/11) vs.   0% (1/468) 3.7.1
        100% (11/11) vs.  65% (306/468) 3.7.2

Comment 4

[Doug Turner (:dougt)]

this is called on a new thread:

https://mxr.mozilla.org/mozilla-central/source/netwerk/wifi/nsWifiScannerDBus.cpp#39


We probably need to init dbus on that thread.  But... why does it only sometimes fail?  Shouldn't this always fail?

Comment 5

[Karl Tomlinson (:karlt)]

IIUC the init needs to be on the main thread.
Docs for dbus_threads_init_default() say
"Note that this function must be called BEFORE the second thread is started."
http://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html#ga33b6cf3b8f1e41bad5508f84758818a7

There is an init call at http://mxr.mozilla.org/mozilla-central/source/ipc/dbus/RawDBusConnection.cpp#23
but I guess that is not in the default build for this platform (and I don't know whether it would be called first anyway).

Comment 6

[Karl Tomlinson (:karlt)]

(In reply to Doug Turner (:dougt) from comment #4)
> Shouldn't this always fail?

I guess you can get lucky without the locking.

Comment 7

[Doug Turner (:dougt)]

Karl, i can call this twice, right?

http://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html#gac7b8a7001befc3eaa8c6b043151008dc

Comment 8

[Karl Tomlinson (:karlt)]

Don't know about dbus_threads_init() in versions prior to 1.6, about June 2012.

dbus_threads_init_default() can be called "as many times as you want", and I assume that's the function you want.

Comment 9

[Adrian Lungu]

Attachment: patch 1

I see that by the time we make this new init call, there is an already existing thread labeled "gdbus". Could there be another place where the dbus is called even earlier?

Comment 10

[Karl Tomlinson (:karlt)]

Comment on attachment 793091 [details] [diff] [review]
patch 1

Please add a comment to indicate that this is for nsWifiScannerDBus, or whatever is a appropriate.

(In reply to Adrian Lungu from comment #9)
> I see that by the time we make this new init call, there is an already
> existing thread labeled "gdbus". Could there be another place where the dbus
> is called even earlier?

The "gdbus" thread is from GDBusConnection, which perhaps is used on systems
with more recent GIO by some GSettings backends, or dbus menu, or other GIO things.  IIRC GDBus uses its own DBus client implementation instead of the reference implementation in libdbus-1.so.

Comment 11

[Adrian Lungu]

Attachment: patch 2 (comment added)

I added a comment that describe the issue solved.
Results from the try server:
https://tbpl.mozilla.org/?tree=Try&rev=ea530f90c348

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d5af18b5e19c

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d5af18b5e19c

Comment 15

[nandhp]

Will this fix be backported to Firefox 24.1 or to Firefox 25? Or do I have to wait for Firefox 26? (December?)

Comment 16

[Doug Turner (:dougt)]

Comment on attachment 793237 [details] [diff] [review]
patch 2 (comment added)

simple fix.  prevents a init race.

Comment 17

[Alex Keybl [:akeybl]]

Comment on attachment 793237 [details] [diff] [review]
patch 2 (comment added)

Longstanding issue and non-critical, so no need to take this on Beta 25. Looks like this is already on Aurora 26.