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]

(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

Fedora 15, fresh reload, recent update, latest chrome, 13.0.782.107, awww snap page when going to twitter.com.  twitter.com/about works, https://support.twitter.com/ works, even signing in here, but returning to profile, awww snap.  Tried clearing cache, cookies, etc.  Nope.

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]

[Empty comment from Monorail migration]

This issue was migrated from crbug.com/chromium/47319?no_tracker_redirect=1

[Monorail components added to Component Tags custom field.]

Good news! Android N Developer Preview implements a new accessibility option: mono sound. I don't think it will be left out in the final version: it's a really requested feature and, if they remove it, it will not make sense that they added it before the final version. You can read more about it at http://www.xda-developers.com/xda-external-link/android-n-now-offers-the-ability-to-playback-audio-in-mono-mode/

Yes, we are introducing the mono feature in N. Thank you for all patience and I apologize for the delay. For those of you with access to the N preview (http://developer.android.com/preview/download.html), please let us know if you have any issues with the feature.

Thank you again.

That's a great news!
Are you going to provide any API to know if "MONO" is enabled/disabled? Some apps use audio socket to communicate to external devices, and it's critical to know if it's stereo/mono actually going out of audio socket.

Oh great!!! I 'll finally be able to enjoy all music on my phone !

Now I'll be completly satisfied with my Nexus 5X !

Android N is only going to have mono sound - or actual pan/balance controls as well (as Samsung-Android/Apple-iOS already have)?

I'm suffering from partial hearing loss in one ear, so I'd only need about 6-8dB louder in my left ear.

With respect to the question in #56 whether you can determine if the user has set the device in mono mode:

Master mono is an integer system setting. The name of the setting is hidden in the API  (we expect typical use through the Settings app) though the string can be used directly.

final boolean masterMono = Settings.System.getInt(getContext().getContentResolver(), "master_mono", 0) != 0;

Re #58 - only mono sound at this point.

[Comment deleted]

I don't want to seem ungrateful, but could Android devs please provide us with a fix for this feature in Android Marshmallow, so we don't have a wait another year? A year is a long time in the life of an Android smartphone, perhaps 25 percent of its lifespan as a useful device. If you want to keep things simple, a fix that permanently sets all audio output to mono would be fine with me, at least, until Android N rolls out.

6.0 is in maintenance mode. It's pretty much just security updates from here on out (unless there ends up being a 6.1 update, which would likely already be almost complete). Features aren't going to be backported by Google (although OEMs are more than welcome to, and many had already included mono audio).

What device do you have that it will take a year to get Android N? Nexus devices are scheduled for release in Q3, and non-Nexus devices mostly don't bother with 0.0.x updates (except for the companies that will probably get Android N out shortly after release anyway).

[Comment deleted]

Motorola Moto G 3rd Gen. This excellent phone will be parked until November 2016, as it has been since I purchased it last October 2015, at which time I discovered that stock Android doesn't provide mono audio. As a matter of policy, Motorola refuses to implement this mod, despite my urging, so I am using an older model LG because LG does provide the mono switch as an accessibility setting. (Kudos to LG)

[Comment deleted]

After this 2 years finally!! Phew.. It's such a reaalllyy long delay. But i'm grateful to hear it

Can we please get the mono option on Nexus 6P?

Considering the implementation of the mono sound option I really hope we can get an audio balance option implemented soon after. Currently the only reason why I can't just run stock Android.

[Comment deleted]

I really don't understand why you guys would take out mono sound after KitKat...It was there, it worked and was absolutely necessary for people with hearing impairment in one of their ears. Really dumb move. Hope you guys fix this ASAP.

My ears work fine, I need this option for a portable soundsystem. Pretty infuriated by the fact that this just doesn't seem to be possible to do. For enjoyers of music everywhere, please.

I have no idea why Google would have taken an ACCESSIBILITY feature out and not replaced it.   Maybe some idiot 22 year old over at Google thought that the term "Mono" was non-inclusive of LGBTQFOFF and a instrument of the global patriarchal conspiracy.  Or maybe they just hate people with hearing loss.  Dunno.  FWIW, I won't buy another Android product until this is replaced.

Hi all, looks like this bug was never closed but Android Nougat did include a Mono option for Android devices (and future versions continue to include it).

If you are on a Nougat (Android 7.0) or higher Android device, but don't see the option in Settings please contact your device manufacturer because Google has added the functionality back to Android ~2 years ago.

Here's an article about it: https://www.androidpolice.com/2016/03/15/android-n-feature-spotlight-sounds-settings-has-a-new-mono-playback-toggle/

Agreed - This is fixed. I directly benefited from the mono option added to Nougat. I had moved to iOS due to this single issue -- with great reservations as I find iOS infuriatingly frustrating. I am now back on Android.

On a side note, I've used both platforms a couple times each over the last 4 years. While Apple was first out of the gate with a mono option, it took them a full year to completely clean my iMessage server registrations so that I can reliably get texts from iPhone users. What an alarming company that is.

The mono option works great on my Pixel!