[sword-devel] 1.5.10RC2 available
Troy A. Griffitts
scribe at crosswire.org
Mon Oct 8 11:47:01 MST 2007
JUNKBUFSIZE increased to 16k)
New autoconf check for vsnprintf to use this safe method instead, if
exists on the system (Daniel, are you proud to see me deal with my
Not sure if vsnprintf exists in BCB or VC. If it does not, or does not
operate correctly with null dest pointer, then we will need to add:
to the definitions during compilation. This will default to the old
code using junkbuf (with the newly increased 16k size)
Karl Kleinpaste wrote:
> 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...
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel