crash when under heavy load #6

kelnos · 2011-05-06T08:16:00Z

I have a lot of photos on my ext4 partition, and I told Picasa to scan those folders. It scans through photos for 20 seconds or so (sometimes as few as 5-10 seconds) and stops, and removes the photos just scanned. The ext4fuse process appears to be dead, and when I ls the mount directory, I get a "Device not configured" error. 100% reproducible here. I'm using official MacFUSE 2.0.3, and I've also tried the 2.1.5 beta version with the same result.

Log file posted here (it's 17MB):
http://spurint.org/stuff/ext4fuse.log

If I attach with gdb, the process at some point receives SIGABRT, and I get the following stack traces for all threads:

Program received signal SIGABRT, Aborted.
0x00007fff8034ffca in __semwait_signal ()
(gdb) thread apply all bt

Thread 6 (process 18942):
#0  0x00007fff8031f9c6 in read ()
#1  0x0000000100012a87 in fuse_kern_chan_receive ()
#2  0x0000000100015eab in fuse_chan_recv ()
#3  0x0000000100012dca in fuse_do_work ()
#4  0x00007fff8034e536 in _pthread_start ()
#5  0x00007fff8034e3e9 in thread_start ()

Thread 5 (process 18942):
#0  0x00007fff80387e4e in __semwait_signal_nocancel ()
#1  0x00007fff80387d50 in nanosleep$NOCANCEL ()
#2  0x00007fff803e46a2 in usleep$NOCANCEL ()
#3  0x00007fff80403cd4 in abort ()
#4  0x00007fff803f2901 in szone_error ()
#5  0x00007fff8031fbcf in small_free_list_remove_ptr ()
#6  0x00007fff8031c63b in szone_free_definite_size ()
#7  0x00000001000116b9 in fuse_lib_read ()
#8  0x00000001000145f1 in do_read ()
#9  0x0000000100013cc3 in fuse_ll_process ()
#10 0x0000000100015df6 in fuse_session_process ()
#11 0x0000000100012e5e in fuse_do_work ()
#12 0x00007fff8034e536 in _pthread_start ()
#13 0x00007fff8034e3e9 in thread_start ()

Thread 4 (process 18942):
#0  0x00007fff8031f9c6 in read ()
#1  0x0000000100012a87 in fuse_kern_chan_receive ()
#2  0x0000000100015eab in fuse_chan_recv ()
#3  0x0000000100012dca in fuse_do_work ()
#4  0x00007fff8034e536 in _pthread_start ()
#5  0x00007fff8034e3e9 in thread_start ()

Thread 3 (process 18942):
#0  0x00007fff8031f9c6 in read ()
#1  0x0000000100012a87 in fuse_kern_chan_receive ()
#2  0x0000000100015eab in fuse_chan_recv ()
#3  0x0000000100012dca in fuse_do_work ()
#4  0x00007fff8034e536 in _pthread_start ()
#5  0x00007fff8034e3e9 in thread_start ()

Thread 2 (process 18942):
#0  0x00007fffffe00295 in __spin_lock ()
#1  0x00007fff803196cb in szone_malloc_should_clear ()
#2  0x00007fff80318eea in malloc_zone_malloc ()
#3  0x00007fff803171e8 in malloc ()
#4  0x0000000100011538 in fuse_lib_read ()
#5  0x00000001000145f1 in do_read ()
#6  0x0000000100013cc3 in fuse_ll_process ()
#7  0x0000000100015df6 in fuse_session_process ()
#8  0x0000000100012e5e in fuse_do_work ()
#9  0x00007fff8034e536 in _pthread_start ()
#10 0x00007fff8034e3e9 in thread_start ()

Thread 1 (process 18942):
#0  0x00007fff8034ffca in __semwait_signal ()
#1  0x00007fff80353de1 in _pthread_cond_wait ()
#2  0x0000000100018856 in fuse_sem_wait ()
#3  0x0000000100012ff2 in fuse_session_loop_mt ()
#4  0x0000000100015203 in fuse_loop_mt ()
#5  0x0000000100016815 in fuse_main_common ()
#6  0x000000010001686a in fuse_main_real ()
#7  0x0000000100000b2f in main (argc=2, argv=0x7fff5fbff7c8) at fuse-main.c:85

gerard · 2011-05-06T09:07:41Z

Hi,

Maybe you could try to run ext4fuse without multithreading and see how it works. Also, check if by simply by running find . on the ext4 mount point it reproduces the problem. If so, you might want to try on subdirectories so that we can pinpoint where the problem is.

You can see how to disable multithreading here:
#2 (comment)

Thanks for reporting the problem,
Gerard.

kelnos · 2011-05-06T10:00:08Z

Scanning only different subdirectories doesn't change the result -- of course if I hit a small subdirectory it doesn't trigger the problem, but larger dirs and different combinations of several subdirs all cause the problem. So I don't think it's related to the data itself, or the filesystem metadata (well, unless all the directories in question have a common "problem").

Running "find ." on the root of the mount does not cause the problem. Got through the entire filesystem without any trouble. Perhaps it has to actually open files and read a bit from them to trigger it...?

Disabling multithreading doesn't help either, but the end of the log is a little more informative, perhaps:

OPEN[1200843] flags: 0x0 /home/brian/Pictures/el_visit-jan2011/.picasa.ini
unique: 1, opcode: READ (15), nodeid: 1103, insize: 64
READ[1200843] 15487 bytes from 0
   READ[1200843] 15487 bytes
   unique: 1, error: 0 (Unknown error: 0), outsize: 15503
unique: 3, opcode: RELEASE (18), nodeid: 1103, insize: 64
RELEASE[1200843] flags: 0x0
   unique: 3, error: 0 (Unknown error: 0), outsize: 16
unique: 0, opcode: OPEN (14), nodeid: 1061, insize: 48
   unique: 0, error: 0 (Unknown error: 0), outsize: 32
OPEN[1219117] flags: 0x0 /home/brian/Pictures/el_visit-jan2011/el-visit-2011.01.06-003.jpg
unique: 2, opcode: READ (15), nodeid: 1061, insize: 64
ext4fuse(19508) malloc: *** error for object 0x10086a008: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Abort trap

gdb is giving something a little more useful now, though it'd be nice if I had debugging symbols for FUSE... might take a look at building that myself. Do you think that might be worthwhile?

OPEN[1846044] flags: 0x0 /home/brian/Pictures/Downloaded Albums/mayaandilya/Natalia and Andrey/DSC01370.JPG
unique: 2, opcode: READ (15), nodeid: 3632, insize: 64
ext4fuse(19741) malloc: *** error for object 0x100883e08: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

Breakpoint 1, 0x00007fff803f176d in malloc_error_break ()
(gdb) bt
#0  0x00007fff803f176d in malloc_error_break ()
#1  0x00007fff803f28c4 in szone_error ()
#2  0x00007fff8031cdb4 in small_malloc_from_free_list ()
#3  0x00007fff80319741 in szone_malloc_should_clear ()
#4  0x00007fff80318eea in malloc_zone_malloc ()
#5  0x00007fff803171e8 in malloc ()
#6  0x0000000100011538 in fuse_lib_read ()
#7  0x00000001000145f1 in do_read ()
#8  0x0000000100013cc3 in fuse_ll_process ()
#9  0x0000000100015df6 in fuse_session_process ()
#10 0x0000000100012bc3 in fuse_session_loop ()
#11 0x000000010000e98f in fuse_loop ()
#12 0x0000000100016822 in fuse_main_common ()
#13 0x000000010001686a in fuse_main_real ()
#14 0x0000000100000b27 in main (argc=4, argv=0x7fff5fbff810) at fuse-main.c:86

At any rate, thank you so much for ext4fuse. I've been a Linux guy for a good 10 years now, but I've been doing a lot of iOS development lately and find myself running OSX just about all the time. Having easy access to the files on my ext4 partition has saved me a lot of time.

gerard · 2011-05-06T12:59:47Z

Wow, thanks for so detailed bug reports :)

At a first look, it looks like a memory corruption: the malloc is freaking out because something seems borken in its internal structs. In your case I would try to reproduce the problem in linux. Then run singlethreaded and foreground using valgrind. Valgrind will make ext4fuse slow as hell, but if the problem is what I suspect, there's no easier way to find it. Besides, getting the debugging symbols on linux should be easier than on OSX (let me know if you need more instructions on some step).

Anyway, if you don't manage to do this or just don't have the time, it might be helpful to attach the singlethreaded log. It should be possible to reproduce the access pattern from the log and maybe that way I can try to reproduce the problem on my own.

BR,
Gerard.

kelnos · 2011-05-09T18:19:56Z

So far I've been unable to reproduce this on Linux :( . I'll try a few more things, though. Might still be possible to debug on OSX.

gerard · 2011-05-09T18:56:35Z

What about efence(3) or similars? They might work on OSX. I'm sorry I'm only giving you more work, but I don't have much time in my hands lately. When I get some, I can parse the logfile you posted to create the same access pattern, but that will be probably on the weekend already.

Edit: Even if the problem doesn't trigger on Linux, you should still try with valgrind. It might detect some buffer overflow that happens to be benign in Linux, but is breaking in OSX.

kelnos · 2011-05-16T00:58:46Z

Hey, sorry I disappeared for a little bit. Getting back to this finally. It turns out valgrind has been ported to OSX (had no idea...), so I'm giving that a try now. So yeah, still crashes, here's the valgrind log:

==73432== Memcheck, a memory error detector
==73432== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==73432== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==73432== Command: ./ext4fuse /dev/disk0s3 /Users/brian/mnt/linux /Users/brian/ext4fuse.log
==73432== Parent PID: 70066
==73432== 
--73432-- 
--73432-- Valgrind options:
--73432--    --leak-check=no
--73432--    -v
--73432--    --num-callers=50
--73432--    --log-file=valgrind.log
--73432--    --dsymutil=yes
--73432-- Contents of /proc/version:
--73432--   can't open /proc/version
--73432-- Arch and hwcaps: AMD64, amd64-sse3-cx16
--73432-- Page sizes: currently 4096, max supported 4096
--73432-- Valgrind library directory: /opt/local/lib/valgrind
--73432-- ./ext4fuse (0x100000000)
--73432--    reading syms   from primary file (40 395)
--73432--    dSYM= ./ext4fuse.dSYM/Contents/Resources/DWARF/ext4fuse
--73432--    reading dwarf3 from dsyms file
--73432-- /usr/lib/dyld (0x7fff5fc00000)
--73432--    reading syms   from primary file (6 1186)
--73432-- Reading suppressions file: /opt/local/lib/valgrind/default.supp
--73432-- REDIR: 0x7fff5fc22fb0 (strcmp) redirected to 0x138048f30 (???)
--73432-- REDIR: 0x7fff5fc20693 (arc4random) redirected to 0x138048fce (???)
--73432-- REDIR: 0x7fff5fc22e90 (strlen) redirected to 0x138048eff (???)
--73432-- REDIR: 0x7fff5fc22ee0 (strcpy) redirected to 0x138048f4c (???)
--73432-- REDIR: 0x7fff5fc2306f (strcat) redirected to 0x138048f10 (???)
--73432-- /opt/local/lib/valgrind/vgpreload_core-amd64-darwin.so (0x10000a000)
--73432--    reading syms   from primary file (3 135)
--73432--    dSYM= /opt/local/lib/valgrind/vgpreload_core-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_core-amd64-darwin.so
--73432--    reading dwarf3 from dsyms file
--73432-- /opt/local/lib/valgrind/vgpreload_memcheck-amd64-darwin.so (0x100015000)
--73432--    reading syms   from primary file (109 593)
--73432--    dSYM= /opt/local/lib/valgrind/vgpreload_memcheck-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_memcheck-amd64-darwin.so
--73432--    reading dwarf3 from dsyms file
==73432== WARNING: new redirection conflicts with existing -- ignoring it
--73432--     new: 0x7fff5fc1dcd0 (strlcat             ) R-> 0x10001a340 strlcat
==73432== WARNING: new redirection conflicts with existing -- ignoring it
--73432--     new: 0x7fff5fc22ee0 (strcpy              ) R-> 0x10001a1a0 strcpy
--73432-- REDIR: 0x7fff5fc227b0 (strncmp) redirected to 0x1000185d0 (strncmp)
--73432-- REDIR: 0x7fff5fc23398 (memset) redirected to 0x1000188f0 (memset)
--73432-- /usr/local/lib/libfuse.2.dylib (0x10002a000)
--73432--    reading syms   from primary file (163 2691)
--73432-- /usr/lib/libiconv.2.dylib (0x100060000)
--73432--    reading syms   from primary file (17 1061)
--73432-- /usr/lib/libSystem.B.dylib (0x100168000)
--73432--    reading syms   from primary file (4604 3793)
--73432-- /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (0x1003ba000)
--73432--    reading syms   from primary file (1988 3673)
--73432-- /usr/lib/libauto.dylib (0x10064a000)
--73432--    reading syms   from primary file (58 410)
--73432-- /usr/lib/libicucore.A.dylib (0x1006a3000)
--73432--    reading syms   from primary file (3643 1)
--73432-- /usr/lib/libobjc.A.dylib (0x1008d0000)
--73432--    reading syms   from primary file (256 561)
--73432-- /usr/lib/libz.1.2.3.dylib (0x10099a000)
--73432--    reading syms   from primary file (58 1)
--73432-- /usr/lib/libstdc++.6.0.9.dylib (0x1009b0000)
--73432--    reading syms   from primary file (3306 365)
--73432-- REDIR: 0x7fff5fc21a36 (strrchr) redirected to 0x1000182f0 (strrchr)
--73432-- REDIR: 0x7fff5fc204b0 (strlcpy) redirected to 0x100019d20 (strlcpy)
--73432-- REDIR: 0x10016a7dc (memcpy) redirected to 0x100019ac0 (memcpy)
--73432-- REDIR: 0x100169414 (memset) redirected to 0x100018870 (memset)
--73432-- REDIR: 0x10016ac8f (__memcpy_chk) redirected to 0x100019250 (__memcpy_chk)
--73432-- REDIR: 0x10016b1bc (malloc) redirected to 0x100017180 (malloc)
--73432-- REDIR: 0x10016c150 (strlen) redirected to 0x100018550 (strlen)
--73432-- REDIR: 0x10016b7e0 (strncmp) redirected to 0x100018570 (strncmp)
--73432-- REDIR: 0x10016f076 (malloc_default_zone) redirected to 0x100015950 (malloc_default_zone)
--73432-- REDIR: 0x10016ce98 (malloc_zone_malloc) redirected to 0x1000170b0 (malloc_zone_malloc)
--73432-- REDIR: 0x7fff5fc234e4 (memmove) redirected to 0x1000189d0 (memmove)
--73432-- REDIR: 0x10016f21e (malloc_zone_calloc) redirected to 0x100015f90 (malloc_zone_calloc)
--73432-- REDIR: 0x7fff5fc23050 (strchr) redirected to 0x1000183b0 (strchr)
--73432-- REDIR: 0x10016f530 (bcmp) redirected to 0x100018750 (bcmp)
--73432-- REDIR: 0x10016c330 (strcmp) redirected to 0x100018630 (strcmp)
--73432-- REDIR: 0x10016f675 (free) redirected to 0x100016c10 (free)
--73432-- REDIR: 0x10017099c (bcopy) redirected to 0x100018a30 (bcopy)
--73432-- REDIR: 0x1001709a8 (malloc_zone_from_ptr) redirected to 0x100015940 (malloc_zone_from_ptr)
--73432-- REDIR: 0x10017107f (malloc_zone_realloc) redirected to 0x100017250 (malloc_zone_realloc)
--73432-- REDIR: 0x100172acd (malloc_zone_free) redirected to 0x100016b50 (malloc_zone_free)
--73432-- REDIR: 0x100172b2e (malloc_size) redirected to 0x100015b60 (malloc_size)
--73432-- REDIR: 0x100172b7c (memmove) redirected to 0x100018970 (memmove)
--73432-- REDIR: 0x100172ce2 (calloc) redirected to 0x100016070 (calloc)
--73432-- REDIR: 0x10016c30c (strrchr) redirected to 0x100018290 (strrchr)
--73432-- REDIR: 0x10016c3d0 (arc4random) redirected to 0x10000af60 (arc4random)
--73432-- REDIR: 0x10016e380 (strcpy) redirected to 0x10001a270 (strcpy)
--73432-- REDIR: 0x10017d0c9 (realloc) redirected to 0x100017380 (realloc)
--73432-- REDIR: 0x100174ed0 (strlcpy) redirected to 0x100019e30 (strlcpy)
--73432-- REDIR: 0x10018137b (strchr) redirected to 0x100018350 (strchr)
--73432-- REDIR: 0x100181180 (strlcat) redirected to 0x10001a480 (strlcat)
--73432-- REDIR: 0x1001a6993 (strcat) redirected to 0x100019170 (strcat)
==73434== 
==73434== HEAP SUMMARY:
==73434==     in use at exit: 238,528 bytes in 566 blocks
==73434==   total heap usage: 701 allocs, 135 frees, 250,974 bytes allocated
==73434== 
==73434== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==73434== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
--73435-- REDIR: 0x1001ca9be (index) redirected to 0x100018380 (index)
--73432-- REDIR: 0x1001a63b0 (strncpy) redirected to 0x10001a070 (strncpy)
==73432== Syscall param pread64(buf) points to unaddressable byte(s)
==73432==    at 0x1001AB04A: pread (in /usr/lib/libSystem.B.dylib)
==73432==    by 0x1000014C7: __disk_read (disk.c:106)
==73432==    by 0x10000177F: __disk_ctx_read (disk.c:142)
==73432==    by 0x100002D45: op_read (op_read.c:94)
==73432==    by 0x10002C598: fuse_fs_read (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x1000315F5: fuse_lib_read (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x1000345F0: do_read (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100033CC2: fuse_ll_process (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100035DF5: fuse_session_process (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100032BC2: fuse_session_loop (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x10002E98E: fuse_loop (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100036821: fuse_main_common (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100036869: fuse_main_real (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100000B26: main (fuse-main.c:86)
==73432==  Address 0x101a55e00 is not stack'd, malloc'd or (recently) free'd
==73432== 
==73432== Syscall param writev(vector[...]) points to uninitialised byte(s)
==73432==    at 0x1001F26E2: writev (in /usr/lib/libSystem.B.dylib)
==73432==    by 0x100035EE7: fuse_chan_send (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x1000339EA: send_reply_iov (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100033A2F: send_reply (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x1000340A7: send_reply_ok (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x1000340F6: fuse_reply_buf (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100031699: fuse_lib_read (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x1000345F0: do_read (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100033CC2: fuse_ll_process (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100035DF5: fuse_session_process (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100032BC2: fuse_session_loop (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x10002E98E: fuse_loop (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100036821: fuse_main_common (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100036869: fuse_main_real (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100000B26: main (fuse-main.c:86)
==73432==  Address 0x101a4de00 is 8,192 bytes inside a block of size 37,646 alloc'd
==73432==    at 0x1000171EF: malloc (vg_replace_malloc.c:236)
==73432==    by 0x100031537: fuse_lib_read (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x1000345F0: do_read (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100033CC2: fuse_ll_process (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100035DF5: fuse_session_process (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100032BC2: fuse_session_loop (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x10002E98E: fuse_loop (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100036821: fuse_main_common (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100036869: fuse_main_real (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100000B26: main (fuse-main.c:86)
==73432== 

valgrind: m_mallocfree.c:248 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 65600, hi = 8241996758919697225.
This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata.  If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away.  Please try that before reporting this as a bug.

==73432==    at 0x138031597: ???
==73432==    by 0x1380317D4: ???
==73432==    by 0x13803D885: ???
==73432==    by 0x1380026E4: ???
==73432==    by 0x13809017D: ???
==73432==    by 0x1380B633D: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==73432==    at 0x100016C7C: free (vg_replace_malloc.c:366)
==73432==    by 0x1000316B8: fuse_lib_read (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x1000345F0: do_read (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100033CC2: fuse_ll_process (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100035DF5: fuse_session_process (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100032BC2: fuse_session_loop (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x10002E98E: fuse_loop (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100036821: fuse_main_common (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100036869: fuse_main_real (in /usr/local/lib/libfuse.2.dylib)
==73432==    by 0x100000B26: main (fuse-main.c:86)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

gerard · 2011-05-21T06:10:48Z

Hi,

Sorry, I also had to disappear for a while :P. Certainly seems like something goes wrong. Could you post a core file? I can have a look after I finish my exams and fix my OSX laptop. Also that log with the single threaded binary would be useful.

Thanks for taking your time with this.
Gerard.

The crash in issue gerard#6 was caused by buf being incremented past the end of its allocated space. This only happened when a file was fragmented enough to cause the op_read() loop to run more than twice, so it wasn't caught by the existing tests. This also adds support for sparse files. A missing pblock is assumed to be a "hole" in the file, rather than an error.

gerard · 2013-01-19T17:01:15Z

@kelnos: I'm assuming that @pwi fixed your problem. Reopen if you still have problems.

gerard closed this as completed Jan 19, 2013

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

crash when under heavy load #6

crash when under heavy load #6

kelnos commented May 6, 2011

gerard commented May 6, 2011

kelnos commented May 6, 2011

gerard commented May 6, 2011

kelnos commented May 9, 2011

gerard commented May 9, 2011

kelnos commented May 16, 2011

gerard commented May 21, 2011

gerard commented Jan 19, 2013

crash when under heavy load #6

crash when under heavy load #6

Comments

kelnos commented May 6, 2011

gerard commented May 6, 2011

kelnos commented May 6, 2011

gerard commented May 6, 2011

kelnos commented May 9, 2011

gerard commented May 9, 2011

kelnos commented May 16, 2011

gerard commented May 21, 2011

gerard commented Jan 19, 2013