IssueTracker

Disabling all extensions does not fix the problem.

Enabled log-level=0 and got the following:

$ google-chrome --enable-logging --log-level=0
[20397:20397:1383124398002:ERROR:chrome/app/chrome_dll_main.cc(247)] GLib-GObject: instance of invalid non-instantiatable type `(null)'
Segmentation fault

Adding debug log.

Do you have crash reporting enabled?  If so, a crash id should be dumped, and if you give that to us, then we can look up what caused the crash.

My client_id appears to be B7776A6E-F752-1E5B-E46B-ACD5F961EE30.

I see crash_count: 0, but since I've enabled it I've gotten it to crash twice.

Seems to happen immediately after geolocation is finished.

I only see 2 browser crashes from your client id:

Stack trace:

Thread 0 *CRASHED* ( SIGSEGV @ 0x00000020 )
0xb6c306ca      [libdbus-glib-1.so.2.1.0        + 0x0000d6ca]  
0xb6c30be4      [libdbus-glib-1.so.2.1.0        + 0x0000dbe4]  
0xb6c324f9      [libdbus-glib-1.so.2.1.0        + 0x0000f4f9]  
0xb6c2f17e      [libdbus-glib-1.so.2.1.0        + 0x0000c17e]  
0xb6c07790      [libdbus-1.so.3.4.0     + 0x0001d790]  
0xb6bf73c5      [libdbus-1.so.3.4.0     + 0x0000d3c5]  
0xb6bf9991      [libdbus-1.so.3.4.0     + 0x0000f991]  
0xb6c2a92c      [libdbus-glib-1.so.2.1.0        + 0x0000792c]  
0xb705b5e4      [libglib-2.0.so.0.2400.1        + 0x0003b5e4]  
0xb705f2d7      [libglib-2.0.so.0.2400.1        + 0x0003f2d7]  
0xb705f4b7      [libglib-2.0.so.0.2400.1        + 0x0003f4b7]  
0x08707d34      [chrome         - base/message_pump_glib.cc:195]        base::MessagePumpForUI::RunWithDispatcher(base::MessagePump::Delegate*, base::MessagePumpForUI::Dispatcher*)
0x0870796f      [chrome         - ./base/message_pump_glib.h:59]        base::MessagePumpForUI::Run(base::MessagePump::Delegate*)
0x086e00f3      [chrome         - base/message_loop.cc:214]     MessageLoop::RunInternal()
0x086e0161      [chrome         - base/message_loop.cc:617]     MessageLoopForUI::Run(base::MessagePumpForUI::Dispatcher*)
0x08073625      [chrome         - chrome/browser/browser_main.cc:198]   BrowserMain(MainFunctionParams const&)
0x0806cb4a      [chrome         - chrome/app/chrome_dll_main.cc:861]    ChromeMain
0x0806cf5f      [chrome         - chrome/app/chrome_exe_main_gtk.cc:50]        

Are they the same? I can reproduce it a few more times if you'd like.

I'm guessing geolocation tries to initialize glib-dbus, which is crashing, possibly due to a race condition. Perhaps r50652 fixes this, or cause the crash to happen sooner?

[Empty comment from Monorail migration]

twitter.com appears to have removed the geotagging feature from the web interface. At least, my colleague can no longer find it (I've never seen it before)
I've tried on some other websites (e.g. maps.google.com/maps/m) and I can't recreate this there. Would be interesting to know if anyone else can?
(This is on the same chrome version)

Btw I'm out for a week now, so if this is urgent we may need someone else to look into it.

One more question, Ian.
You mention: "Seems to happen immediately after geolocation is finished."
However, from the log file attached, I don't see any evidence of geolocation working (but this maybe because you already had another tab open that was also using geolocation and so pre-cached the location?)

Could you clarify how you know geolocation is finished? What is the visible indicator on the website?

Cheers

I seem to have been chosen for A/B geolocation testing on twitter as others have mentioned not getting the geo feature on their twitter pages, too.

The way geolocation on twitter (at least for me) is:
1. after logging in and hitting http://twitter.com, a small link with the text "Add your location" and a crosshairs next to it appears directly underneath the "What's Happening" text box.
2. clicking the link requests geolocation from Chrome (Chrome asks for permission and shows the crosshairs in the URL bar). The twitter.com UI switches to a "Getting your location..."
3. when Chrome comes back with a location, the UI element changes to a "in X" link (where X is the best guessed location). If you click on the "in X", a dropdown list of nearby cities and businesses shows up. Clicking on one specifies that location for your tweet.

I said that it seems to happen immediately after geolocation because both crashes that I had yesterday occurred at step 3 when the UI element changed to the link. I did not have to click on anything on the page to get it to crash.

Great, many thanks for the clarification.

Could you try another site or two using geolocation and see if it happens
there?
maps.google.com/maps/m
http://www.google.com/search?q=geolocation+demo

So it looks like the twitter geotagging feature is only available in the US right now
http://twitter.zendesk.com/forums/26810/entries/122236
> Please note that this feature is currently only available for US users - Twitter's @support account will let you know when it's available in other countries.

I connected to twitter via US based proxy, was presented with the geotagging UI, and sucessfully posted some tweets. No crash.
This is on Ubuntu 10.4, and Chrome 6.0.437.3 (Official Build 50164) dev
I've got some passwords in the password manger (just in case this is kwallet interaction)

Ideas?

I tried the demos and it looks like geolocation works fine.

Vague idea:
- does this dev version have the kwallet D-Bus code enabled?
- if so, is this a repeat of http://crbug.com/40803 which we had on geolocation? i.e. kwallet is sometimes causing code to run on the main loop? Perhaps it needs the same work-around as was applied to geolocation.
(but hard to explain why twitter.com would be exposing this, when using the geolocation feature).

I just had it crash a couple more times. It's definitely not timed the same for every crash: sometimes geolocation works and I can click around other parts of twitter.com with no problem. It seems to happen more frequently when I sit on twitter for a few minutes doing stuff in other windows and then come back to the page.

I'm in the US, just updated to a recent version of Chromium (50687), and am on Mint 9 (Ubuntu 10.4).  I still have twitter crash all chromium tabs and windows about half the time when I go to my home page.

Evan, look at Joth's https://crbug.com/chromium/47319#c17.  It does seem like quite a coincidence that the password manager stuff recently went out and we're now seeing this crash.

If 50687 is crashing (as per https://crbug.com/chromium/47319#c19), then moving the dbus initialization to one place in startup in r50652 hasn't helped :(

HenrySchreinerIII: can you get a backtrace of the crash at all? (just to see if it's also dbus in there).

jorlow, joth: the password manager stuff is disabled normally isn't it without an explicit password-store command line option? (well maybe there's some initialization stuff that still runs ... I haven't looked)

For what it's worth, I have "Never save passwords" and "Enable AutoFill to make it easier to fill in forms" (but with no profiles created) checked.

[Empty comment from Monorail migration]