766316 - parent.lock is not deleted

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[Edoardo Tirtarahardja]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120614114901

Steps to reproduce:

Shutdown Firefox and/or Thunderbird.


Actual results:

Since 13.0.1 (not sure about 13.0 as I skip that version), both Firefox & Thunderbird no longer delete the parent.lock file in the profile folder at normal termination of the application.


Expected results:

The parent.lock file should be deleted to indicate there is no active FF or TB instance is using that profile.

Comment 1

[Matthias Versen [:Matti]]

That means that you can start Firefox and Thunderbird only once without manually deleting the file.
This is the first report about this issue and we would get thousand bug reports if this would happen on every system.
What is special on your system that is causing this ?

Comment 2

[Edoardo Tirtarahardja]

Well, the strange thing that I can start Firefox & Thunderbird anyway.

A quick search on the google:
http://support.mozilla.org/en-US/questions/924342
http://portableapps.com/node/32500
http://forums.mozillazine.org/viewtopic.php?f=31&p=12076763

Also worth note, the issue seems to be only on WinXP (SP3), on my other machine at home with Win7 64 (SP1) it got deleted fine.

I will confirm again on my office WinXP machine once I get to the office today and will give you an update.

Comment 3

[Matthias Versen [:Matti]]

Do you have any problem due to the not deleted parent.lock ?

Comment 4

[Edoardo Tirtarahardja]

It's confirmed that Firefox & Thunderbird 13.0.1 does not delete the parent.lock at shutdown. I made a mistake earlier that stated the issue doesn't exist on Win7 64 on my home machine. I forgot that it still runs on version 12.

The external profile manager app. from Mozilla complains also I saw some people do sanity check via batch file.

There is some suggestion that the change is intentional:
https://bugzilla.mozilla.org/show_bug.cgi?id=294260
to detect the startup crash. However in the discussion they mention that if the lock file does not exist then that means there is no crash.

So I really don't understand why the parent lock is not deleted on clean shutdown of the application.

Comment 5

[Matthias Versen [:Matti]]

Yes, it's intentional, the time from the lock file is used to detect the last startup time.

Comment 6

[Edoardo Tirtarahardja]

But the detection is only needed in case of crash. So what's wrong with deleting the lock file at clean shutdown? Then in the next start up, if the lock file does not exist, then there was no crash, hence there is no need to detect the last startup time anyway.

Comment 7

[Matthias Versen [:Matti]]

Why does it matter of the lock file gets deleted or not ?
The file is an internal data file and nothing more

Comment 8

[Edoardo Tirtarahardja]

As I have stated in comment 4 above, some people check this lock file via batch file to find out whether the profile is used or not. To check whether the file exist or not is very simply in windows batch file.

And from my understanding of the discussion in Bug 294260, the last startup time check may cause performance hit, but this is minimized if the check is only done in case of crash. Hence logically, you still want to delete the lock file at clean shutdown to avoid last start time check on every startup.

Comment 9

[Matthew N. [:MattN]]

(In reply to Edoardo Tirtarahardja from comment #6)
> But the detection is only needed in case of crash. So what's wrong with
> deleting the lock file at clean shutdown? Then in the next start up, if the
> lock file does not exist, then there was no crash, hence there is no need to
> detect the last startup time anyway.

The problem with your proposal is that you're not solving the same problem. Bug 294260 was for startup crash detection not overall crash detection. The existence of the lock file wouldn't tell us whether it was a crash during startup or a crash hours later.

Comment 10

[Edoardo Tirtarahardja]

Hi Matthew,

I'm scratching my head in here. Your algorithm on comment #18@Bug 294260 is to detect startup crash, I got that. What I don't get is how deleting the lock file at clean shutdown prevent you detecting the startup crash?

If the lock file is deleted at clean shutdown as before, then on the next start we won't have this lock file -> No lock file = no crash (any crash, including startup crash), in other word: why we are trying to detect the startup crash if we were not even crashing? The next step is we lock the profile, a lock file is created record timestamp t2 (as step 2 in your algorithm). Then TrackStartupCrashBegin() is called (your step 3), since no prev. lock file (i.e. no t1) then this shouldn't do anything, or even better: if no t1 available then don't even call TrackStartupCrashBegin() (unless it's needed by TrackStartupCrashEnd() later). Then at your step 5, call TrackStartupCrashEnd() to store t2 in toolkit.startup.last_success.

In case of startup crash occured before we reach step 5, then we will have a lock file available for your step 1 in the next start.

Am I missing something in here???

Comment 11

[Matthew N. [:MattN]]

Hello Edoardo,

Sorry, I haven't yet had time to study your proposal closely to see if it would work.  I have it on my TO-DO list.

I just wanted to say that a workaround for most cases (except for when we fallback to a symlink on *nix systems) is that you can just try and delete the lock file in your scripts and if that works then the profile is not in use.

So the script could:
1) for *nix based systems, check if the profile lock is a symlink. If it is then you can't really tell if it's in use
2) Otherwise, try to delete the lock.  This should fail if the lock is actually still valid.

I haven't thoroughly tested this so test it before relying on it. (Make sure that you can't delete non-symlink locks while the profile is actually in use).

I posted this fix here: http://forums.mozillazine.org/viewtopic.php?f=39&t=2490329&p=12162077#p12162077