I’m trying to clone the pijul’s repository, but the command is awaiting something, and don’t download patches neither finish the command. The command is:
pijul clone https://nest.pijul.com/pijul_org/pijul
Which version of pijul are you using? Is it up-to-date?
It’s version 0.6.1. Installed yesterday in an recently formatted computer, with cargo install pijul
P.D. I’m in Windows 10 64 bits
I just tried cloning through https with no problem. Have you tried with some debugging info, a la
$ RUST_LOG=pijul pijul clone https://nest.pijul.com/pijul_org/pijul
?
It took ~100 seconds for me (I’m on a slow connection right now, so I’m pretty sure that’s a factor).
To me, is not finishing after 30 mins. In Visual Studio Debugger, i can see that the program is stopped in line 103 in .cargo\registry\src\github.com-1ecc6299db9ec823\fs2-0.4.2\src\windows.rs;The line contains:
let ret = kernel32::LockFileEx(file.as_raw_handle(), flags, 0, !0, !0, &mut overlapped);
The stack trace is:
ntdll.dll!NtLockFile() Desconocido
KernelBase.dll!LockFileEx() Desconocido
pijul.exe!fs2::windows::lock_file(std::fs::File * file, unsigned int flags) Línea 103 Desconocido
pijul.exe!fs2::windows::lock_exclusive(std::fs::File * file) Línea 79 Desconocido
pijul.exe!fs2::{{impl}}::lock_exclusive(std::fs::File * self) Línea 105 Desconocido
pijul.exe!sanakirja::transaction::{{impl}}::commit(sanakirja::transaction::MutTxn<()> self) Línea 714 Desconocido
pijul.exe!libpijul::backend::T<sanakirja::transaction::MutTxn<()>, rand::ThreadRng>::commit<rand::ThreadRng>() Línea 1311 Desconocido
pijul.exe!pijul::commands::create_repo(std::path::Path * dir) Línea 130 Desconocido
pijul.exe!pijul::commands::clone::run(clap::args::arg_matches::ArgMatches * args) Línea 101 Desconocido
pijul.exe!pijul::main() Línea 63 Desconocido
pijul.exe!panic_unwind::__rust_maybe_catch_panic() Línea 98 Desconocido
pijul.exe!std::rt::lang_start() Línea 51 Desconocido
pijul.exe!main() Desconocido
[Marco flotante] pijul.exe!invoke_main() Línea 64 C++
pijul.exe!__scrt_common_main_seh() Línea 253 C++
kernel32.dll!00007ffc5aa52774() Desconocido
ntdll.dll!RtlUserThreadStart() DesconocidoOuch, that definitely Windows land - maybe a bug in fs2 in the call to lock_exclusive()? It’s called from sanakirja in transaction.rs and is this line (714):
self.env.lock_file.lock_exclusive().unwrap();
I’m afraid I can’t help you with a test, as I’m on Linux myself, but maybe write a small program that uses fs2, create a File and call lock_exclusive() on it? If that works, then we might be looking at a bug in Sanakirja, but if not then it seems likely to be a problem in fs2.
I’m really not sure what’s going on there. What file system are you working on?
I can confirm that this litte program runs suscessfully in my machine:
let mut contentFile= String::new();
let mut file=File::open("E:/tmp/1364560.csv").unwrap();
file.lock_exclusive();
file.read_to_string(&mut contentFile).unwrap();
print!("Contenido del archivo: {}", contentFile);
In my machine, lock_exclusive works ok. But pijul is waiting something. Including pijul 0.7.0. I think, lock_exclusive is invoked twice on the same file from sanakirja maybe, and the second time, pijul is waiting for the lock.
For reference, LockFileEx is called from lock_exclusive and can wait for unbounded time:
If the file handle was not opened for asynchronous I/O and the lock is not available, this call waits until the lock is granted or an error occurs
When I try to clone the official repo on Windows 10 I get a stack overflow exception. Here’s the log:
Please let me know if you need anything else.
Is it not re-entrant? What happens if you make two calls to file.lock_exclusive()?
I can confirm lock_exclusive is not reentrant. When i make two calls to file.lock_exlusive, the second call is waiting to get the lock, and never gets the lock. The thread is suspended and the program doesn’t advance. With the debugger, in pijul, i can see the stack trace the first time that lock_exclusive is called is:
pijul.exe!fs2::windows::lock_file(std::fs::File * file, unsigned int flags) Línea 103 Desconocido
pijul.exe!fs2::windows::lock_exclusive(std::fs::File * file) Línea 79 Desconocido
pijul.exe!fs2::{{impl}}::lock_exclusive(std::fs::File * self) Línea 105 Desconocido
pijul.exe!sanakirja::transaction::Env::new<&std::path::PathBuf>(unsigned __int64 path) Línea 225 Desconocido
pijul.exe!libpijul::backend::Repository::open<&std::path::PathBuf>(core::option::Option<u64> path) Línea 1214 Desconocido
pijul.exe!pijul::commands::create_repo(std::path::Path * dir) Línea 129 Desconocido
pijul.exe!pijul::commands::clone::run(clap::args::arg_matches::ArgMatches * args) Línea 101 Desconocido
pijul.exe!pijul::main() Línea 80 Desconocido
pijul.exe!panic_unwind::__rust_maybe_catch_panic() Línea 98 Desconocido
pijul.exe!std::rt::lang_start() Línea 51 Desconocido
pijul.exe!main() Desconocido
[Marco flotante] pijul.exe!invoke_main() Línea 64 C++
pijul.exe!__scrt_common_main_seh() Línea 253 C++
kernel32.dll!BaseThreadInitThunk() Desconocido
ntdll.dll!RtlUserThreadStart() Desconocido
This stack trace is diferent from the stack trace of the second call. I put the stack trace of the second call here:
pijul.exe!fs2::windows::lock_file(std::fs::File * file, unsigned int flags) Línea 103 Desconocido
pijul.exe!fs2::windows::lock_exclusive(std::fs::File * file) Línea 79 Desconocido
pijul.exe!fs2::{{impl}}::lock_exclusive(std::fs::File * self) Línea 105 Desconocido
pijul.exe!sanakirja::transaction::{{impl}}::commit(sanakirja::transaction::MutTxn<()> self) Línea 714 Desconocido
pijul.exe!libpijul::backend::T<sanakirja::transaction::MutTxn<()>, rand::ThreadRng>::commit<rand::ThreadRng>() Línea 1377 Desconocido
pijul.exe!pijul::commands::create_repo(std::path::Path * dir) Línea 130 Desconocido
pijul.exe!pijul::commands::clone::run(clap::args::arg_matches::ArgMatches * args) Línea 101 Desconocido
pijul.exe!pijul::main() Línea 80 Desconocido
pijul.exe!panic_unwind::__rust_maybe_catch_panic() Línea 98 Desconocido
pijul.exe!std::rt::lang_start() Línea 51 Desconocido
pijul.exe!main() Desconocido
[Marco flotante] pijul.exe!invoke_main() Línea 64 C++
pijul.exe!__scrt_common_main_seh() Línea 253 C++
kernel32.dll!BaseThreadInitThunk() Desconocido
ntdll.dll!RtlUserThreadStart() Desconocido
@laumann, can i help with more information?
I think lines 713-714 and 732-733 can be simply deleted from transaction.rs in Sanakirja
I think: This lines locks and unlocks the file to commit the change, but the file lock is already taken, because methods new and Drop in Env locks and unlocks the file too. Can i submit a patch deleting those lines?
You’re right. These lines are supposed to implement a cool feature of Sanakirja (immutable transactions running concurrently with a single mutable transaction), but need to be removed until that feature is fully implemented.
Thanks for tracking down the issue, it worked on my version of windows, and on linux. I’ll release a new Sanakirja now (0.8.10).
Done! Thanks! I believe Pijul install should be using the new Sanakirja right away, please come back here if that is not the case.
Thanks for the explanation… but, now pijul is crashing with the error:
thread ‘main’ panicked at ‘called Result::unwrap() on an Err value: Error { repr: Os { code: 158, message: “El segmento ya está desbloqueado.” } }’, src\libcore\result.rs:859
stack backtrace:
pijul don’t show me the stack trace in console with set RUST_BACKTRACE=1
Wow, sorry about that, I just uploaded a new version (0.8.12), which should fix it. Thanks for your help!
It works!!! I cloned the pijul repository sucessfully!