This mutex timeout is a result of the Vault client thinking that another Vault client is accessing one of its cache files (and holding the mutex associated with that file). These are the cache files at ~/.config/SourceGear/Vault_1/Client. This mutex is managed by Mono, and is a system-wide named mutex (in the terminology of the class library documentation), but the name is specific to the path of the file being locked (so multiple users can run their own Vault client instances without having these mutexes collide in shared memory). Are there any mono processes running in the background for the user experiencing the problem?
I don't know Mono's exact implementation of this mutex class, but it seems to create an IPC semaphore array (visible with ipcs) for the user running the client, with mode 600. Since Vault uses multiple instances of this mutex class, each with a different named mutex, Mono must be managing them within a single semaphore array. You may try removing the array (with ipcrm -S <key>) if there are no other running mono processes for that user.
Solaris command line client: timeout
Moderator: SourceGear
Thank you for your reply. I can see that the semaphore array exists
after I run the vault clc. I also tried removing it with ipcrm -S but this
has not helped. Another semaphore set is created and I get the same
error.
I also tried rebooting the linux machine, that does not help either.
The mutex may be getting persisted to disk somewhere, but I am
just speculating. Running the mono process under strace shows mono
waiting (a series of nanosleep() calls) but provides no other insight.
I'd be happy to run any other tests to provide you more data. This problem
was intermittant earlier (~ vault 3.0) and would correct itself after a few
hours. Now, it just never goes away.
I am going to try an older mono version and see what happens. Do
let me know if you think of anything else to try.
after I run the vault clc. I also tried removing it with ipcrm -S but this
has not helped. Another semaphore set is created and I get the same
error.
I also tried rebooting the linux machine, that does not help either.
The mutex may be getting persisted to disk somewhere, but I am
just speculating. Running the mono process under strace shows mono
waiting (a series of nanosleep() calls) but provides no other insight.
I'd be happy to run any other tests to provide you more data. This problem
was intermittant earlier (~ vault 3.0) and would correct itself after a few
hours. Now, it just never goes away.
I am going to try an older mono version and see what happens. Do
let me know if you think of anything else to try.
Ok so I thought I would report back on my findings:
The new build Linda sent me did not help. I still get the mutex
timeout error with mono 1.1.8.3 and "index out of bounds" with
mono 1.1.9.2. I tried removing the semaphore set but that has
no effect either.
I tried mono 1.0.6 and that DOES work with vault 3.1.2 and I
have switched to using that.
If you all think of something else or need more details from me
do let me know.
As a user on unix, I have the following suggestions:
1. Please do provide a tar or zip file with the clc and needed DLLs.
Right now I have to install the vault client on windows, create a zip
file of the dlls and exes that are needed and then install on unix.
2. Any guidance about the mono version we should use would be great.
For instance, it would help knowing which mono version sourcegear QA
used to test.
Thank you.
The new build Linda sent me did not help. I still get the mutex
timeout error with mono 1.1.8.3 and "index out of bounds" with
mono 1.1.9.2. I tried removing the semaphore set but that has
no effect either.
I tried mono 1.0.6 and that DOES work with vault 3.1.2 and I
have switched to using that.
If you all think of something else or need more details from me
do let me know.
As a user on unix, I have the following suggestions:
1. Please do provide a tar or zip file with the clc and needed DLLs.
Right now I have to install the vault client on windows, create a zip
file of the dlls and exes that are needed and then install on unix.
2. Any guidance about the mono version we should use would be great.
For instance, it would help knowing which mono version sourcegear QA
used to test.
Thank you.
-
- Posts: 95
- Joined: Mon Aug 29, 2005 12:39 pm
.zip for Client exe and DLLs:
http://download.sourcegear.com/files/Va ... _3_1_2.zip
http://download.sourcegear.com/files/Va ... _3_1_2.zip