rar2fs crash with corrupted double linked list error #98

Darkvater · 2018-10-10T00:50:16Z

Continuing from #95

tomi@hattusa:~$ sudo rar2fs /mnt/sma/media/rar-movies /mnt/sma/media/.rar-movies.rar2fs -o rw,noatime,allow_other --seek-length=2 -o max_readahead=512K -d 2> smamovie
*** Error in `rar2fs': corrupted double-linked list: 0x0000007f7000a2c0 ***        
Aborted

Actually managed to get two core dumps

1

last entry from log

Caught signal SIGSEGV                                                              Read 4096 bytes from vol=0, base=0                                                    read[547876771024] 4096 bytes from 270999552                                       
unique: 13262, success, outsize: 4112                                           rar2fs[9837]: Got signal 11, faulty address is 0x7f84021000, from 0x557050a9e8

stack trace

Core was generated by `rar2fs /mnt/sda/media/rar-tv-series/ /mnt/sda/media/.rar-tv-series.rar2fs/ -o r'.
Program terminated with signal SIGSEGV, Segmentation fault.                        
#0  0x0000007fa116df84 in raise () from /lib/aarch64-linux-gnu/libpthread.so.0     [Current thread is 1 (Thread 0x7f988c41e0 (LWP 9841))]                             
(gdb) bt                                                                           #0  0x0000007fa116df84 in raise () from /lib/aarch64-linux-gnu/libpthread.so.0     
#1  0x000000557050a9fc in sig_handler (signum=11, info=0x7f988c2280,                   secret=0x7f988c2300) at sighandler.c:135                                       #2  <signal handler called>                                                        #3  0x0000007fa10824e4 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
#4  0x00000000ffffffff in ?? ()                                                    Backtrace stopped: previous frame identical to this frame (corrupt stack?)

2

last entry from log

Opening /mnt/sma/media/rar-movies/The.Assassin.2015.720p.BluRay.x264-ROVERS/the.assassin.2015.720p.bluray.x264-rovers.rar

stack trace

Core was generated by `rar2fs /mnt/sma/media/rar-movies /mnt/sma/media/.rar-movies.rar2fs -o rw,noatim'.
Program terminated with signal SIGABRT, Aborted.
#0  0x0000007f97aa39fc in raise () from /lib/aarch64-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0x7f8db031e0 (LWP 9895))]
(gdb) bt
#0  0x0000007f97aa39fc in raise () from /lib/aarch64-linux-gnu/libc.so.6
#1  0x0000007f97aa4df4 in abort () from /lib/aarch64-linux-gnu/libc.so.6           
#2  0x0000007f97adc628 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
#3  0x0000007f97b8ee48 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

will update as I find out more. Since it (or at least a core dump) can be reproduced quite easily I will try to narrow down the cause and then trace it with gdb.
apologies for possibility mangled copy&paste, I'm doing the bug reporting from a phone

The text was updated successfully, but these errors were encountered:

Darkvater · 2018-10-10T01:21:19Z

Update 1:
My mount combines multiple shares into a single share using unionfs. Eg movies and rar-movies into /movies which I can easily serve up as a single folder without having to worry about the internals.

I am unable to reproduce the problem with just mounting the rar2fs point, but I can with mounting 1 rar2fs point and doing a unionfs.

*** Error in `rar2fs': corrupted size vs. prev_size: 0x0000007f78001ef0 ***       
Aborted

*** Error in `rar2fs': double free or corruption (out): 0x0000007f940033d0 ***    
Aborted

Darkvater · 2018-10-10T01:37:56Z

Update 2:
Ran it from gdb. But just as useless I think?

(gdb) run /mnt/sda/media/rar-tv-series/ /mnt/sda/media/.rar-tv-series.rar2fs/ -o rw,noatime,allow_other --seek-length=2 -o max_readahead=512K -d 2>sdatv2
Starting program: /usr/bin/rar2fs /mnt/sda/media/rar-tv-series/ /mnt/sda/media/.rar-tv-series.rar2fs/ -o rw,noatime,allow_other --seek-length=2 -o max_readahead=512K -d 2>sdatv2                                                                       
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".        
[New Thread 0x7fb04bb1e0 (LWP 11945)]
[New Thread 0x7fafc991e0 (LWP 11946)]                                             
[New Thread 0x7faf4771e0 (LWP 11947)]
[New Thread 0x7faec551e0 (LWP 11990)]                                             
[New Thread 0x7fae4331e0 (LWP 11991)]
*** Error in `/usr/bin/rar2fs': double free or corruption (out): 0x0000007f9c007770 ***
Thread 5 "rar2fs" received signal SIGABRT, Aborted.
[Switching to Thread 0x7faec551e0 (LWP 11990)]                                    
0x0000007fb7bf59fc in raise () from /lib/aarch64-linux-gnu/libc.so.6
(gdb) bt                                                                          
#0  0x0000007fb7bf59fc in raise () from /lib/aarch64-linux-gnu/libc.so.6
#1  0x0000007fb7bf6df4 in abort () from /lib/aarch64-linux-gnu/libc.so.6           
#2  0x0000007fb7c2e628 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
#3  0x0000007fb7ce0f08 in ?? () from /lib/aarch64-linux-gnu/libc.so.6              
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

hasse69 · 2018-10-10T07:12:39Z

Thanks for the issue report.

I think we should separate this from #95 at least until we cannot prove it is having the same root cause. Currently I do not think that is the case due to the very different crash signature and stack traces.

I really appreciate all the hard work you are putting into trying to collect more data for trouble shooting. We will need more of that since I am currently unable to reproduce anything similar.

There are a few things that are interesting to note here:

Before upgrading your system you did not observe the same problem, using the same version of rar2fs and also using the same approach with unionfs
On the current system not using unionfs in combination with rar2fs does not seem to trigger the problem
The crash signature is different, SIGABRT vs SIGSEGV, which indicates this is not a deterministic problem and points to memory corruption somewhere
I have been running tools like valgrind and there are currently no indications of incorrect handling of allocated regions etc. in rar2fs itself

These kind of issues are very hard to troubleshoot, especially since we do not seem to be able to collect a decent stack trace. We also cannot out rule the fact that the source of the corruption could be located some where else, not in rar2fs itself. The crash always points to the main process, but there are several linked in libraries being used too. What strikes me as a bit odd is that you started to see this after a system upgrade and without unionsfs it also seems to behave.

From what I can tell so far is that the last thing you do see is some partial read of a file, right? What if the buffer provided by FUSE in the read call simply is not big enough? I am not saying that is the case, only saying that a corruption can have many different sources.

So, we need to narrow it down somehow. Would it be possible for you to downgrade rar2fs to , lets say, v1.24.1? Not that I think it will do much good but we need to try something.

Another thing you can try on the current version is mounting using the -s flag to force rar2fs/FUSE into single threaded mode.

Darkvater · 2018-10-16T12:28:11Z

Update 2 (sorry for being late, but a new addition to the family totally changed all plans):

I can confirm that using single threaded mode (with -s) does not cause an issue.
the previous system I had rar2fs running on was an arm86, running different hardware, different kernel and debian version so I think doing any kind of testing there will not be that useful. I can downgrade the current version of rar2fs to 1.24.1 and see what happens, but do bear with me if it takes a while.

Darkvater · 2018-10-16T13:41:11Z

Update:

Compiled 1.24.1 using the same library 5.6.5 and fuse and had the same problem.
Also realised I was running 5.6.5 while the readme said 5.6.2 (and suggested higher minor versions might work), so tried with that one as well. Same.

hasse69 · 2018-10-16T16:17:06Z

Yea, I was sort of afraid of this...
So, if you can confirm it is working fine using -s, then the only conclusion we can make from that is that there is some terrible thread synchronization bug left in the code somewhere. If that bug is in fact in rar2fs or some library it is using is very hard to tell without a proper stack trace. Actually, even with a stack trace it can be difficult to find since memory corruption can go on silently for a while until it becomes a problem big enough to cause a crash.

hasse69 · 2018-10-16T17:38:49Z

What you can try is to compile rar2fs using the maximum debug level, I believe it is --enable-debug=5 and then start it in the foreground using -d. Possibly we can at least see what is the last thing it tries before going down.

Darkvater · 2018-10-19T02:20:09Z

Tried that, but it is not really giving more information compared to --enable-debug which is level 4.

Now the interesting but is that the exception happens in thread 11892. However, this is not rar2fs. All activities in the log happen in 11871. Is that perhaps a clue?

gdb

*** Error in `/usr/bin/rar2fs.1.27.0-dbg': double free or corruption (out): 0x0000007fa001f7d0 ***

Thread 5 "rar2fs.1.27.0-d" received signal SIGABRT, Aborted.
[Switching to Thread 0x7faecdd1e0 (LWP 11892)]
0x0000007fb7c5b9fc in raise () from /lib/aarch64-linux-gnu/libc.so.6
(gdb) info threads
  Id   Target Id         Frame
  1    Thread 0x7fb7ff5420 (LWP 11871) "rar2fs.1.27.0-d" 0x0000007fb7cc7764 in nanosleep () from /lib/aarch64-linux-gnu/libc.so.6
  2    Thread 0x7fb05211e0 (LWP 11873) "rar2fs.1.27.0-d" 0x0000007fb7d84870 in do_futex_wait.constprop () from /lib/aarch64-linux-gnu/libpthread.so.0
  3    Thread 0x7fafcff1e0 (LWP 11874) "rar2fs.1.27.0-d" 0x0000007fb7d85a28 in read () from /lib/aarch64-linux-gnu/libpthread.so.0
  4    Thread 0x7faf4dd1e0 (LWP 11875) "rar2fs.1.27.0-d" 0x0000007fb7d85a28 in read () from /lib/aarch64-linux-gnu/libpthread.so.0
* 5    Thread 0x7faecdd1e0 (LWP 11892) "rar2fs.1.27.0-d" 0x0000007fb7c5b9fc in raise () from /lib/aarch64-linux-gnu/libc.so.6
(gdb) thread 1
[Switching to thread 1 (Thread 0x7fb7ff5420 (LWP 11871))]
#0  0x0000007fb7cc7764 in nanosleep () from /lib/aarch64-linux-gnu/libc.so.6
(gdb) bt
#0  0x0000007fb7cc7764 in nanosleep () from /lib/aarch64-linux-gnu/libc.so.6
#1  0x0000007fb7cc7598 in sleep () from /lib/aarch64-linux-gnu/libc.so.6
#2  0x000000555557bff0 in work (args=0x7ffffffac8) at rar2fs.c:5194
#3  0x000000555557c794 in main (argc=4, argv=0x7ffffffc28) at rar2fs.c:5485
(gdb) thread 2
[Switching to thread 2 (Thread 0x7fb05211e0 (LWP 11873))]
#0  0x0000007fb7d84870 in do_futex_wait.constprop ()
   from /lib/aarch64-linux-gnu/libpthread.so.0
(gdb) bt
#0  0x0000007fb7d84870 in do_futex_wait.constprop ()
   from /lib/aarch64-linux-gnu/libpthread.so.0
#1  0x0000007fb7d84928 in __new_sem_wait_slow.constprop.0 ()
   from /lib/aarch64-linux-gnu/libpthread.so.0
#2  0x0000007fb7f91788 in fuse_session_loop_mt ()
   from /lib/aarch64-linux-gnu/libfuse.so.2
#3  0x0000007fb7f96908 in fuse_loop_mt () from /lib/aarch64-linux-gnu/libfuse.so.2
#4  0x000000555557b830 in work_task (data=0x7ffffffa60) at rar2fs.c:5006
#5  0x0000007fb7d7c0a0 in start_thread ()
   from /lib/aarch64-linux-gnu/libpthread.so.0
#6  0x0000007fb7cf2eac in ?? () from /lib/aarch64-linux-gnu/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread 0x7fafcff1e0 (LWP 11874))]
#0  0x0000007fb7d85a28 in read () from /lib/aarch64-linux-gnu/libpthread.so.0
(gdb) bt
#0  0x0000007fb7d85a28 in read () from /lib/aarch64-linux-gnu/libpthread.so.0
#1  0x0000007fb7f90e8c in ?? () from /lib/aarch64-linux-gnu/libfuse.so.2
#2  0x0000007fafcfe9a0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) thread 4
[Switching to thread 4 (Thread 0x7faf4dd1e0 (LWP 11875))]
#0  0x0000007fb7d85a28 in read () from /lib/aarch64-linux-gnu/libpthread.so.0
(gdb) bt
#0  0x0000007fb7d85a28 in read () from /lib/aarch64-linux-gnu/libpthread.so.0
#1  0x0000007fb7f90e8c in ?? () from /lib/aarch64-linux-gnu/libfuse.so.2
#2  0x0000007faf4dc9a0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) thread 5
[Switching to thread 5 (Thread 0x7faecdd1e0 (LWP 11892))]
#0  0x0000007fb7c5b9fc in raise () from /lib/aarch64-linux-gnu/libc.so.6
(gdb) bt
#0  0x0000007fb7c5b9fc in raise () from /lib/aarch64-linux-gnu/libc.so.6
#1  0x0000007fb7c5cdf4 in abort () from /lib/aarch64-linux-gnu/libc.so.6
#2  0x0000007fb7c94628 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
#3  0x0000007fb7d46f08 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

logs

Opening /mnt/sda/media/rar-tv-series/Fawlty.Towers.S01-02.HUN.ENG.DVDRip.XviD-RELEASHERZ/Season 01/Fawlty.Towers.S01E02.HUN.ENG.DVDRip.XviD-RELEASHERZ/rlz-fawlty.towers.s01e02.r15                                                                     
SEEK src_off = 85, VOL_REAL_SZ = 14851288                                          
size = 14288, chunk = 14851203                                                    
Read 14288 bytes from vol=16, base=0                                                 
   read[548212346464] 131072 bytes from 237502464                                    
   unique: 1853, success, outsize: 131088                                         
unique: 1855, opcode: READ (15), nodeid: 5, insize: 80, pid: 11881                
read[548212346464] 131072 bytes from 237764608 flags: 0x20000                     
rar2_read()   size=131072, offset=237764608, fh=548212346464                       
PID 11871 calling lread_raw(), seq = 1846, offset=237764608                        
SEEK src_off = 145445, VOL_REAL_SZ = 14851288                                      
size = 131072, chunk = 14705843                                                   
Read 131072 bytes from vol=16, base=0
      read[548212346464] 131072 bytes from 237764608
      unique: 1855, success, outsize: 131088

hasse69 · 2018-10-19T08:00:01Z

The thread id is a hint but not much more than that I am afraid.
Since the stack cannot be traversed properly it is impossible to say which thread this really is.
But this is somewhat strange:

size = 14288, chunk = 14851203                                                    
Read 14288 bytes from vol=16, base=0                                                 
   read[548212346464] 131072 bytes from 237502464                                    
   unique: 1853, success, outsize: 131088

The size read is 14288 bytes but still FUSE thinks we read 131072 bytes?
Can you look a few lines up in the log to see if you can find the actual read request for 14288 bytes?
Should be something like this

read[548212346464] 131072 bytes from 237764608 flags: 0x20000

but with a size of 14288 rather than 131072.

We can try to add some protection in the raw read function in case we are called from different threads using asynchronous reads. The -osync_read is hard-coded by rar2fs so that would surprise me though.

Unfortunately we dump the PID and not the TID in the log. We might have spotted if the read is coming from the thread that caught the exception. Can you please step up to latest version of rar2fs?
Then it would be easier for me to attach a patch that you could try.

Also, am I right in that it seem to be different files each time being involved in the crash?
What if you reduce your media library size? Can you still reproduce?

Darkvater · 2018-10-20T03:22:50Z

Okay, I had a look around and I think we might have some bit more information still running 1.27.0. Added some more gcc hardening flags like -fsanitize=address* and some others, and when things crash I have a lot more information 👍.
I have also further narrowed down the cause, and can reproduce just by mounting the share and copying a single file.

The below should help, right? :)
sdatv.txt

==31414==ERROR: AddressSanitizer: heap-use-after-free on address 0x7fac102e63 at pc 0x55555b416c bp 0x7faa6fd810 sp 0x7faa6fd878
READ of size 26 at 0x7fac102e63 thread T2
    #0 0x55555b416b in __interceptor_strncmp.part.67 (/mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs+0x5f16b)
    #1 0x555567e16b in syncdir_scan /mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs.c:2745
    #2 0x555567f72b in syncdir /mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs.c:2982
    #3 0x555567ffb7 in rar2_getattr /mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs.c:3081
    #4 0x7fb7f89b6f  (/lib/aarch64-linux-gnu/libfuse.so.2+0xbb6f)

0x7fac102e63 is located 19 bytes inside of 48-byte region [0x7fac102e50,0x7fac102e80)
freed by thread T2 here:
    #0 0x5555621ce3 in free (/mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs+0xccce3)
    #1 0x555567e61f in syncdir_scan /mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs.c:2790
    #2 0x555567f72b in syncdir /mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs.c:2982
    #3 0x555567ffb7 in rar2_getattr /mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs.c:3081
    #4 0x7fb7f89b6f  (/lib/aarch64-linux-gnu/libfuse.so.2+0xbb6f)
    #5 0x7fb7f89d87  (/lib/aarch64-linux-gnu/libfuse.so.2+0xbd87)
    #6 0x7fb7f947e3  (/lib/aarch64-linux-gnu/libfuse.so.2+0x167e3)
    #7 0x7fb7f91607  (/lib/aarch64-linux-gnu/libfuse.so.2+0x13607)
    #8 0x7fb7d9e09f in start_thread (/lib/aarch64-linux-gnu/libpthread.so.0+0x709f)
    #9 0x7fb7c47eab  (/lib/aarch64-linux-gnu/libc.so.6+0xc7eab)

previously allocated by thread T2 here:
    #0 0x5555621f93 in __interceptor_malloc (/mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs+0xccf93)
    #1 0x7fb7c1843f  (/lib/aarch64-linux-gnu/libc.so.6+0x9843f)
    #2 0x55555ebc27 in scandir64 (/mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs+0x96c27)
    #3 0x555567dfef in syncdir_scan /mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs.c:2734
    #4 0x555567f72b in syncdir /mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs.c:2982
    #5 0x555567ffb7 in rar2_getattr /mnt/sda/work/tmp/rar2fs-1.27.0/rar2fs.c:3081
    #6 0x7fb7f89b6f  (/lib/aarch64-linux-gnu/libfuse.so.2+0xbb6f)
    #7 0x7fb7f89d87  (/lib/aarch64-linux-gnu/libfuse.so.2+0xbd87)
    #8 0x7fb7f947e3  (/lib/aarch64-linux-gnu/libfuse.so.2+0x167e3)
    #9 0x7fb7f91607  (/lib/aarch64-linux-gnu/libfuse.so.2+0x13607)
    #10 0x7fb7d9e09f in start_thread (/lib/aarch64-linux-gnu/libpthread.so.0+0x709f)
    #11 0x7fb7c47eab  (/lib/aarch64-linux-gnu/libc.so.6+0xc7eab)

Update1:

Looking at the code, this looks a bit dodgy in syncdir_scan(): "if (i && strncmp(namelist[i]->d_name, namelist[i - 1]->d_name, pos))". at rar2fs.c:2745. All entries are allocated in rar2fs.c:2734 scandir(...) then when i>0 you do the string comparison between i and i-1, however i-1 has already been freed in rar2fs.c:2790.
I'm guessing the same applies to readdir_scan(). rar2fs.c:2894, rar2fs.c:2941

Update2:

After "fixing" these two, rar2fs fails as follows: sdatv_fixed.txt which is a double free on an open file pointer; however the copy was successful.

Update3:

If I comment out the fclose() in lread_raw() on rar2fs.c:1231 in addition to Update1 then all the problems are gone. Obviously there should be an fclose there somewhere so not sure about that.

Update4:

In single threaded mode, or without unionfs the incorrect free of Update1 and doule fclose() of Update3 still happens, but doesn't seem to affect operations.

[*] for future reference, add -fsanitize=address to CFLAGS/CPPFLAGS and -fsanitize=address -static-libasan to LDFLAGS

hasse69 · 2018-10-20T06:54:00Z

Thanks, will look into it.

Darkvater · 2018-10-20T06:54:55Z

updated post

hasse69 · 2018-10-20T08:17:03Z

If I comment out the fclose() in lread_raw() on rar2fs.c:1231 then the problems are gone. Obviously there should be a free there somewhere so not sure about that.

Yepp, you spotted a problem that has been there all the time I believe. Nice catch.
I will look more closely into the problem and what can be done to resolve it. There are a couple of different approaches one might take here. It is remarkable how bugs can pass unnoticed sometimes.

In single threaded mode, or without unionfs the incorrect free of Update1 and doule _fclose()_of Update3 still happens, but doesn't seem to affect operations.

That is also what I suspect, this is probably a very silent bug hiding under the radar. Otherwise I think someone (including myself) would have seen this a long time ago. Again, nice catch.

hasse69 · 2018-10-20T20:33:04Z

Please try this patch. I primarily wish to see if it resolves the problem(s) you have observed. This is not necessarily the final solution.

issue98.patch.txt

Darkvater · 2018-10-20T23:41:35Z

Thanks, that seems to have solved it. AddressSanitizer does no longer complain and the few test cases I have thrown at it all work beautifully. Cheers!

hasse69 · 2018-10-21T08:08:38Z

Excellent. Please give it some more run-time and then report back. It is very possible this also solves #95. The unionfs must have triggered a rather unusual use-case for which multiple threads are accessing the same file but otherwise shares the same open request. If this is a common access pattern I think it should have been discovered much earlier. Sorry for all the trouble. Not sure why I have not considered this. My bad.

This patch fixes a problem discovered by compiling using the -fsanitize=address option while trouble shooting issue #98. Signed-off-by: Hans Beckerus <hans.beckerus at gmail.com>

This patch should resolve the problem with sporadic crashes as reported in issue #98. Signed-off-by: Hans Beckerus <hans.beckerus at gmail.com>

hasse69 · 2018-10-22T10:43:19Z

Made a push to master. Please try it and report back. If everything seems to work well we can close this issue. I will probably make an official patch release later this week.

Darkvater · 2018-10-28T00:40:05Z

Been running for the past six days and no issues detected. Finally my sbc is stable again - used to lock up & reboot due to rar2fs.

hasse69 · 2018-10-29T07:18:18Z

Thanks, I will make a release ASAP. Did not manage to get the time last week.
I also have some ideas how this patch can be slightly improved so if possible I will ping you for a short test if that is ok. But I will release as is for now since it seems to be working fine.

hasse69 changed the title ~~rar2fs does with corrupted double linked lis~~ rar2fs crash with corrupted double linked list error Oct 10, 2018

hasse69 added Defect Priority-Medium labels Oct 10, 2018

This was referenced Oct 21, 2018

rar2fs dies with "Got signal 11, faulty address" #95

Closed

rar2fs faulty address #59

Closed

hasse69 pushed a commit that referenced this issue Oct 22, 2018

Fix a heap-use-after-free error

d4d46d0

This patch fixes a problem discovered by compiling using the -fsanitize=address option while trouble shooting issue #98. Signed-off-by: Hans Beckerus <hans.beckerus at gmail.com>

hasse69 pushed a commit that referenced this issue Oct 22, 2018

Add mutex lock to protect reads in raw mode

86939fe

This patch should resolve the problem with sporadic crashes as reported in issue #98. Signed-off-by: Hans Beckerus <hans.beckerus at gmail.com>

hasse69 closed this as completed Oct 29, 2018

hasse69 mentioned this issue Jan 8, 2021

Transport endpoint is not connected #153

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rar2fs crash with corrupted double linked list error #98

rar2fs crash with corrupted double linked list error #98

Darkvater commented Oct 10, 2018 •

edited

Darkvater commented Oct 10, 2018 •

edited

Darkvater commented Oct 10, 2018 •

edited

hasse69 commented Oct 10, 2018 •

edited

Darkvater commented Oct 16, 2018

Darkvater commented Oct 16, 2018

hasse69 commented Oct 16, 2018

hasse69 commented Oct 16, 2018

Darkvater commented Oct 19, 2018 •

edited

hasse69 commented Oct 19, 2018

Darkvater commented Oct 20, 2018 •

edited

hasse69 commented Oct 20, 2018

Darkvater commented Oct 20, 2018

hasse69 commented Oct 20, 2018

hasse69 commented Oct 20, 2018

Darkvater commented Oct 20, 2018

hasse69 commented Oct 21, 2018 •

edited

hasse69 commented Oct 22, 2018

Darkvater commented Oct 28, 2018

hasse69 commented Oct 29, 2018

rar2fs crash with corrupted double linked list error #98

rar2fs crash with corrupted double linked list error #98

Comments

Darkvater commented Oct 10, 2018 • edited

1

2

Darkvater commented Oct 10, 2018 • edited

Darkvater commented Oct 10, 2018 • edited

hasse69 commented Oct 10, 2018 • edited

Darkvater commented Oct 16, 2018

Darkvater commented Oct 16, 2018

hasse69 commented Oct 16, 2018

hasse69 commented Oct 16, 2018

Darkvater commented Oct 19, 2018 • edited

hasse69 commented Oct 19, 2018

Darkvater commented Oct 20, 2018 • edited

Update1:

Update2:

Update3:

Update4:

hasse69 commented Oct 20, 2018

Darkvater commented Oct 20, 2018

hasse69 commented Oct 20, 2018

hasse69 commented Oct 20, 2018

Darkvater commented Oct 20, 2018

hasse69 commented Oct 21, 2018 • edited

hasse69 commented Oct 22, 2018

Darkvater commented Oct 28, 2018

hasse69 commented Oct 29, 2018

Darkvater commented Oct 10, 2018 •

edited

Darkvater commented Oct 10, 2018 •

edited

Darkvater commented Oct 10, 2018 •

edited

hasse69 commented Oct 10, 2018 •

edited

Darkvater commented Oct 19, 2018 •

edited

Darkvater commented Oct 20, 2018 •

edited

hasse69 commented Oct 21, 2018 •

edited