lock failed after every xmake command #992

posutsai · 2020-10-12T19:52:28Z

Every time when I enter a xmake command such as xmake build xxx, xmake clean ...., xmake seems to forbid me to conduct next command. It always raise an error as following.

error: <filelock: ..6_64/project.lock>: lock failed!

Also I've tried to run diagnosis and here is the output.

error: @programdir/core/main.lua:284: ...dir/core/sandbox/modules/import/core/project/project.lua:163: <filelock: ..6_64/project.lock>: lock failed!
stack traceback:
    [C]: in function 'error'
    [@programdir/core/base/os.lua:792]: in function 'raise'
    [...dir/core/sandbox/modules/import/core/project/project.lua:163]: in function 'lock'
    [@programdir/actions/build/main.lua:93]:
    [C]: in function 'load'
    [@programdir/core/base/task.lua:520]: in function 'run'
    [@programdir/core/main.lua:282]: in function 'cotask'
    [@programdir/core/base/scheduler.lua:317]:

stack traceback:
	[C]: in function 'error'
	@programdir/core/base/os.lua:792: in function 'raise'
	@programdir/core/main.lua:284: in function 'cotask'
	@programdir/core/base/scheduler.lua:317: in function <@programdir/core/base/scheduler.lua:315>
warning: the current project is being accessed by other processes, please waiting!

I really don't know what's the meaning of "accessed by other processes", since there is no process reading any relevant files and I can't find any information relates to this error in document.

Btw, the error appears when I upgrade to the latest version. It works perfectly in v2.3.1.

The text was updated successfully, but these errors were encountered:

waruqi · 2020-10-13T01:14:02Z

After version 2.3.1, I added a file lock to ensure that only one xmake process is compiling the current project at the same time.

You can check if there are other xmake processes compiling the current project.

posutsai · 2020-10-13T05:18:58Z

If I understand it correctly, there is no other xmake process compiling the current project simultaneously. However, I doubt cause comes from sharing /home directory with other server. @waruqi Is this an issue for xmake?

waruqi · 2020-10-13T05:44:54Z

It works fine for me. Please try to update to the dev branch code first to confirm if the same problem exists. xmake update dev

If you still have the same problem, you can run the following command to get project file lock path.

xmake l core.project.project.filelock
filelock "/Users/ruki/projects/personal/xmake/tests/projects/c/console/.xmake/macosx/x86_64/project.lock"

Then use lsof to see which processes are accessing it when compiling.

$ lsof .xmake/macosx/x86_64/project.lock
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
xmake   14004 ruki    7r   REG    1,4        0 61847353 .xmake/macosx/x86_64/project.lock
ccache  14660 ruki    7r   REG    1,4        0 61847353 .xmake/macosx/x86_64/project.lock
ccache  14663 ruki    7r   REG    1,4        0 61847353 .xmake/macosx/x86_64/project.lock
clang   14680 ruki    7r   REG    1,4        0 61847353 .xmake/macosx/x86_64/project.lock
clang   14681 ruki    7r   REG    1,4        0 61847353 .xmake/macosx/x86_64/project.lock
clang   14685 ruki    7r   REG    1,4        0 61847353 .xmake/macosx/x86_64/project.lock

Of course, there may be other problems that cause lock fail, such as permission issues.

waruqi · 2020-10-13T05:45:54Z

In addition, you can try to create an empty project to compile and confirm whether you have the same problem.

xmake create test
cd test
xmake

posutsai · 2020-10-13T12:34:21Z

I've try the suggestions above. Lock failed error throws the same even on dev version. Also lsof .xmake/linux/x86_64/project.lock returns nothing seems like there's no other process opening the project.lock file. I try the test project as well, and xmake has the same behavior. Thanks for your help.

waruqi · 2020-10-13T13:34:56Z

I added more debug info on test branch. Can you update to test branch and let me see the output? xmake update test

posutsai · 2020-10-13T14:30:27Z

Unfortunately, seems like I am not able to access the test branch from xmake update

error: unable to select version for range 'test'

Should I clone the git repo and build from source? Cause I install my xmake through deb file.

waruqi · 2020-10-13T14:33:12Z

I have pushed test branch to other git mirrors. You can try it again. xmake update test

posutsai · 2020-10-13T15:28:45Z

Sorry it still throws the same error.

error: unable to select version for range 'test'

waruqi · 2020-10-13T15:45:28Z

Very strange, you can leave project directory and run xmake update -vD test or you can also download deb package to install it from ci. https://github.com/xmake-io/xmake/actions/runs/304481726

posutsai · 2020-10-13T16:04:06Z

Here's the diagnosis info xmake update -vD test.

$xmake update -vD test
checking for the unzip ... /usr/bin/unzip
checking for the git ... /usr/bin/git
checking for the gzip ... /bin/gzip
checking for the tar ... /bin/tar
checking for the ping ... /bin/ping
pinging for the host(gitlab.com) ... 28 ms
pinging for the host(gitee.com) ... 87 ms
pinging for the host(github.com) ... 42 ms
/usr/bin/git ls-remote --refs https://gitlab.com/tboox/xmake.git
error: @programdir/core/main.lua:284: ...gramdir/core/sandbox/modules/import/core/base/semver.lua:88: unable to select version for range 'test'
stack traceback:
    [C]: in function 'error'
    [@programdir/core/base/os.lua:792]: in function 'raise'
    [...gramdir/core/sandbox/modules/import/core/base/semver.lua:88]: in function 'select'
    [@programdir/modules/private/action/update/fetch_version.lua:81]: in function 'fetch_version'
    [@programdir/actions/update/main.lua:297]:
    [C]: in function 'load'
    [@programdir/core/base/task.lua:520]: in function 'run'
    [@programdir/core/main.lua:282]: in function 'cotask'
    [@programdir/core/base/scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir/core/base/os.lua:792: in function 'raise'
        @programdir/core/main.lua:284: in function 'cotask'
        @programdir/core/base/scheduler.lua:317: in function <@programdir/core/base/scheduler.lua:315>

Anyway I remove the existing xmake with xmake update --uninstall and install the test version with deb file and conduct the same operation as creating test project.

$ xmake create test_proj && cd test_proj
$ xmake
$ xmake clean

It throws the same error again after xmake clean.

error: <filelock: ..6_64/project.lock>: lock failed!

waruqi · 2020-10-13T16:18:08Z

can you try xmake update github:xmake-io/xmake#test again? thanks

posutsai · 2020-10-13T16:23:20Z

It works! I successfully download the test branch and I do the same thing.

$ xmake create test_proj && cd test_proj
$ xmake
$ xmake clean -D

_LOCKED_NUM     0
[xmake]: [filelock_lock]: lock: 0x2014a70, is_shared: 0
[xmake]: [filelock_lock]: tb_filelock_enter: 0, errno: 9
error: @programdir/core/main.lua:284: ...dir/core/sandbox/modules/import/core/project/project.lua:166: <filelock: ..6_64/project.lock>: lock failed, Bad file descriptor
stack traceback:
    [C]: in function 'error'
    [@programdir/core/base/os.lua:792]: in function 'raise'
    [...dir/core/sandbox/modules/import/core/project/project.lua:166]: in function 'lock'
    [@programdir/actions/clean/main.lua:161]:
    [C]: in function 'load'
    [@programdir/core/base/task.lua:520]: in function 'run'
    [@programdir/core/main.lua:282]: in function 'cotask'
    [@programdir/core/base/scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir/core/base/os.lua:792: in function 'raise'
        @programdir/core/main.lua:284: in function 'cotask'
        @programdir/core/base/scheduler.lua:317: in function <@programdir/core/base/scheduler.lua:315>

I guess it finally logs some information you need. Hope this helps.

waruqi · 2020-10-13T21:18:07Z

Ok, I will look at it.

waruqi · 2020-10-14T01:11:02Z

I added more debug log, can you try run xmake update test again? and let me see the output.

error: unable to select version for range 'test'

Because I failed to push the test branch to gitlab yesterday. It should work now, you can try again. xmake update test

posutsai · 2020-10-14T01:20:40Z

Here's the output this time, please check.

$ xmake
[xmake]: [filelock_open]: file: 0x7                                                      
[xmake]: [filelock_open]: open: 0xe29a70     
filelock_open   userdata: 0x00e29a70
sandbox_core_project.lock       <filelock: ..6_64/project.lock>
trylock ok                                               
sandbox_core_project.lock       <filelock: ..6_64/project.lock>
trylock ok
checking for architecture ... x86_64
[ 50%]: ccache compiling.release src/main.cpp
[ 75%]: linking.release test_proj                            
[100%]: build ok!

$ xmake clean -D
[xmake]: [filelock_open]: file: 0x7
[xmake]: [filelock_open]: open: 0x1412a70
filelock_open   userdata: 0x01412a70
sandbox_core_project.lock       <filelock: ..6_64/project.lock>
_LOCKED_NUM     0       userdata: 0x01412a70
[xmake]: [filelock_lock]: lock: 0x1412a70, is_shared: 0
[xmake]: [filelock_lock]: file: 0x7, fd: 0x6
[xmake]: [filelock_lock]: tb_filelock_enter: 0, errno: 9
error: @programdir/core/main.lua:284: ...dir/core/sandbox/modules/import/core/project/project.lua:168: <filelock: ..6_64/project.lock>: lock f
ailed, Bad file descriptor
stack traceback:
    [C]: in function 'error'
    [@programdir/core/base/os.lua:792]: in function 'raise'
    [...dir/core/sandbox/modules/import/core/project/project.lua:168]: in function 'lock'
    [@programdir/actions/clean/main.lua:161]:
    [C]: in function 'load'
    [@programdir/core/base/task.lua:520]: in function 'run'
    [@programdir/core/main.lua:282]: in function 'cotask'
    [@programdir/core/base/scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir/core/base/os.lua:792: in function 'raise'
        @programdir/core/main.lua:284: in function 'cotask'
        @programdir/core/base/scheduler.lua:317: in function <@programdir/core/base/scheduler.lua:315>

Btw, I remove the whole test_proj for making sure it is not affected by previous version. Is that necessary or maybe I just make things messier, since I find out the address of file lock is different this time?

waruqi · 2020-10-14T01:38:18Z

Btw, I remove the whole test_proj for making sure it is not affected by previous version. Is that necessary or maybe I just make things messier, since I find out the address of file lock is different this time?

It doesn't matter.

What is your Linux distribution and architecture? Very strange. Looking at the log, the file lock has been created and opened normally, and the fd is also correct, but it still reports: Bad file descriptor

posutsai · 2020-10-14T01:41:52Z

The distribution info is as following.

cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"
NAME="Ubuntu"
VERSION="18.04.4 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.4 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

And my architecture is x86_64.

waruqi · 2020-10-14T01:43:24Z

Every time the xmake command is executed normally, try manually deleting the lock file?

xmake -vD
rm .xmake/linux/x86_64/project.lock
xmake clean -vD

I don’t have ubuntu18.04, but it works fine on my ubuntu16.04

posutsai · 2020-10-14T01:50:17Z

It works totally fine if I explicitly remove the project.lock. Should I just do it after every xmake command? Also, it works perfectly on my other ubuntu 18.04 machine. It seems strange for me that it has different behavior as well.

waruqi · 2020-10-14T01:56:02Z

In theory, the file lock will be automatically released when the xmake process exits, and it will not affect the next operation. I will update the code later to further confirm the reason.

posutsai · 2020-10-14T01:57:59Z

Anyway, thanks for helping and I will stay in removing it manually temporarily. Please let me know if need any further information.

waruqi · 2020-10-14T02:17:14Z

I try to close the filelock when the process exits, you can try it again. xmake update test

posutsai · 2020-10-14T02:43:53Z

Sorry I tried and it is still not working.

$ xmake clean -Dv
[xmake]: [filelock_open]: file: 0x7
[xmake]: [filelock_open]: open: 0xa2ca70
filelock_open   userdata: 0x00a2ca70
sandbox_core_project.lock       <filelock: ..6_64/project.lock>
_LOCKED_NUM     0       userdata: 0x00a2ca70
[xmake]: [filelock_lock]: lock: 0xa2ca70, is_shared: 0
[xmake]: [filelock_lock]: file: 0x7, fd: 0x6
[xmake]: [filelock_lock]: tb_filelock_enter: 0, errno: 9
error: @programdir/core/main.lua:288: ...dir/core/sandbox/modules/import/core/project/project.lua:168: <filelock: ..6_64/project.lock>: lock failed, Bad file descriptor
stack traceback:
    [C]: in function 'error'
    [@programdir/core/base/os.lua:792]: in function 'raise'
    [...dir/core/sandbox/modules/import/core/project/project.lua:168]: in function 'lock'
    [@programdir/actions/clean/main.lua:161]:
    [C]: in function 'load'
    [@programdir/core/base/task.lua:520]: in function 'run'
    [@programdir/core/main.lua:286]: in function 'cotask'
    [@programdir/core/base/scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir/core/base/os.lua:792: in function 'raise'
        @programdir/core/main.lua:288: in function 'cotask'
        @programdir/core/base/scheduler.lua:317: in function <@programdir/core/base/scheduler.lua:315>
warning: the current project is being accessed by other processes, please waiting!
project.exit
filelock_close  userdata: 0x00a2ca70
[xmake]: [filelock_close]: close lock: 0xa2ca70
exit

Looks like the file is closed successfully. But if the file accidentally remain unclosed, shouldn't we know from lsof .xmake/linux/x86_64/project.lock? Furthermore, Linux seems take care of those file descriptor automatically.

waruqi · 2020-10-14T03:16:28Z

Looks like the file is closed successfully. But if the file accidentally remain unclosed, shouldn't we know from lsof .xmake/linux/x86_64/project.lock? Furthermore, Linux seems take care of those file descriptor automatically.

Yes, linux will automatically close filelock after the program exits, but the problem is that on your system, you must delete the previous project.lock every time to work properly. Why is this happening, I am not very clear.

waruqi · 2020-10-14T03:29:04Z

I attempt to improve it, you can try it again. xmake update test

posutsai · 2020-10-14T03:39:57Z

It works perfectly. Could you give me some detail about the root cause and how you solve it?

waruqi · 2020-10-14T03:50:17Z

I modified the open mode of filelock.

core/src/xmake/io/filelock_open.c

    tb_long_t tryn = 2;
    tb_filelock_ref_t lock = tb_null;
    while (!lock && tryn-- > 0)
-        lock = tb_filelock_init_from_path2(path, tb_file_info(path, tb_null)? TB_FILE_MODE_RO : TB_FILE_MODE_RW | TB_FILE_MODE_CREAT);
+        lock = tb_filelock_init_from_path2(path, tb_file_info(path, tb_null)? TB_FILE_MODE_RW : TB_FILE_MODE_RW | TB_FILE_MODE_CREAT);
    if (lock) xm_lua_pushpointer(lua, (tb_pointer_t)lock);
    else lua_pushnil(lua);

waruqi · 2020-10-14T03:52:50Z

I have updated to the dev branch. xmake update dev

posutsai · 2020-10-14T03:53:50Z

Thank you very much and hope my issue will make the awesome project like xmake even better.

bridgeQiao · 2023-06-28T07:07:55Z

I have also encountered this issue, and I found that it is because I do not have permission to create files in the current directory. Just chown to your user.

waruqi added the in review label Oct 13, 2020

waruqi added bug fixed and removed in review labels Oct 14, 2020

waruqi added this to the v2.3.8 milestone Oct 14, 2020

waruqi closed this as completed Oct 14, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

lock failed after every xmake command #992

lock failed after every xmake command #992

posutsai commented Oct 12, 2020

waruqi commented Oct 13, 2020

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020

waruqi commented Oct 13, 2020

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020 •

edited

Loading

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020

waruqi commented Oct 14, 2020

posutsai commented Oct 14, 2020 •

edited

Loading

waruqi commented Oct 14, 2020

posutsai commented Oct 14, 2020

waruqi commented Oct 14, 2020 •

edited

Loading

posutsai commented Oct 14, 2020

waruqi commented Oct 14, 2020

posutsai commented Oct 14, 2020 •

edited

Loading

waruqi commented Oct 14, 2020

posutsai commented Oct 14, 2020

waruqi commented Oct 14, 2020 •

edited

Loading

waruqi commented Oct 14, 2020

posutsai commented Oct 14, 2020

waruqi commented Oct 14, 2020

waruqi commented Oct 14, 2020 •

edited

Loading

posutsai commented Oct 14, 2020

bridgeQiao commented Jun 28, 2023

lock failed after every xmake command #992

lock failed after every xmake command #992

Comments

posutsai commented Oct 12, 2020

waruqi commented Oct 13, 2020

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020

waruqi commented Oct 13, 2020

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020 • edited Loading

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020

posutsai commented Oct 13, 2020

waruqi commented Oct 13, 2020

waruqi commented Oct 14, 2020

posutsai commented Oct 14, 2020 • edited Loading

waruqi commented Oct 14, 2020

posutsai commented Oct 14, 2020

waruqi commented Oct 14, 2020 • edited Loading

posutsai commented Oct 14, 2020

waruqi commented Oct 14, 2020

posutsai commented Oct 14, 2020 • edited Loading

waruqi commented Oct 14, 2020

posutsai commented Oct 14, 2020

waruqi commented Oct 14, 2020 • edited Loading

waruqi commented Oct 14, 2020

posutsai commented Oct 14, 2020

waruqi commented Oct 14, 2020

waruqi commented Oct 14, 2020 • edited Loading

posutsai commented Oct 14, 2020

bridgeQiao commented Jun 28, 2023

waruqi commented Oct 13, 2020 •

edited

Loading

posutsai commented Oct 14, 2020 •

edited

Loading

waruqi commented Oct 14, 2020 •

edited

Loading

posutsai commented Oct 14, 2020 •

edited

Loading

waruqi commented Oct 14, 2020 •

edited

Loading

waruqi commented Oct 14, 2020 •

edited

Loading