[sword-devel] 1.5.10RC1 available
Karl Kleinpaste
karl at kleinpaste.org
Sun Oct 7 19:21:47 MST 2007
Troy, on the strange key init bug that has haunted GnomeSword recently,
domcox has made this observation to me:
| If I increase the size of JUNKBUFSIZE in sword/include/swbuf.h from 8191
| to 16383 (#define JUNKBUFSIZE 16383): the bug is gone.
| I now suspect a memory overflow on a swbuf.appendFormatted or
| swbuf.setFormatted as these methods are limited to JUNKBUFSIZE per call.
I just tried this and can confirm it: Simply making JUNKBUFSIZE twice as
large makes the problem disappear. GnomeSword makes pretty heavy use of
appendFormatted() and setFormatted().
I suspect that the issue is that the new modules have larger amounts of
markup, and recent GnomeSword generates substantially more HTML on its
own than was previously generated prior to blocked Strongs/morph/lemma
markup. This combines with the fact that we're seeing this only in
Greek modules, which are using wide characters, and all in all, it looks
like we're just generating more stuff than will fit in 8k.
Such a situation is consistent with the increasingly random nature of
where we've been seeing failures -- at this point, the getZeroContent()
previously used is gone entirely (because the routine's content has been
subsumed into another), but we still consistently see the bug (with
original JUNKBUFSIZE) in the same Greek chapters...and I can make the
bug stop happening by disabling some of the Strongs/lemma/morph
features, thus reducing the size of the overall content that is
formatted and then shipped to the HTML widget.
Is there any grief that can be expected from making a permanent change
to 16k? We appear to have no reason to suspect anything stranger than
that overly long appends to a SWbuf are leading to random memory
corruption in following data structures in memory.
I really hope we're analyzing this correctly...
More information about the sword-devel
mailing list