1550806 - "Unable to start the application" when attempting a bisection when parent.lock in profile

Status: REOPENED

(Testing :: mozregression, defect, P3)

Description

[(No longer employed by Mozilla) Aaron Klotz]

mozregression-gui 0.9.38 for Windows
Win10 1809 64-bit

STR:
Start a bisection for Firefox 64 shippable from 2019-04-29 to 2019-05-07. I had it set to clone my default profile.

Expected:
Mozregression can run the various Firefox builds that it downloads.

Actual:
Every time it tries to run a build, mozregression throws up a "Unable to start the application" error. This happens for every single build that it downloads.

Comment 2

[Ian Moody [:Kwan] (UTC+1)]

In the interim, if you use the cli version (pip install --user mozregression) and pass the --allow-downgrade arg it should work.

mozregression -g 2019-04-29 -b 2019-05-07 --arg="--allow-downgrade" --profile-persistence clone -p <path/to/your/profile>

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

This has nothing to do with profile downgrading and everything to do with the presence of parent.lock in the cloned profile.

At the very least, we need to produce a more useful error message.

Comment 4

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I can confirm this. I had to re-run nearly each Firefox build, because of this issue.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:wlach, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[William Lachance (:wlach)]

I believe this is a duplicate of bug 1464127

Comment 7

[William Lachance (:wlach)]

Oh wait, sorry, re-reading the bug. It appears to be another issue.

Comment 8

[William Lachance (:wlach)]

So I tried to reproduce this problem by creating a temporary "parent.lock" file in a copied profile, but it seems to still work fine. Does the file need to have some specific content for the error to occur?

At the request of the relman bot, I'm going to set the priority flag to P3 but note that I can't guarantee resolution times for mozregression bugs since maintaining this project is not technically in my job description. If this is blocking your work, feel free to pick this up or perhaps file a PI request. I can give pointers on where in the codebase to make a fix.

Comment 9

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to William Lachance (:wlach) (use needinfo!) from comment #8)

So I tried to reproduce this problem by creating a temporary "parent.lock" file in a copied profile, but it seems to still work fine. Does the file need to have some specific content for the error to occur?

According to the code, the lock file is opened by a process with exclusive access, so that any attempts by another process to open that file will fail.