Starting in the 2002091404 build Talkback data shows crashes at nsPromiseFlatCString::nsPromiseFlatCString, though no changes have been made recently to the nsPromiseFlatString.cpp module. Darin, could this be related to your patch for bug 166792? I noticed the stack is calling nsURLHelper.cpp which you renamed in that bug and checked in on the Friday the 13th. (oooh. ;)) nsPromiseFlatCString::nsPromiseFlatCString [c:/builds/seamonkey/mozilla/string/src/nsPromiseFlatString.cpp line 97] net_ExtractURLScheme [c:/builds/seamonkey/mozilla/netwerk/base/src/nsURLHelper.cpp line 457] nsIOService::ExtractScheme [c:/builds/seamonkey/mozilla/netwerk/base/src/nsIOService.cpp line 425] nsIOService::NewURI [c:/builds/seamonkey/mozilla/netwerk/base/src/nsIOService.cpp line 445] NS_NewURI [../../dist/include/necko\nsNetUtil.h line 107] nsPermissionManager::TestForBlocking [c:/builds/seamonkey/mozilla/extensions/cookie/nsPermissionManager.cpp line 151] XPTC_InvokeByIndex [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp line 106] XPCWrappedNative::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 1996] XPC_WN_CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1267] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 841] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 2804] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 857] js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 932] JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c line 3433] nsJSContext::CallEventHandler [c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp line 1044] nsJSEventListener::HandleEvent [c:/builds/seamonkey/mozilla/dom/src/events/nsJSEventListener.cpp line 184] nsEventListenerManager::HandleEventSubType [c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp line 1183] nsEventListenerManager::HandleEvent [c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp line 2171] nsXULElement::HandleDOMEvent [c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp line 3470] PresShell::HandleDOMEventWithTarget [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6243] nsMenuFrame::OnCreate [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsMenuFrame.cpp line 1736] nsMenuFrame::OpenMenuInternal [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsMenuFrame.cpp line 759] nsMenuFrame::AttributeChanged [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsMenuFrame.cpp line 706] nsCSSFrameConstructor::AttributeChanged [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 10754] StyleSetImpl::AttributeChanged [c:/builds/seamonkey/mozilla/content/base/src/nsStyleSet.cpp line 1588] PresShell::AttributeChanged [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 5241] nsXULDocument::AttributeChanged [c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp line 2206] nsXULElement::SetAttr [c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp line 2750] nsXULElement::SetAttribute [c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp line 1330] nsMenuFrame::OpenMenu [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsMenuFrame.cpp line 741] nsMenuFrame::ToggleMenuState [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsMenuFrame.cpp line 558] nsMenuFrame::HandleEvent [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsMenuFrame.cpp line 421] PresShell::HandleEventInternal [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6212] PresShell::HandleEvent [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6118] nsViewManager::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp line 2098] nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp line 301] nsViewManager::DispatchEvent [c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp line 1909] HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp line 83] nsWindow::DispatchEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1042] nsWindow::DispatchWindowEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1059] nsWindow::DispatchMouseEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 5143] ChildWindow::DispatchMouseEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 5398] nsWindow::ProcessMessage [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 3850] nsWindow::WindowProc [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1308] USER32.dll + 0x3a5f (0x77d43a5f) USER32.dll + 0x3b2e (0x77d43b2e) USER32.dll + 0x3d6a (0x77d43d6a) USER32.dll + 0x41fd (0x77d441fd) nsAppShellService::Run [c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp line 472] main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1524] main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1872] WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1892] WinMainCRTStartup() kernel32.dll + 0x1eb69 (0x77e7eb69)

hmm... the contents of net_ExtractURLScheme didn't actually change... only its name changed. this actually looks like were getting a corrupted nsACString reference passed into nsPermissionManager::TestForBlocking and then passed down into necko, where necko finally tries to use it and dies. there's three different JS callsites to TestForBlocking: http://lxr.mozilla.org/seamonkey/search?string=TestForBlocking i wonder if this doesn't instead have to do with the string changes i made to nsIPermissionManager for bug 157131. that is, in conjunction with someone simply unzipping mozilla ontop of an existing install.

There are a number of bugs logged right now for crashes that started to appear on 9/13 (bug 143824, bug 169068, bug 169217, bug 169199 and bug 169205). Just a coincidence or are they all related somehow? I'm guessing if Darin's string changes went in around 9/13, then a pave over install might be causing most of the recent crashes. When exactly were those changes made Darin? I couldn't tell in the bug.

jpatel: the patch i was referring to landed on the trunk on 8-15.

ok, so the changes made for bug 157131 can't be the cause of this crash. we should have just kept the tree closed on friday the 13th! doh!

9/13 could have just been when someone unzipped a new build on top of a much older one. how many occurances of this crash are we seeing?

nevermind, i answered my own question.. looks like this is getting a lot of hits.

darin: a reporter see this with a clean installation. see bug 169875 (not duped to this bug because 2 different stack traces)

this may be related to bug 169653.

My money would be darin's check-in bug 157131 which changed TestForBlocking's signature. I know there aren't any talkback incidents past 9/13 for this one. It's interesting that many of these crashes, the eax register equates to "http". This would seem solid evidence that TestForBlocking is getting a raw string rather than an ns*String class. I wonder if we're seeing a spike in 9/13 because a lot of people started upgrading from 1.0 on that date? Could the move from component.reg to compreg.dat be an issue as well? The branch uses component.reg and the trunk uses compreg.dat. I'm not sure what happens if they both exist.

resolving this as a duplicate of bug 167174 since that should prevent this sort of crash (according to dougt). *** This bug has been marked as a duplicate of 167174 ***

Reopening since the checkin for bug 167174 didn't fix this crash. There are plenty of crashes after 9/26 when we made build changes to generate the .autoreg file. Could it be possible that users that continue to install new builds over older ones will still see this crash? Do the build changes from bug 167174 require the user to wipe out everything clean and install a fresh build to avoid this crash?

*** Bug 172102 has been marked as a duplicate of this bug. ***

hmm... i wonder... could it be that some third party JS component is calling into the permission manager? could it be that it is not using the correct .xpt file?

I had this bug but I have fixed it by uninstalling and completely deleting the mozilla.org directory. When I re-installed 1.2 the bug was gone - I guess there is some incompatibility between the versions? Maybe the answer is just to make the uninstaller do a more thorough job?!

This went away as a topcrash as soon as we fixed the xpt file linking issue (bug 172586). Duping. *** This bug has been marked as a duplicate of 172586 ***

VERIFIED/dupe