While I agree we probably shouldn't segfault, this is a bit like renaming xyz.exe to xyz.doc and trying to open it in Word.
Not that is matters, but the details are that the LZSS decompressor treats the entire block as uncompressed binary (because it doesn't encounter any compression block signatures, because the data is not LZSS data but instead ZIP encoded data) and does nothing with any of it, returning the zip compressed data as-is, resulting in binary gibberish when we reference it, so when we pull offset and size values from the "uncompressed" block (which really isn't uncompressed), we get essentially random numbers... which causes things to crash. Not sure what Word does when you give it a ".doc" file which is a binary, or MySQL does when you cat /dev/random > /var/data/mysql/ibdata1, but I would bet it doesn't behave very well. I would say the solution to this is don't give the LZSS filters ZIP compressed data. I can try to put some sanity checks in when I read the offset, size values from the "uncompressed" data and might be able to prevent a crash. Troy On 2/27/21 10:19 AM, Bastian Germann wrote: > Am 27.02.21 um 17:47 schrieb ref...@gmx.net: >> Could you put a bug report into JIRA? > > https://tracker.crosswire.org/browse/API-247 > >> As such the LZSS code is experimental and should not be relied upon. >> > > Why is it the default then? (according to > https://wiki.crosswire.org/DevTools:conf_Files#Required_Elements_with_defaults) > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
