[sword-devel] breakage in verse management at -r2785?

Troy A. Griffitts scribe at crosswire.org
Thu Mar 21 15:40:51 MST 2013


Thanks for all the help guys.

It seems the problem (or at least 'a' problem) was when you are set to 
an intro (or above) and you try to lookup ChapterMax or VerseMax.
I added a check to simply return 0 if this is called.

Nic's code snippet doesn't throw any valgrind errors anymore.

Hope this squashes this.

Let me know,

Troy



On 03/21/2013 03:40 AM, Nic Carter wrote:
> Ok, I have just looked into r2785 in PS.
>
> PS opened to the previous chapter/verse I had used in the app, but 
> when I tried to navigate to Genesis chapter 1 it exploded the same as 
> what has been reported.
>
> The code I have is:
>
> sword::VerseKey *curKey = (sword::VerseKey*)swModule->getKey();
> curKey->setIntros(YES);
> curKey->setText([chapter cStringUsingEncoding: NSUTF8StringEncoding]);
> curKey->setVerse(0);
>
> swModule->stripText();
>
> and the setText call is basically being given "Genesis 1". This code 
> has worked since day 1 of PS.
>
> The call to stripText() is where it explodes, and in my case, it is 
> thinking that it should be going to chapter 159607.
>
> Seems r2785 introduces a fun bug somewhere?
>
> Further testing reveals that it works fine bringing up Gen 2
> works fine bringing up Matt 1 (possible corner case, given it's the 
> first book in the NT?)
> works fine with Rev 1, Rev 22
>
> However, then randomly, I decided to try Gen 1 again & it worked!
> So I force quit the app, launched again & it resumed it's crashing on 
> Gen 1, this time thinking it was trying chapter 160880...  :/
>
> Moving the setIntros(YES) line below setText() did not solve the issue.
> However, removing the setIntros() line and changing the other line to 
> setVerse(1) DID seem to solve the crashing issue for me.
>
> So, it appears that when setIntros() is set to YES then the r2785 
> changes causes a crash.
>
> FYI, screenshot of the stack where it crashes is attached for fun :)
>
> Hope this helps? Gotta run off now, so I can't dig deeper right now...
>
>
> ybic
> nic...  :)
>
> // attachment removed as even tho it was only 10k, it failed to get 
> through without moderation :(
>
> On 20/03/2013, at 1:26 AM, Greg Hellings <greg.hellings at gmail.com 
> <mailto:greg.hellings at gmail.com>> wrote:
>
>> I have toyed with changing this on the Xiphos side, setting 
>> key.setIntros(1) before setting the key to 0:0 or 1:0 and rendering. 
>> The key that is used during rendering appears to be a copy of the 
>> module's key, and it does not appear to be preserving the value of 
>> the intros parameter. It seems like this should be a multi-point fix.
>>
>> 1) SWORD should not explode when intros == 0 and the user tries to 
>> navigate to a Genesis {1,0}:0 destination. My previous diff appears 
>> to handle that.
>> 2) Xiphos should properly call setIntros(1) before attempting to 
>> fetch 1:0 without the user's direct input (e.g. when the user has 
>> selected to view headings & intros). I have a diff in hand for this, 
>> but it does not resolve the problem because...
>> 3) SWORD should properly preserve the value of intros when copying 
>> the key for use during rendering.
>>
>> --Greg
>>
>>
>> On Tue, Mar 19, 2013 at 8:26 AM, Greg Hellings 
>> <greg.hellings at gmail.com <mailto:greg.hellings at gmail.com>> wrote:
>>
>>     The following diff seems to solve the problem. I don't know if
>>     it's the "correct" way to go about it, but it appears to resolve
>>     the issue from what I see in Xiphos. I have a feeling the
>>     "better" way to do it is to have Xiphos set the intros == 1
>>     before attempting to fetch intro material? My editor appears to
>>     have botched the white space, so please forgive that.
>>
>>     diff --git a/src/keys/versekey.cpp b/src/keys/versekey.cpp
>>     index 20cccc5..0290fd7 100644
>>     --- a/src/keys/versekey.cpp
>>     +++ b/src/keys/versekey.cpp
>>     @@ -1347,7 +1347,9 @@ void VerseKey::normalize(bool autocheck)
>>                             }
>>                             if (verse < (intros?0:1)) {
>>                                     if (--chapter < (intros?0:1)) {
>>     -                                       --book;
>>     +                    if (book > 1) {
>>     +                        --book;
>>     +                    }
>>                                             chapter +=
>>     (getChapterMax() + (intros?1:0));
>>                                     }
>>                                     verse += (getVerseMax() +
>>     (intros?1:0));
>>
>>
>>     On Mon, Mar 18, 2013 at 9:13 PM, Greg Hellings
>>     <greg.hellings at gmail.com <mailto:greg.hellings at gmail.com>> wrote:
>>
>>
>>
>>
>>         On Mon, Mar 18, 2013 at 5:07 PM, Troy A. Griffitts
>>         <scribe at crosswire.org <mailto:scribe at crosswire.org>> wrote:
>>
>>             Thanks Greg,
>>
>>             Any idea where chapter 17474 is coming from?
>>
>>             I can add code to check max before looking into the
>>             vector, which I'd rather not because it should be an
>>             unnecessary check each time and will be a speed hit, but
>>             even so, who ever is asking for the maximum verse for
>>             chapter 17474 is obviously doing something wrong.
>>
>>
>>         I'm hardly competent with a C debugger, but let's see what
>>         sense I can make of this. Somewhere in
>>         VerseKey::parseVerseList on line 944 (#5 in the stack trace)
>>         curKey has a value of 17425 for chapter. The text buffer
>>         reads "Genesis 1:0" and the value of the chap variable is 1.
>>
>>         The value of 17,425 is being set on line 1351 of versekey.cpp
>>         when a key value of "Genesis 1:0" is being parsed while
>>         intros == 0. This triggers the condition
>>
>>         if (verse < (intros?0:1))
>>
>>         which causes the resulting block to be executed. Xiphos
>>         believes that headings have been enabled here, and Xiphos has
>>         always considered 'Headings' and 'Introductions' to be
>>         synonymous from my understanding. I know there's been some
>>         discussion of the Headings/Intro distinction here lately, so
>>         I don't know if Xiphos is now running afoul of changes you
>>         made in this distinction due to prior bugs in the
>>         implementation that unified them or not?
>>
>>         I'm not sure if there's more I can contribute here without a
>>         deeper understanding of Xiphos' options and SWORD's parsing.
>>
>>         --Greg
>>
>>             I'll try to have a look soon.
>>
>>             Troy
>>
>>
>>
>>
>>             On 03/18/2013 05:12 PM, Greg Hellings wrote:
>>>             #1  0x00007ffff527724c in
>>>             sword::VersificationMgr::Book::getVerseMax
>>>             (this=0xa60028, chapter=17424)
>>>                 at
>>>             /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241
>>>             #2  0x00007ffff525aebb in sword::VerseKey::getVerseMax
>>>             (this=0xdcc290)
>>>                 at
>>>             /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243
>>>             #3  0x00007ffff525b65b in sword::VerseKey::normalize
>>>             (this=0xdcc290, autocheck=true)
>>>                 at
>>>             /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353
>>>             #4  0x00007ffff525bbe9 in sword::VerseKey::setVerse
>>>             (this=0xdcc290, iverse=0)
>>>                 at
>>>             /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523
>>>             #5  0x00007ffff52596b3 in
>>>             sword::VerseKey::parseVerseList (this=0xeb7fa0,
>>>             buf=0xea5e1b "", defaultKey=0x0, expandRange=false,
>>>             useChapterAsVerse=false) at
>>>             /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:944
>>>             #6  0x00007ffff52570d8 in sword::VerseKey::parse
>>>             (this=0xeb7fa0, checkAutoNormalize=true)
>>>                 at
>>>             /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293
>>>             #7  0x00000000004922df in sword::VerseKey::setText
>>>             (this=0xeb7fa0, ikey=0xd04b20 "Genesis 0:0")
>>>                 at /usr/local/include/sword/versekey.h:210
>>>             #8  0x0000000000492310 in sword::VerseKey::operator=
>>>             (this=0xeb7fa0, ikey=0xd04b20 "Genesis 0:0")
>>>                 at /usr/local/include/sword/versekey.h:475
>>>             #9  0x00007ffff52df98f in
>>>             sword::OSISFootnotes::processText (this=0xef4920,
>>>             text=..., key=0xd14a00, module=0xef9618)
>>>                 at
>>>             /home/ghellings/Projects-old/sword/src/modules/filters/osisfootnotes.cpp:65
>>>             #10 0x00007ffff5296fec in sword::SWModule::filterBuffer
>>>             (this=0xef9618, filters=0xef90b0, buf=..., key=0xd14a00)
>>>                 at
>>>             /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:1352
>>>             #11 0x00007ffff5297aa1 in sword::SWModule::optionFilter
>>>             (this=0xef9618, buf=..., key=0xd14a00)
>>>                 at
>>>             /home/ghellings/Projects-old/sword/include/swmodule.h:622
>>>             #12 0x00007ffff5293ea7 in sword::SWModule::renderText
>>>             (this=0xef9618, buf=0x0, len=-1, render=true)
>>>                 at
>>>             /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:826
>>>             #13 0x000000000049219f in sword::SWModule::operator char
>>>             const* (this=0xef9618) at
>>>             /usr/local/include/sword/swmodule.h:709
>>>             #14 0x000000000049e093 in GTKChapDisp::getVerseBefore
>>>             (this=0xf0b420, imodule=...) at ../src/main/display.cc:1130
>>>
>>>             When I drill all the way down in, the appear to try and
>>>             pull the verse max for chapter 17424 when asked to
>>>             render Genesis 0:0.
>>>
>>>             --Greg
>>>
>>>
>>>
>>>                 This segfault only seems to happen when I enter
>>>                 Genesis 1 in the navigation panel and not at any
>>>                 other time. Those with more gdb savvy than I can
>>>                 maybe figure out more of what is going on.
>>>
>>>                 --Greg
>>>
>>>
>>>                 On Mon, Mar 11, 2013 at 8:57 PM, Karl Kleinpaste
>>>                 <karl at kleinpaste.org <mailto:karl at kleinpaste.org>>
>>>                 wrote:
>>>
>>>                     I see that your new showchapter.cpp works.  The
>>>                     only difference in how
>>>                     that works versus Xiphos code is you changed the
>>>                     VerseKey init slightly,
>>>                     so I made that change:
>>>
>>>                     VerseKey *key = (VerseKey *)imodule.getKey();
>>>
>>>                     And yet Xiphos still fails to construct the
>>>                     chapter.  The loop never
>>>                     executes once.  I don't know what to make of it.
>>>                      I will have to look at
>>>                     it some more.
>>>
>>>                     _______________________________________________
>>>                     sword-devel mailing list:
>>>                     sword-devel at crosswire.org
>>>                     <mailto:sword-devel at crosswire.org>
>>>                     http://www.crosswire.org/mailman/listinfo/sword-devel
>>>                     Instructions to unsubscribe/change your settings
>>>                     at above page
>>>
>>>
>>>
>>>
>>>
>>>             _______________________________________________
>>>             sword-devel mailing list:sword-devel at crosswire.org  <mailto:sword-devel at crosswire.org>
>>>             http://www.crosswire.org/mailman/listinfo/sword-devel
>>>             Instructions to unsubscribe/change your settings at above page
>>
>>
>>             _______________________________________________
>>             sword-devel mailing list: sword-devel at crosswire.org
>>             <mailto:sword-devel at crosswire.org>
>>             http://www.crosswire.org/mailman/listinfo/sword-devel
>>             Instructions to unsubscribe/change your settings at above
>>             page
>>
>>
>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org 
>> <mailto:sword-devel at crosswire.org>
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130321/e0cb3d61/attachment-0001.html>


More information about the sword-devel mailing list