perhaps the same as  issue 40811 ?

backtrace:


#0  _dbus_connection_lock (connection=0x5f004e004f005a) at dbus-connection.c:355
No locals.
#1  0x00007ffff25ecd0d in _dbus_pending_call_get_connection_and_lock 
(pending=0x56191e0) at dbus-pending-call.c:307
No locals.
#2  0x00007ffff25dedde in reply_handler_timeout (data=0x5f004e004f005a) at dbus-
connection.c:3156
        connection = <value optimized out>
        status = <value optimized out>
#3  0x00007ffff2818c0d in ?? () from /usr/lib/libdbus-glib-1.so.2
No symbol table info available.
#4  0x00007ffff4a0e09b in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#5  0x00007ffff4a0d8c2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
No symbol table info available.
#6  0x00007ffff4a11748 in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#7  0x00007ffff4a118fc in g_main_context_iteration () from /lib/libglib-2.0.so.0
No symbol table info available.
#8  0x0000000000ab4110 in base::MessagePumpForUI::RunWithDispatcher (this=0x320b4e0, 
delegate=<value optimized out>, dispatcher=0x56191e0)
    at base/message_pump_glib.cc:195
        state = {delegate = 0x7fffffffc1e0, dispatcher = 0x0, should_quit = false, 
run_depth = 1, has_work = false}
        previous_state = 0x0
        more_work_is_plausible = <value optimized out>
#9  0x0000000000a8ee7b in MessageLoop::RunInternal (this=0x7fffffffc1e0) at 
base/message_loop.cc:205
No locals.
#10 0x0000000000a8ef38 in MessageLoop::RunHandler (this=0x5f004e004f005a, 
dispatcher=0x7ffff2818c00) at base/message_loop.cc:177
No locals.
#11 MessageLoopForUI::Run (this=0x5f004e004f005a, dispatcher=0x7ffff2818c00) at 
base/message_loop.cc:612
        save_state = {<MessageLoop::RunState> = {run_depth = 1, quit_received = 
false, dispatcher = 0x0}, loop_ = 0x7fffffffc1e0, previous_state_ = 0x0}
#12 0x00000000004355af in RunUIMessageLoop (parameters=...) at 
chrome/browser/browser_main.cc:177
No locals.

yep evan seems to be the same

 Issue 40811  has been merged into this issue.

Had either of you opened a webstite that uses geolocation prior to the crash occurring?
The code that uses dbus (in wifi_data_provider_linux) is lazily constructed, so shouldn't have any effect unless 
you do use geolocation.

The link below (read the follow-up mail too) looks like the same sort of crash:

http://lists.freedesktop.org/archives/dbus/2009-February/010945.html

Maybe that helps...

Thanks for the link, I'd just found that one too. Indeed, it looks like a stray pending message timeout is being 
processed on the main thread. 
The wifi data provider runs entirely on its own thread and woks entirely with blocking / synchronous calls, so 
shouldn't  ever need to process async timeouts (on main thread or otherwise)

Hypothesis: the wifi worker thread is posting timers to the main loop's thread, which are occasionally serviced just as they are 
being deleted.
We never need to the main loop to be involved with timers, so perhaps we can just neuter these function calls and stop the pain.
e.g.: http://build.chromium.org/buildbot/try-server/builders/linux/builds/26211/steps/gclient/logs/patch
I've not been able to try that out, as my linux box is awol, and I've not managed to reproduce the problem anyway. If someone else 
gets chance to patch that in and try it out, it would be extremely useful (I know it at least builds & doesn't blow up, thanks to 
bulach)

OK, I managed to test out the patch linked, and it looks good (as in, the code all works fine with timers disabled).

It may worth landing this as a tentative fix, and monitor if these crashes continue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=44216 

------------------------------------------------------------------------
r44216 | joth@chromium.org | 2010-04-11 15:25:56 -0700 (Sun, 11 Apr 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/geolocation/wifi_data_provider_linux.cc?r1=44216&r2=44215

Work-around for DBus crash due to timers firing on the wrong thread.

BUG= 40803 
TEST=run browser & use geolocation.

Review URL: http://codereview.chromium.org/1604023
------------------------------------------------------------------------

joth yes i did... brainbird.net (or any other Status.net site)
they ask for geo location, and i usually have at least one open


OT find funny i did not get most of the emails of this thread :(

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=44221 

------------------------------------------------------------------------
r44221 | laforge@chromium.org | 2010-04-11 17:19:21 -0700 (Sun, 11 Apr 2010) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/375/src/chrome/browser/geolocation/wifi_data_provider_linux.cc?r1=44221&r2=44220

Merge 44216 - Workaround for DBus crash due to timers firing on the wrong thread.

BUG= 40803 
TEST=run browser & use geolocation.

Review URL: http://codereview.chromium.org/1604023

TBR=joth@chromium.org
Review URL: http://codereview.chromium.org/1562022
------------------------------------------------------------------------

The workaround was pushed in 5.0.375.3, haven't heard any reports either way on if this solved it, but I'll 
speculatively mark as fixed awaiting verification.

Chrome Version       : 5.0.371.0 (43913) Ubuntu
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
Firefox 3.x:
IE 7:
IE 8:

What steps will reproduce the problem?
1. doing nothing special, sometimes not even using the browser, it just 
crashs

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.