Closed Bug 745453 Opened 13 years ago Closed 10 years ago

crash in nsAString_internal::Finalize with Norton Confidential 2012

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
12 Branch
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox12 + fixed

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression, reproducible, Whiteboard: [startupcrash])

Crash Data

Attachments

(1 file)

Screenshot of dialog
53.77 KB, image/png
Details
It's a new crash signature that first appeared in 12.0b5 on Mac OS X 10.7 and 10.8. The regression range is: http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=9bfe6330d055&tochange=4b1d4ddf1fb4 Signature nsAString_internal::Finalize More Reports Search UUID 088e7062-fac7-4c30-8853-816282120414 Date Processed 2012-04-14 14:50:59 Uptime 14 Last Crash 20.1 hours before submission Install Age 20.4 hours since version was first installed. Install Time 2012-04-13 18:26:12 Product Firefox Version 12.0 Build ID 20120411064248 Release Channel beta OS Mac OS X OS Version 10.7.3 11D50 Build Architecture amd64 Build Architecture Info family 6 model 30 stepping 5 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0xfffffffffffffff8 App Notes AdapterVendorID: 0x1002, AdapterDeviceID: 0x68a1 Frame Module Signature Source 0 XUL nsAString_internal::Finalize xpcom/string/src/nsSubstring.cpp:188 1 libnortonconfidential12.dylib libnortonconfidential12.dylib@0x5917 2 libnortonconfidential12.dylib libnortonconfidential12.dylib@0x6476 3 libobjc.A.dylib libobjc.A.dylib@0x9f3b 4 Foundation Foundation@0x252ce7 5 CoreFoundation CoreFoundation@0x549a7 6 CoreFoundation CoreFoundation@0x8058d 7 Foundation Foundation@0x1daae 8 libnortonconfidential12.dylib libnortonconfidential12.dylib@0x7ce4 More reports at: https://crash-stats.mozilla.com/report/list?signature=nsAString_internal%3A%3AFinalize
It's #1 top crasher in 12.0b5 on Mac OS X.
tracking-firefox12: --- → ?
Keywords: topcrash
I was able to reproduce this using 10.7. Here are my STR: 1. Start with a fresh Firefox 12 beta build with a fresh profile. 2. Download and install http://www.symantec-norton.com/Norton_Internet_Security_5_for_Mac_p118.aspx 3. Make sure your machine restarts after installation 4. After restart, the Norton Security Assistant should run. 5. Make sure to allow the installation of the Norton toolbar in Beta 4. 6. Check for an update to Firefox and apply the update. 7. Firefox crashes upon startup, and on every subsequent launch there is a startup crash. https://crash-stats.mozilla.com/report/index/bp-c33755ac-2b0e-41eb-b971-b62872120416
Keywords: reproducible
I've reached out to the assignees of the following suspicious Beta 5 landings * bug 725793 * bug 732951 asking for their help in debugging given Marcia's STR. This will likely block our beta 6 go to build (planned for today), so this investigation is urgent.
I can reproduce the crash using STR in comment 2: bp-9f512b5f-50b8-4224-b3e6-929702120416
FWIW, a somewhat more detailed stack from a debug build. I'm still trying to figure out which bug cause the regression... waiting for Try builds with each backed out... Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 XUL 0x00000001029a77a7 nsStringBuffer::Release() + 25 (nsSubstring.cpp:188) 1 XUL 0x00000001029aa614 ReleaseData(void*, unsigned int) + 42 (nsSubstring.cpp:118) 2 XUL 0x00000001029a9359 nsAString_internal::Finalize() + 31 (nsTSubstring.cpp:190) 3 XUL 0x000000010169cf49 nsAString_internal::~nsAString_internal() + 21 (nsTSubstring.h:113) 4 XUL 0x0000000102377be5 nsString::~nsString() + 21 (nsTString.h:55) 5 XUL 0x00000001029133f9 NS_StringContainerFinish_P + 21 (nsXPCOMStrings.cpp:108) 6 libxpcom.dylib 0x00000001006d9e06 NS_StringContainerFinish + 21 (nsXPComStub.cpp:381) 7 libnortonconfidential12.dylib 0x000000010758e918 NSGetModule + 6960 8 libnortonconfidential12.dylib 0x000000010758f477 NSGetModule + 9871 9 libnortonconfidential12.dylib 0x0000000107590ce5 NSGetModule + 16125 10 libnortonconfidential12.dylib 0x000000010759570a NSGetModule + 35106 11 libnortonconfidential12.dylib 0x00000001075a85f6 NSGetModule + 112654
Hmm, both Try builds crash for me after installing the Norton add-on. Also, a self-built debug build from revision FIREFOX_12_0b4_RELEASE also crash. I'm confused. Can someone else test the Try builds please?
(In reply to Mats Palmgren [:mats] from comment #9) > Hmm, both Try builds crash for me after installing the Norton add-on. Also, > a self-built debug build from > revision FIREFOX_12_0b4_RELEASE also crash. I'm confused. Can someone > else test the Try builds please? That's interesting - I'll ask Marcia to take a look when she gets in in the morning. Here's the full list of mozilla-beta bugs fixed in beta 5 in case those suspicious bugs are actually unrelated: https://bugzilla.mozilla.org/buglist.cgi?bug_id=704227%2C724352%2C732951%2C734019%2C735073%2C735749%2C738043%2C738985%2C739793%2C742174%2C743475%2C725793;bug_id_type=anyexact;list_id=2871892;query_format=advanced
(In reply to Alex Keybl [:akeybl] from comment #10) > Here's the full list of mozilla-beta bugs fixed in beta 5 in case those > suspicious bugs are actually unrelated: Some bugs are missing: bug 725793 and bug 738749 which is suspicious (only bug specific to Mac).
Read bug 738349 above.
First bad changeset: http://hg.mozilla.org/releases/mozilla-beta/rev/ca80d75dbcb1 Note: you have to test Opt builds, this add-on crash *all* Fx12 debug builds by hitting a JS_Assert: Assertion failure: cx->runtime->requestDepth || cx->runtime->gcRunning, at js/src/jscntxt.cpp:1293
Blocks: 734019
Keywords: regression
(In reply to Mats Palmgren [:mats] from comment #13) > First bad changeset: > http://hg.mozilla.org/releases/mozilla-beta/rev/ca80d75dbcb1 > > Note: you have to test Opt builds, this add-on crash *all* Fx12 debug builds > by hitting a JS_Assert: > Assertion failure: cx->runtime->requestDepth || cx->runtime->gcRunning, at > js/src/jscntxt.cpp:1293 Which means that Norton is misusing the JSAPI; we should probably blocklist it.
(In reply to Ms2ger from comment #14) > Which means that Norton is misusing the JSAPI; we should probably blocklist > it. It doesn't fulfill blocklisting criteria: https://wiki.mozilla.org/Blocklisting#A_High_Bar In addition, many users want to downgrade Firefox when they see that their AV toolbars are disabled because they think they can't surf safely without them.
(In reply to Mats Palmgren [:mats] from comment #13) > First bad changeset: > http://hg.mozilla.org/releases/mozilla-beta/rev/ca80d75dbcb1 > > Note: you have to test Opt builds, this add-on crash *all* Fx12 debug builds > by hitting a JS_Assert: > Assertion failure: cx->runtime->requestDepth || cx->runtime->gcRunning, at > js/src/jscntxt.cpp:1293 Can you post a backtrace for that?
I commented in bug 734019: that backout bug involved a pretty significant IDL change after beta, so compiled addons are pretty rightly going to be screwed by it in weird ways.
>> Assertion failure: cx->runtime->requestDepth || cx->runtime->gcRunning, at >> js/src/jscntxt.cpp:1293 > Can you post a backtrace for that? The stack trace isn't very interesting: (gdb) bt #0 0x0000000102e8aa3a in js::TypedArray::isArrayIndex () #1 0x0000000102e8aa9c in JS_Assert () #2 0x0000000102d2b145 in JS::AutoCheckRequestDepth::AutoCheckRequestDepth () #3 0x0000000102ce83e1 in JS_DefineFunction () #4 0x0000000106aaf0c5 in NSGetModule () #5 0x0000000106ab326f in NSGetModule () #6 0x0000000106aa903d in NSGetModule () #7 0x0000000106aa9440 in NSGetModule () ... the symbols for #4 ... #7 etc are wrong, those are inside Norton binary code: /Library/Application Support/Symantec/WebFraud/nortonconfidential/components/libnortonconfidential12.dylib So, afaict, it's a direct call to JS_DefineFunction() from the above dll.
Ok, they're clearly misusing JS_DefineFunction in ways that will crash. Can we get a separate bug on that?
I was having some issues testing the tinderbox build, but now I understand the the toolbar injects into the Firefox instance - /Library/Application Support/Symantec/WebFraud/nortonconfidential - so am going to find another 10.7 machine to test on.
Attached image Screenshot of dialog —
Testing on a different 10.7 machine in the lab, I am still having difficulty getting the attached dialog or getting the toolbar installed when I run the tinderbox build - https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-beta-macosx64/1334683860/. As soon as I switch back to FF B5, I have no issues.
Juan thinks Comment 21 might be due to the fact that the process is called "Nightly" instead of Firefox. Is there a way to get a tryserver build that will use the Firefox process instead? In the meantime Juan was working to see if he could rename the process in the tinderbox build.
Juan was able to hack the process so he should be able to verify this bug shortly.
After a little bit of fiddling with the package contents, I can verify that the tinderbox build in comment #21 doesn't crash. 1. First I checked that I could reproduce the crash using Firefox 12.0b5 and Norton Internet Security for Mac (trial version). 2. Then I installed the tinderbox build and edited the following files in the package contents (FirefoxNightly.app/Contents/Info.plist) replacing those instances of "nightly" for "firefox" 3. Then I edited FirefoxNightly.app/Contents/Resources/en.lproj to say "Firefox" 4. I restarted my machine (I don't know if this step is necessary). After this I launched the browser and a moment later the Norton application displayed a dialog prompting me to install the toolbar add-on. I installed it, enabled it, restarted the browser, and this time it did not crash, and the toolbar is showing and working.
I have verified this on: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20100101 Firefox/12.0 beta 6 and Firefox doesn't crash anymore. I have followed the steps from comment2 and after the Norton installation, I performed the update from Firefox 12 beta 3 to Firefox 12 beta 6 using the "releasetest" channel. After the restart, Firefox did not crash. I've also performed exploratory testing after the update on youtube, facebook, google etc and also used the Norton toolbar and everything performed as expected. Just to make sure that the crash is fixed, I've performed an update on "beta" channel from Firefox 12 beta 3 to Firefox 12 beta 5, and after the restart, Firefox crashed, so the crash is fixed in Firefox 12 beta 6. This be the case, can the status and the flags of this bug be changed?
We're unable to reproduce the STR in comment 24 using the FF13 tbpl build in [1]. We verified that the toolbar installed properly, but did not cause the browser to crash on startup. We're going to try doing the same for a recent FF14 nightly build. [1] http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-beta-macosx64/1335298260/
Also unable to reproduce using the STR in comment 24 and the latest FF14 nightly build in [1]. We again verified that the toolbar installed properly, but did not cause the browser to crash on startup. [1] https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-14.0a1.en-US.mac.dmg
One final note - we did reproduce the startup crash on Beta 5, so our STR seem solid. Given this, we won't perform the backout of the backout from https://bugzilla.mozilla.org/show_bug.cgi?id=734019#c34 on Beta 13 or Aurora 14.
There are 5 crashes in 13.0.
Keywords: topcrash
Per Comment 29
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: