BUILD: Current trunk build STEPS TO REPRODUCE: 1) Start the browser 2) Try to start the browser again with NO_EM_RESTART=1 and using the same profile EXPECTED RESULTS: The "the profile is locked" dialog ACTUAL RESULTS: ###!!! ASSERTION: nsTHashtable::Init() should not be called twice.: 'Error', file ../../dist/include/nsTHashtable.h, line 327 with this stack: #6 0x007ae33f in nsTHashtable<nsBaseHashtableET<nsPtrHashKey<void const>, nsRefPtr<nsThread> > >::Init (this=0x7ffd2c, initSize=16) at nsTHashtable.h:327 #7 0x007ae3b8 in nsBaseHashtable<nsPtrHashKey<void const>, nsRefPtr<nsThread>, nsThread*>::Init (this=0x7ffd2c, initSize=16) at nsBaseHashtable.h:99 #8 0x007ad57e in nsThreadManager::Init (this=0x7ffd20) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/xpcom/threads/nsThreadManager.cpp:91 #9 0x00738717 in NS_InitXPCOM3_P (result=0xbfffddd4, binDirectory=0x1004800, appFileLocationProvider=0xbfffe0c0, staticComponents=0xf6958, componentCount=1) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/xpcom/build/nsXPComInit.cpp:530 #10 0x000aa4c3 in ScopedXPCOMStartup::Initialize (this=0xbfffddd4) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/toolkit/xre/nsAppRunner.cpp:1145 #11 0x000aa6ec in ProfileMissingDialog (aNative=0xa17a90) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/toolkit/xre/nsAppRunner.cpp:1901 Then: ###!!! ASSERTION: oops, JS_SetPrincipalsTranscoder wars!: '!callbacks->principalsTranscoder', file /Users/bzbarsky/mozilla/css-frameconst/mozilla/caps/src/nsJSPrincipals.cpp, line 186 Then: ###!!! ASSERTION: nsTHashtable::Init() should not be called twice.: 'Error', file ../../../dist/include/nsTHashtable.h, line 327 from imgLoader::InitCache and then: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xafafafc7 0x0071e125 in PL_DHashTableFinish (table=0xa19300) at pldhash.c:389 389 table->ops->finalize(table); with this stack: #0 0x0071e125 in PL_DHashTableFinish (table=0xa19300) at pldhash.c:389 #1 0x00740b61 in nsTHashtable<nsBaseHashtableET<nsStringHashKey, nsIAtom*> >::~nsTHashtable (this=0xa19300) at nsTHashtable.h:318 #2 0x00740b75 in nsBaseHashtable<nsStringHashKey, nsIAtom*, nsIAtom*>::~nsBaseHashtable (this=0xa19300) at nsBaseHashtable.h:84 #3 0x00740b89 in nsDataHashtable<nsStringHashKey, nsIAtom*>::~nsDataHashtable (this=0xa19300) at nsDataHashtable.h:55 #4 0x0074028f in NS_PurgeAtomTable () at /Users/bzbarsky/mozilla/css-frameconst/mozilla/xpcom/ds/nsAtomTable.cpp:223 #5 0x007366b4 in mozilla::ShutdownXPCOM (servMgr=0x0) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/xpcom/build/nsXPComInit.cpp:910 #6 0x0073671b in NS_ShutdownXPCOM_P (servMgr=0xa1fda4) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/xpcom/build/nsXPComInit.cpp:755 #7 0x000aa664 in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0xbfffddd4) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/toolkit/xre/nsAppRunner.cpp:1077 #8 0x000aadd9 in ProfileMissingDialog (aNative=0xa17a90) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/toolkit/xre/nsAppRunner.cpp:1939 Pretty darned sure this is a somewhat recent regression.

I've confirmed this issue on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a6pre) Gecko/20100622 Minefield/3.7a6pre BuildID: 20100622040308 http://crash-stats.mozilla.com/report/index/bp-5250d1fb-de9a-44d9-885a-29eb62100622 http://crash-stats.mozilla.com/report/index/bp-0b76b443-e631-44ca-952c-67a9f2100622 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a6pre) Gecko/20100622 Shredder/3.2a1pre BuildID: 20100622033253 http://crash-stats.mozilla.com/report/index/bp-b667c688-f471-4897-a79a-2cb762100622

Looks like something is initializing XPCOM twice. Can you get stacks for the two calls to NS_InitXPCOM3?

First stack: #0 NS_InitXPCOM3_P (result=0xbfffdcb0, binDirectory=0x1004800, appFileLocationProvider=0xbfffe220, staticComponents=0xf6958, componentCount=1) at /Users/bzbarsky/mozilla/vanilla/mozilla/xpcom/build/nsXPComInit.cpp:481 #1 0x000aabd3 in ScopedXPCOMStartup::Initialize (this=0xbfffdcb0) at /Users/bzbarsky/mozilla/vanilla/mozilla/toolkit/xre/nsAppRunner.cpp:1145 #2 0x000ab520 in ProfileLockedDialog (aProfileDir=0x1009600, aProfileLocalDir=0x1009c00, aUnlocker=0x0, aNative=0xa17a10, aResult=0xbfffe2b8) at /Users/bzbarsky/mozilla/vanilla/mozilla/toolkit/xre/nsAppRunner.cpp:1827 #3 0x000aeff6 in SelectProfile (aResult=0xbfffe2b8, aNative=0xa17a10, aStartOffline=0xbfffe2b4, aProfileName=0xbfffe140) at /Users/bzbarsky/mozilla/vanilla/mozilla/toolkit/xre/nsAppRunner.cpp:2266 #4 0x000b1482 in XRE_main (argc=3, argv=0xbfffe588, aAppData=0xa0eb80) at /Users/bzbarsky/mozilla/vanilla/mozilla/toolkit/xre/nsAppRunner.cpp:3258 #5 0x00002862 in main (argc=3, argv=0xbfffe588) at /Users/bzbarsky/mozilla/vanilla/mozilla/browser/app/nsBrowserApp.cpp:158 Second stack: #0 NS_InitXPCOM3_P (result=0xbfffdf34, binDirectory=0x1004800, appFileLocationProvider=0xbfffe220, staticComponents=0xf6958, componentCount=1) at /Users/bzbarsky/mozilla/vanilla/mozilla/xpcom/build/nsXPComInit.cpp:481 #1 0x000aabd3 in ScopedXPCOMStartup::Initialize (this=0xbfffdf34) at /Users/bzbarsky/mozilla/vanilla/mozilla/toolkit/xre/nsAppRunner.cpp:1145 #2 0x000aadfc in ProfileMissingDialog (aNative=0xa17a10) at /Users/bzbarsky/mozilla/vanilla/mozilla/toolkit/xre/nsAppRunner.cpp:1901 #3 0x000b1513 in XRE_main (argc=3, argv=0xbfffe588, aAppData=0xa0eb80) at /Users/bzbarsky/mozilla/vanilla/mozilla/toolkit/xre/nsAppRunner.cpp:3264 #4 0x00002862 in main (argc=3, argv=0xbfffe588) at /Users/bzbarsky/mozilla/vanilla/mozilla/browser/app/nsBrowserApp.cpp:158

beltzner says we won't block beta1 for this, but dolske's on it!

I don't think this actually has anything to do with prompts bug 573808, which is what we were talking about before. bp-b667c688-f471-4897-a79a-2cb762100622 shows this crashing at link 1902, in the xpcom deconstructor, presumably it failed to in init and is in a bad state now? 1901 rv = xpcom.Initialize(); 1902 NS_ENSURE_SUCCESS(rv, rv); Is this expected to crash if it tried to init XPCOM again? Or is the right fix to just find the previous caller that inited xpcom and make them play well together?

This bug is precisely that the prompt service is failing here: http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#1880 Because of this, ProfileLockedDialog is returning some error code instead of NS_ERROR_ABORT. _ABORT will shut down the app properly, while any other code will let it keep running and then it tries to initialize XPCOM again.

Ah, I see now. Yes, my patch in bug bug 573808 prevents the ConfirmEx at nsAppRunner.cpp#1880 from failing, so everything then works. But it seems to me that the bug _here_ is that if somthing in SelectProfile() fails, it should still be able to call ProfileMissingDialog(). So either the first ScopedXPCOMStartup has an unclean shutdown (such that the second one fails), or ScopedXPCOMStartup isn't ever supposed to be attempted again (in which case we need to sprinkle in some NS_ERROR_ABORTs to ensure it doesn't try). I don't know which approach is correct, though sprinking in some rv's should be really easy.

FWIW, I seem to be seeing this locked profile dialog at least once maybe twice a day on a nightly lately after 5 shutdowns on windows 7. I have several profiles, and I use -P. Though, not sure if its crashing first/after. Restarting my pc fixes a locked profile situation.

Dolske, moving this to betaN, but if we could get it for 3 or 4, that'd be grand. Hits testers more than real users, I suspect.

How do you start a browser with a locked profile on windows, without rebuilding?

Create a new or access a different profile. Then it might eventually unlock, else log off or restart your pc if it doesn't.

Every time I try (using -no-remote and opening the same profile twice), I always get the "Firefox is already running" warning, and have since at least beta 8 I was thus surprised to see this on the list of known issues for the RC. Windows XP SP 3.

I am also having this problem of "Firefox is already running" and it is happening to me on W/XP with 3.6, 12, and now 13. System had crashed (running under VMware) and recovered it only to find that (1) had to upgrade to 12. 12 failed as stated above. Regressed back to 3.6 and it failed as above. Migrated up to 13 just a few minutes ago and it is now failing with the same problem. How does one unlock the profile? I don't want an eventually unlock, I want it unlocked. I have enough to do to recover this W/XP system to also have to play games with FF.

If this is happening for 3.6, 12, and 13, there's no reason to track for upcoming releases.

A consistent problem occurs when using profiles with firefox 12 or 13 versions, i.e. using the "-p" argument with Windows 7. The first time you start up firefox with profiles enabled, a normal browser session occurs withthe profile selection window. When the user terminates their firefox session as normal using the "Exit" option, the browser windows closes as expected, but the firefox process remains active in the background. With previous version of firefox the "Exit" would have also ended the firefox process normally. Any subsequent start-up of the firefox browser will then complain about a locked session file because the previous firefox session has not terminated and is still active as a background process. Terminating the firefox process using the windows task manager will clear the problem. Clearly something changed during version 12 that is still present with the latest version 13.0.1 that cause profile session start-up of firefox to remain active after the user has requested to terminate normally.

I'm using firefox with RSSOwl, when attempting multible page open, this bug is effecting me. thk.

Hmm, earlier comments seem to indicate this was an issue on all platforms, but I can't trigger a crash on OS X now. Is this still an issue on Windows/Linux? I don't have a box handy to check with.

As I stated, I haven't been able to trigger this crash in Windows for a long time. I don't believe I've tried it in Linux.

I can't reproduce this in Windows with FF 18b4 too.

Probably worth closing it then, it's been listed as a unresolved bug on the Firefox notes for ages.

(In reply to Ryan from comment #22) > Probably worth closing it then, it's been listed as a unresolved bug on the > Firefox notes for ages. Maybe it's quite reasonable. I haven't experienced the crash since version 17.0 (for the last 2 months with 17.0, 17.0.1, & 18.0).

There is a code bug here to fix, identified in comment 7. Please do not close this bug.

Keep it open for another couple of years?

For what's it worth, Firefox continues to display the firefox already running dialog. Firefox 19.0.2 & Windows 7 SP1

Is this bug ever going to be resolved?

Removing relnote keyword, since it's no more worthy of mention than many of our other crashes/SUMO FAQ pages that don't appear on our relnotes. It also cannot be that critical if we haven't fixed it since the bug was filed, and IMO having the same unfixed issue show up on relnote after relnote looks really bad.

This still appears on the release notes as of FF 24 (https://www.mozilla.org/en-US/firefox/24.0/releasenotes/). Is that intentional, or was the change made in Comment 28 not carried over to some other list?

Really surprised to see this bug having been around for this long? This has been happening to me a lot lately using FF 23. Once hung, I can't even use Task Mgr. to end task it. Very annoying that reboot seems to be the only fix. Running on Win 7 64-bits. Made lots of searches and lots of other people seem to have the very same problem. This is happening for "normal" browser usage.

Hanging is not a crash, Perski. It sounds like you have a different bug. And I still say I cannot reproduce this bug. Firefox doesn't crash. It just pops up a warning and then exits. That's not crashing, either. Crashing would mean that Firefox exits unexpectedly, usually meaning it would display the crash dialog. It does not mean it exits too quickly. We really need to confirm this bug still exists, not just pretend it doesn't exist because you don't want to look bad. If it's an known bug, it's a known bug. If, as I suspect, it's an old bug that no longer exists, then we can remove it on those grounds. We should never, ever do something in Firefox to deceive people because we think doing otherwise makes us look bad. Lying is not an option. A relnote can only be removed once the bug is resolved.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #24) > There is a code bug here to fix, identified in comment 7. Please do not > close this bug. A coding bug that does not actually manifest is not an actual bug. A bug is something a user can actually run into. That's why we need to check. If it can still be reproduced, keep it. Or, if the relnote thing is so important, rewrite the bug so that it only happens in certain circumstances, allowing us to legitimately remove the relnote instead of just removing it because it makes us look bad. Also, if it's as easy as you guys imply, why the delay on fixing it? Just put in those aborts and be done with it. It may not be top priority, but it is supposed to be rather easy. Heck, I'd look at doing it myself if I still supported the Firefox project in that way after the needless removal of the addon bar with extremely faulty logic that no one cares about.

Hanging/crashing...?! I believe I have the same symptoms others are describing in here. You use FF for a while, you close out. You then try to open up FF again, but get the annoying popup saying FF is already running. You go to Task Manager, you in fact see FF running in the background, try to end task it, but can't. Only solution seems to be a reboot at this point. Driving me nuts! And if you google this, you find a LOT of others with the very same problem. What is really strange is why can't you end task it?! That is the most annoying part of this whole thing. I haven't come across any other software that when it hangs/crashes doesn't let me end task it?!

This bug is about crashing only, not hanging. Please don't add comments if you don't have any NEW information to provide, or provide patches. (In reply to Terrell Kelley from comment #32) > is supposed to be rather easy. Heck, I'd look at doing it myself if I still > … after the needless removal of the addon bar with extremely faulty logic > that no one cares about. That has not happened yet. So please feel free to fix this ;). (And you can always stick to ESR for some extra time with the addon bar.)

Coulnd't reproduce on linux (ubuntu). Can we change 'platform : x86 All' to be more correct?

(In reply to balakrishnan.erode from comment #35) > Coulnd't reproduce on linux (ubuntu). Can we change 'platform : x86 All' to > be more correct? Some people can't reproduce it on Windows eithre (comment #20), others can (comment #26). The fact that one particular tester couldn't reproduce it on platform X is thus not enough to decide that it cannot happen anymore on platform X. If, during a long enough time period, no one can reproduce it on any platform, it will be

…RESOLVED WORKSFORME. Otherwise, if (during a long enough period of time) several people test it on all three platforms and can only reproduce it on one of them, it may be downgraded to that platform. That's the problem with intermittent bugs, or bugs that only some people can reproduce and others not: it's hard to tell exactly when they've stopped happening.

I wanted to let you know this issue is still a problem. I'm running Arch linux. I started getting the "firefox is already running" dialog when i upgraded to firefox 24. I'm now using 25.01 and its still happening. I get the same error with a clean install of windows 7 and firefox 25.01. It happens frequently and its really annoying.

"Firefox is already running error" can be fixed by encoding firefox to make the "red X close" the same exact process as the current "file then exit". This will prevent "Firefox is already running error". Now the way to do this I will leave this up to the developers and their coding expertise.

In addition to comment #26, I've resolved the issue for me amsterdam by uninstalling a security module and installing the latest version of the security module . The security module is used while reading the Belgian Electronic Identity Card. http://eid.belgium.be/nl/binaries/eid-mw-4%2E0%2E4-0%2E1253%2Efc16%2Ex86_64_tcm227-178463.rpm http://eid.belgium.be/nl/binaries/eID-QuickInstaller-407-7453-signed_tcm227-246722.exe