Closed gt1 closed 7 years ago
This crashed as the second argument was too large. In the perfect case daligner would guard against that instead of crashing.
Anyway, the reason this was observed was a /tmp directory on a drive with insufficient space. The messages I got were
LAmerge: System error, read failed! LAcheck: Cannot open ./dmel_30.19.dmel_30.19.las for 'r' LAmerge: Cannot open ./dmel_30.19.dmel_30.19.las for 'r' Usage: LAcheck [-vS] src1:db|dam [ src2:db|dam ] align:las ... rm: cannot remove ‘dmel_30.19.dmel_30.19.las’: No such file or directory
None of these report any issues with writing data, which is not surprising considering that e.g. none of the return codes of fwrite in LAsort are checked.
I have hit a seg fault while using daligner on a set of simulated D.mel reads:
Command line:
daligner -T32 -M56 dmel_30.19 dmel_30
The crash occured on a certain block (19 in this case), thus the block id on the command line. The original crash was using an HPC.daligner generated script on the whole dataset though.
Debugger output:
(gdb) run -T32 -M56 dmel_30.19 dmel_30 ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffec4ce1700 (LWP 7025)] 0x00000000004059f6 in tuple_thread (arg=0x7fffffffd500) at filter.c:464 464 list[n].read = i;