Last Comment Bug 573369 - Browser crash when trying to start browser against a locked profile [@ mozalloc_abort(char const*) ]
: Browser crash when trying to start browser against a locked profile [@ mozall...
Status: NEW
: regression
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: x86 All
: -- critical with 27 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 574139 (view as bug list)
Depends on: 573808
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-20 09:57 PDT by Boris Zbarsky [:bz]
Modified: 2016-03-21 08:29 PDT (History)
43 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
-
-


Attachments

Description Boris Zbarsky [:bz] 2010-06-20 09:57:34 PDT
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.
Comment 1 Shadow912 2010-06-22 07:55:09 PDT
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
Comment 2 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2010-06-22 08:07:13 PDT
Looks like something is initializing XPCOM twice. Can you get stacks for the two calls to NS_InitXPCOM3?
Comment 3 Boris Zbarsky [:bz] 2010-06-23 11:51:40 PDT
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
Comment 4 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2010-06-23 13:56:18 PDT
*** Bug 574139 has been marked as a duplicate of this bug. ***
Comment 5 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2010-06-23 14:08:02 PDT
beltzner says we won't block beta1 for this, but dolske's on it!
Comment 6 Justin Dolske [:Dolske] 2010-06-23 16:55:29 PDT
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?
Comment 7 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2010-06-23 17:07:56 PDT
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.
Comment 8 Justin Dolske [:Dolske] 2010-06-23 17:48:56 PDT
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.
Comment 9 [not reading bugmail] 2010-06-30 02:19:49 PDT
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.
Comment 10 Mike Beltzner [:beltzner, not reading bugmail] 2010-07-19 19:03:07 PDT
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.
Comment 11 Ian C 2011-02-14 03:32:27 PST
How do you start a browser with a locked profile on windows, without rebuilding?
Comment 12 [not reading bugmail] 2011-02-14 16:40:14 PST
Create a new or access a different profile.  Then it might eventually unlock, else log off or restart your pc if it doesn't.
Comment 13 Terrell Kelley 2011-03-09 21:59:48 PST
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.
Comment 14 Steve Thompson 2012-06-05 19:36:38 PDT
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.
Comment 16 Alex Keybl [:akeybl] 2012-06-06 15:28:13 PDT
If this is happening for 3.6, 12, and 13, there's no reason to track for upcoming releases.
Comment 17 Ant 2012-07-01 09:23:35 PDT
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.
Comment 18 yakushabb 2012-08-28 16:44:58 PDT
I'm using firefox with RSSOwl, when attempting multible page open, this bug is effecting me.

thk.
Comment 19 Justin Dolske [:Dolske] 2012-11-30 19:03:33 PST
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.
Comment 20 Terrell Kelley 2012-12-13 15:57:52 PST
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.
Comment 21 Fernando Hartmann 2012-12-17 05:58:27 PST
I can't reproduce this in Windows with FF 18b4 too.
Comment 22 Ryan 2013-01-16 18:36:50 PST
Probably worth closing it then, it's been listed as a unresolved bug on the Firefox notes for ages.
Comment 23 Grzegorz Wiktorowski 2013-01-16 23:46:49 PST
(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).
Comment 24 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2013-01-17 06:09:08 PST
There is a code bug here to fix, identified in comment 7. Please do not close this bug.
Comment 25 Ryan 2013-01-17 11:41:40 PST
Keep it open for another couple of years?
Comment 26 geert.jordaens 2013-03-24 02:41:48 PDT
For what's it worth, Firefox continues to display the firefox already running dialog.

 Firefox 19.0.2 & Windows 7 SP1
Comment 27 kamranm1200 2013-04-02 10:20:08 PDT
Is this bug ever going to be resolved?
Comment 28 Ed Morley [:emorley] 2013-04-09 06:32:08 PDT
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.
Comment 29 realgrouchy 2013-09-17 10:05:31 PDT
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?
Comment 30 Perski 2013-09-18 08:34:23 PDT
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.
Comment 31 Terrell Kelley 2013-09-18 18:18:08 PDT
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.
Comment 32 Terrell Kelley 2013-09-18 18:23:30 PDT
(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.
Comment 33 Perski 2013-09-18 20:03:58 PDT
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?!
Comment 34 Florian Bender 2013-09-19 02:10:09 PDT
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.)
Comment 35 balakrishnan.erode 2013-10-04 15:10:13 PDT
Coulnd't reproduce on linux (ubuntu). Can we change 'platform : x86 All' to be more correct?
Comment 36 Tony Mechelynck [:tonymec] 2013-10-04 17:45:54 PDT
(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
Comment 37 Tony Mechelynck [:tonymec] 2013-10-04 17:49:22 PDT
…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.
Comment 38 c1441975 2013-11-24 03:43:04 PST
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.
Comment 39 Mike S. 2014-05-24 13:14:44 PDT
"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.
Comment 40 geert.jordaens 2014-05-24 13:36:01 PDT
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

Note You need to log in before you can comment on or make changes to this bug.