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.

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]

(whoops, it's already on dev channel, we should at elast prevent it from getting to beta)

[Empty comment from Monorail migration]

I'm having a similar issue on OSX 10.6.4 with Chrome 6.0.447.0.

Chrome does not crash but it will take 30-45 seconds from the load of the page until a location is loaded. The entire length of that time Chrome is almost completely frozen.

If I have Twitter configured to not automatically find my location the delay never happens. If I manually click "Add your location" the delay and freeze happens.

This bug is about Linux.  Can you open a separate one about the Mac issue?  It is plausible it has a different cause.

[Empty comment from Monorail migration]

Any updates on this?

I've been reticent to check twitter.com lately because I'm doing actual work... I just checked now and couldn't get it to crash. Same version, no changes on the system (haven't done any package upgrades). Twitter must have changed something on their side?

Not sure how to proceed with this one: this is the only report, and it's no longer happing.

I now notice the OP says using incognito windows stops the problem; there's very little reason that geolocation would stop crashing when in incognito, which leads me to think it is (was) something the javascript code was doing in response to receiving the geolocaiton result, rather than the result itself, that was causing this crash.

I can't get Twitter to crash anymore with 6.0.458.1 (Official Build 51742) dev. I would vote for marking this closed with the explanation that it was some external-to-Chrome interaction.

On my home laptop (which has been running dev builds too -- previously I thought I had it on beta) twitter never crashed.

As per the comments, Cannot reproduce.

Was only ever seen on one machine, and now can no longer be seen there either.

I came across this bug report and thought I should chime in.

I get this error in chromium on both a Windows machine and Ubuntu Lucid. It doesn't take down Chromium, but does crash the twitter tab - I load the twitter.com page and within 10 seconds or so, I get the window popping up saying the tab has crashed and I can either wait or kill the tab. Waiting just leads the page loading constantly, you can read the page, but it can't be scrolled. I use the Chromium updater tool on Windows and the daily build PPA on Linux, so both builds are pretty up-to-date.

I've been seeing this occur ever since I started using Chromium about a month ago. It does seem rather random though, it doesn't always happen...

@pathios, you maybe seeing another issue: 59913. That should now be fixed on the dev channel.

may this will help, I can get into twitter.com running chromium as root, this means a permissions problems isn't? but where?

I can confirm I also get this error but it resolves itself if I run my browser as root.

14.0.790.0 canary, just ran into the problem

14.0.792.0, openSUSE, same symptoms as https://crbug.com/chromium/47319#c37, 32bit and 64bit archs

Fedora 15, 64bit Chrome 12.0.742.112. Problem exists

I tried removing Site Data for twitter.com, but Chromium also crashed when trying to delete Web Database from UI as well. After that I went to ~/.config/chromium/Default and deleted the whole "databases" subdirectory. Upon deletion twitter.com works again. Therefore I guess there is some problem in the WebDB storage code.

14.0.825.0 under openSUSE seems to work

If you're encountering this on Fedora, it's https://crbug.com/chromium/81413.  I'd love it if you commented on the bug I filed with them: https://bugzilla.redhat.com/show_bug.cgi?id=710276 and asked them why they can't fix it.  ;)

(This bug is from July 2010.  If you are still encountering a problem with this specific bug, then please either star https://crbug.com/chromium/81413 if it applies to you, or open a new bug so your info isn't lost.)

[Empty comment from Monorail migration]