Invalid memory address or nil pointer dereference, in 1.4.3 on Debian testing #260
Comments
|
Wow. These "Fstat failed" messages mean that we have an open file descriptor to the file, but could still not read the attributes of the file. But in any case, gocryptfs should not crash! The crash is inside the go-fuse library, do you run Debian testing? |
|
Yes, we recently uploaded a new For what is worth, I think NFS refused to authenticate for a moment, possibly after a Kerberos ticket renewal. Then Gocryptfs crashed. Some type of blocking would probably be preferable. Thank you! |
|
I'll see if I can spot the problem next week or the week after - i guess the chance of getting this to reproduce is slim? |
|
I have only had the kernel for two days, so we may get lucky. (I can also expire the ticket manually.) What are we looking for? Thank you! |
|
It happened again. Here is the log, this time from Here is the corresponding |
|
Unfortunately I'm abroad without my pc right now and can't really do much for another 10 days or so. Maybe try v1.6 and see if the same thing happened? You could just download the release and replace your gocryptfs binary. |
|
Please do not worry. I am using an older kernel. Have a good trip! Thank you! |
|
Thanks :) |
gocryptfs user Felix Lechner reported a nil pointer dereference in GetAttr: rfjakob/gocryptfs#260 The crash is in line n.setClientInode(fi.Ino) because fi is nil. This can happen when file.GetAttr() returns an error code other than ENOSYS and EBADF. For gocryptfs, this can only happen when an open file descriptor breaks. In this case it was triggered by a failing NFS volume. Fix the crash by erroring out for error codes that are not handled by the retry-by-path logic.
|
I think I found it. Can you test rfjakob/go-fuse@b11e293 ? I have attached a static gocryptfs v1.6 build that includes the patch, but it looks like it should also apply cleanly to the go-fuse version in Debian. gocryptfs.zip (why zip? github does not support tar.gz/xz attachments!) |
|
Thank you for sending the patched version. I cannot conclusively test the patch, as NFSv4 in recent Debian kernels no longer withdraws access rights when a Kerberos ticket is deleted, but your patched version has been running flawlessly. Most notably, there have been no more crashes, compared to one or two a day before. I recommend the adoption of this fix upstream. Thank you for your excellent customer support! |
|
Great, thanks for testing! Maybe you can comment "tested and fixed the issue for me" at hanwen/go-fuse#232 ? |
gocryptfs user Felix Lechner reported a nil pointer dereference in GetAttr: rfjakob/gocryptfs#260 The crash is in line n.setClientInode(fi.Ino) because fi is nil. This can happen when file.GetAttr() returns an error code other than ENOSYS and EBADF. For gocryptfs, this can only happen when an open file descriptor breaks. In this case it was triggered by a failing NFS volume. Fix the crash by erroring out for error codes that are not handled by the retry-by-path logic.
Hi,
Gocryptfs gets a real workout here on kerberized NFSv4. It recently panicked for the first time. To be sure, the latest Linux kernel for Debian testing (4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 (2018-08-18) x86_64 GNU/Linux) introduces other serious problems related to networking and NFS, but perhaps this unexpected error should be caught. I am still on version 1.4.3. Thank you!
Kind regards,
Felix
The text was updated successfully, but these errors were encountered: