4 ms·
I once had to debug a crash in a very popular program used in genomics (for those in the know, it was an early version of "samtools" IIRC) and I found it really
by lbeltrame 6y ago
I once had to debug a crash in a very popular program used in genomics (for those in the know, it was an early version of "samtools" IIRC) and I found it really hard to read.
(In the end the crash was due to corrupted input data, so I fixed the data and stopped debugging)
- masonic 6y agothe crash was due to corrupted input data Bad data shouldn't cause a crash. That's just sloppy.
- lbeltrame 6y agoIndeed: in fact someone must have found the issue eventually, as newer versions exited with an error instead of core dumping. Sadly, academic constraints (time; results required the day before) prevented me from actually filing a bug report.
- SiempreViernes 6y agoProper input validation is really hard, and a reliable crash on incorrect input is frankly much better than other alternatives such as soldiering on and output trash, or even worse seemingly fine results. Of course, it sucks if it takes a few hours before you get your crash, that usually tricks you into thinking the software did something wrong and not you. Best is if it dies immediately upon reading the input, and if it does that with an error or a crash isn't crucial, though of course getting a clear error message is always better. As a comparison, a collaboration internal tool I need to use will print a helpful usage message, and then segfault if you call it without any arguments...