search

sgan81 / apfs-fuse

FUSE driver for APFS (Apple File System)
GNU General Public License v2.0
1.79k stars 164 forks source link

Deadlock issue #193

Open nijave opened 5 months ago

nijave commented 5 months ago

I'm hitting what appears to be some locking issue where apfs-fuse sits at 100% CPU and doesn't respond.

I started tar -cf - . | pv > /dev/null then tried to do tab filename completion in another window (although I think I hit the same issue just running the first command alone.

Here's gdb -p $(pgrep apfs-fuse)

(gdb) thread apply all bt

Thread 1 (Thread 0x7f96a5edcb80 (LWP 159921) "apfs-fuse"):
#0  0x00007f96a600a48c in updatewindow (strm=strm@entry=0x7ffe70dbeb10, end=end@entry=0x2eff3320 "", len=len@entry=0, cksum=4) at /usr/src/debug/zlib-ng-2.1.6-5.fc40.x86_64/inflate.c:281
#1  0x00007f96a6011e62 in inflate (strm=0x7ffe70dbeb10, flush=0) at /usr/src/debug/zlib-ng-2.1.6-5.fc40.x86_64/inflate.c:1123
#2  0x00000000004353e4 in DecompressZLib(unsigned char*, unsigned long, unsigned char const*, unsigned long) ()
#3  0x000000000042a965 in DecompressFile(ApfsDir&, unsigned long, std::vector<unsigned char, std::allocator<unsigned char> >&, std::vector<unsigned char, std::allocator<unsigned char> > const&) ()
#4  0x0000000000410cbb in apfs_open(fuse_req*, unsigned long, fuse_file_info*) ()
#5  0x00007f96a603af19 in do_open (req=<optimized out>, nodeid=<optimized out>, inarg=<optimized out>) at ../lib/fuse_lowlevel.c:1353
#6  0x00007f96a6045b97 in fuse_session_process_buf_int (se=0x2bba1a60, buf=0x7ffe70dbee60, ch=<optimized out>) at ../lib/fuse_lowlevel.c:2771
#7  0x00007f96a60351ec in fuse_session_loop (se=0x2bba1a60) at ../lib/fuse_loop.c:34
#8  0x000000000040eb8b in main ()

I have logs from -d 4 but they may have sensitive info so I don't want to post them publicly. I see the log output is also stopped

RustinCohle commented 4 months ago

I had the same issue too. In my case, the return value of inflate() is Z_BUF_ERROR, which doesn't met break condition of inflate loop. In zlib manual page, error Z_BUF_ERROR is not fatal, and inflate() can be called again with more input and more output space to continue decompressing. I am wondering how to fix this issue. Should we call inflate() again with larger memory size? or truncate the decompressed data?