Closed Bug 422018 Opened 17 years ago Closed 17 years ago

spike in google toolbar crashes during 3.0b4pre cycle from users disabling extension compatibility checks [@ libgoogletoolbar.dylib@0x4fbd] [@ googletoolbar.dll@0x4b2f][@ libgoogletoolbar.dylib@0x8420]

Categories

(Core :: General, defect, P2)

Product:
Core
Component:
General
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: dbaron, Unassigned)

Details

(Keywords: relnote, topcrash)

Crash Data

There was a spike in crashes in googletoolbar.dll and googletoolbar.dylib during the 3.0b4pre cycle that's making those crashes show up as the top crash (so far, anyway) in Firefox 3.0b4. They're crashing at a fixed offset in the library (I'm assuming that's what the number breakpad gives us is): 0x4fbd on Mac, 0x4b2f on Windows. Looking at the table for 3.0b4pre, the crashes on Windows appeared to have started in the 2008022200 build ; on Mac with the sample sizes much lower, it's mostly consistent with that start date, except for 2 crashes on 2008021300. I'm not sure how reliable this information is or if it's just because we're trimming old data.
Flags: blocking1.9?
All of these crashes seem to crash on a non-main thread, owned by the google toolbar, but with the main thread having the google toolbar waiting on a convar (Windows). Main thread behavior seems to vary more on Mac.
Ah, so I can fiddle with the URL I get after following links within http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0b4pre to change the 2 weeks to 8 weeks -- so it looks like this got a lot worse around the 21st or 22nd, but was present before then in much lower numbers.
(In reply to comment #0) > They're crashing at a fixed offset in the library (I'm assuming that's what the > number breakpad gives us is): 0x4fbd on Mac, 0x4b2f on Windows. Yes, if breakpad gives you foo.dll@0x1234, that's an offset within the library. (Any offset you see in a result is an offset from the most specific information it gave you.) If we knew someone on the Google Toolbar team, it should be trivial for them to find out where this is crashing. Mark: do you have any contacts on the Google Toolbar team you could point to this bug?
kev or basil might have some contact too...
I do, I'll ping Google PSO and see how they want to address. Is there someone who wants to take lead on our side if there are questions?
best to have the work straight in this bug with questions or comments if that's possible.
+'ing this for now. P2.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Current version of Google Toolbar is not supposed to work on Firefox 3. All those crashes are presumably the result of manual hacking install.rdf in xpi. Currently we are working on the new version of the Toolbar which will support Firefox 3.
Thats great news to hear that people have to go out of their way to run into this problem. We should add this to the release notes as an attempt to keep people from trying to hack max version to get their google tool bar working. Any idea when the new version will be ready?
Keywords: relnote
I filed bug 422939 on a possible way for us to help users avoid shooting themselves in the foot, but it's not going to happen any time soon. It does reflect negatively on us, since a lot of the comments in the crash reports indicate that they don't know why they're crashing. Something like bug 411425 would also help mitigate the problem if the user provides an email address in the crash reporter, since we could tell them that one of their extensions is at fault. I suspect a lot of people just flip the "checkCompatibility" pref to get all their extensions working and don't realize they're causing their own crashes.
we could also think about trying to get users back to a page that has a listing of things they can do to avoid crashes for known issues when we pop the break pad dialog. [restart firefox and show info on how to avoid this and other crashes] maybe this is just an extra tab that we show only on restart that is the result of a breakpad initiated crash. would something like this be possible? We generally always have had a list of workarounds and knowledge of plugins and extensions that are known to crash. We have tried the the e-mail reply with previous reporting system and its work fairly well but part of the problem is that a very small pct. of users actually provide e-mail addresses. if we can get the word out when the browser restarts we would hit a larger number of users with information on key crashes that they can avoid.
I'm entitled to give any dates. I can just promise, that new version of the Toolbar will be out as soon as it's ready.
chofmann: yeah, we could add another URL during the restart that would give them some info. It'd have to be generic though, since we don't know any details of the crash at that point. Still might be useful, just something like "Extensions with known crashes: xyz". I worry that it would get annoying for users experiencing other crashes, though.
For what it's worth, I confirmed that this is what happens when you install google toolbar and turn off extensions.checkCompatibility in such a way that google toolbar is enabled. (Adding the Mac-ppc signature, which is @0x8420.) I got bp-353c0f00-f1f5-11dc-9dac-001a4bd43ed6. It seems like we should probably encourage places that document extensions.checkCompatibility (and maybe also nightly tester tools) to make it clearer that turning off compatibility checks can cause crashes, both immediately, or later (after a future upgrade).
Summary: spike in google toolbar crashes during 3.0b4pre cycle [@ libgoogletoolbar.dylib@0x4fbd] [@ googletoolbar.dll@0x4b2f] → spike in google toolbar crashes during 3.0b4pre cycle [@ libgoogletoolbar.dylib@0x4fbd] [@ googletoolbar.dll@0x4b2f][@ libgoogletoolbar.dylib@0x8420]
Summary: spike in google toolbar crashes during 3.0b4pre cycle [@ libgoogletoolbar.dylib@0x4fbd] [@ googletoolbar.dll@0x4b2f][@ libgoogletoolbar.dylib@0x8420] → spike in google toolbar crashes during 3.0b4pre cycle from users disabling extension compatibility checks [@ libgoogletoolbar.dylib@0x4fbd] [@ googletoolbar.dll@0x4b2f][@ libgoogletoolbar.dylib@0x8420]
One thing we could do on this particular bug is to add the current version of the google toolbar to the the blocklist for firefox 3 betas. As soon as the new toolbar is available we could remove it from the blocklist and allow updates. This would remove our #1 beta4 top crasher and give fx3 beta testers a much better experience. Oleg, do you think google would be ok with this? I was amazed at the number of blog entries and advice out there that basically says "go get the FX3 beta, and don't worry about extension compatiblity; just flip the pref and things should be fine..." A google search for http://www.google.com/search?q=extensions.checkcompatibility&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a reviles many blog posts and articles like this one... http://kakku.wordpress.com/2008/03/11/firefox-beta-4-upgrade-now-and-run-all-your-extensions-extensionscheckcompatibility-false/
Yes, it would be ok, if you will restrict only the current version (3.x) of Toolbar.
kev, oleg, can you also help find someone to look at a possible similar problem with google gears? bug 423157
So, we going to close this out as WONTFIX?
(In reply to comment #19) > So, we going to close this out as WONTFIX? It'd be INVALID, actually. I think the best thing to do is to add it to the blocklist and then close this as INVALID. morgamic: Oleg agreed that putting the current version of the Google Toolbar on the blocklist for Firefox 3 is an appropriate solution to this bug.
don't mark it invalid. lets leave it open to help track the preparation of the blocklist patch and getting the current version of the extension shut off for beta5 and beyond.
choffman, is tracking this in bug 423550 not sufficient?
I'm going to mark this as invalid and leave on the blocker list, just because I'm looking at it, and waiting for a reply will just spend a cycle. Choffman, if you disagree that using bug 423550 is not good enough, just reopen. It seems sufficient to me as others bugs of this type are being created in that component (blocklisting).
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
Usually we don't put the description of a problem (this bug) and the solution to the problem (bug 423550) in different bugs since it breaks down continuity of understanding the the problem, how we got the fix, and follow up on verfication. But the overriding important thing is that we track to a solution, so I guess it's ok.
Pinged Google PSO for an update on when a compatible version of toolbar is available. Their Dev team is (and has been) aware of the issue, and are still working on ironing out the Fx3 compatible release. No firm schedule for a fix at this point. More info as I get it.
Yes, Google Toolbar team is still working on the compatibility issues. By the way, where do you suggest we could send some specific questions on Firefox 3 interfaces?
there are newsgroups, or you can contact the authors of the individual interfaces by reviewing cvs blame for the files.... when in doubt, visit irc.mozilla.org and ask someone for directions.
Crash Signature: [@ libgoogletoolbar.dylib@0x4fbd] [@ googletoolbar.dll@0x4b2f] [@ libgoogletoolbar.dylib@0x8420]
You need to log in before you can comment on or make changes to this bug.