Yep, and I appreciate the report and the stack trace. Your example
crashes on a strcpy, which fails because there is no terminating null in
the random data. I changed that to a strncpy, to prevent the problem,
but the issue still persists because the size I am passing as the 'n' in
strncpy is als
Am 28.02.21 um 17:32 schrieb Troy A. Griffitts:
The problem would be the same if ZIP was the default and you gave the
ZIP compression driver LZSS data files.
I tried several combinations of wrong input for the other compression
types after finding the bug and it turned out the others error, wh
Hi Troy, I think I caused confusion by saying it is an experimental compression driver but I guess I mixed that up with the other compression forms we have in the engine but do not really support. So, me bad here. PeterSent from my mobile. Please forgive shortness, typos and weird autocorrects.---
Maybe I don't understand. It is the default because it is the first compression
type we supported and was the compression type of STEP data files (which
previously was an open standard for Bible data; not having anything to do with
the STEP Bible Project).
The problem would be the same if ZIP w
Still unanswered is Bastian’s good question “Why is it the default then?”
David
Sent from ProtonMail Mobile
On Sun, Feb 28, 2021 at 03:06, Troy A. Griffitts wrote:
> 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.
>
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 signatu
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#Req
Could you put a bug report into JIRA?As such the LZSS code is experimental and should not be relied upon. PeterSent from my mobile. Please forgive shortness, typos and weird autocorrects. Original Message Subject: [sword-devel] Segfault in LZSS codeFrom: Bastian Germann To: SWORD De
Hi,
When sword reads a ZIP-compressed zLD module with bad conf file that has
CompressType=LZSS (or no CompressType), sword segfaults. To reproduce,
modify Nave's conf file accordingly and start Xiphos, Bibletime, or
diatheke -b Nave -k ... (tried on Debian bullseye):
(gdb) bt
#0 0x7
