Browser crash when trying to start browser against a locked profile [@ mozalloc_abort(char const*) ]

NEW
Unassigned

Status

()

Core
XPCOM
--
critical
7 years ago
6 months ago

People

(Reporter: bz, Unassigned)

Tracking

({regression})

Trunk
x86
All
regression
Points:
---

Firefox Tracking Flags

(firefox12-, firefox13-, blocking2.0 -)

Details

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

7 years ago
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?
OS: Mac OS X → All
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
Duplicate of this bug: 574139
Summary: Browser crash when trying to start browser against a locked profile → Browser crash when trying to start browser against a locked profile [@ mozalloc_abort(char const*) ]
Assignee: nobody → dolske
Depends on: 573808
beltzner says we won't block beta1 for this, but dolske's on it!
blocking2.0: ? → beta2+
Keywords: relnote
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.
blocking2.0: beta2+ → betaN+
blocking2.0: betaN+ → -

Comment 11

6 years ago
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.

Comment 13

6 years ago
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

5 years ago
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 15

5 years ago
http://support.mozilla.org/en-US/kb/firefox-already-running-not-responding#w_remove-the-profile-lock-file

Updated

5 years ago
tracking-firefox12: --- → ?
tracking-firefox13: --- → ?
If this is happening for 3.6, 12, and 13, there's no reason to track for upcoming releases.
tracking-firefox12: ? → -
tracking-firefox13: ? → -

Comment 17

5 years ago
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

5 years ago
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.

Comment 20

5 years ago
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

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

Comment 22

5 years ago
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.

Comment 25

5 years ago
Keep it open for another couple of years?

Comment 26

4 years ago
For what's it worth, Firefox continues to display the firefox already running dialog.

 Firefox 19.0.2 & Windows 7 SP1

Comment 27

4 years ago
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.
Keywords: relnote

Comment 29

4 years ago
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

4 years ago
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

4 years ago
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

4 years ago
(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

4 years ago
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

4 years ago
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

4 years ago
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.

Comment 38

4 years ago
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

3 years ago
"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

3 years ago
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
Assignee: dolske → nobody
You need to log in before you can comment on or make changes to this bug.