Re: [sword-devel] breakage in verse management at -r2785?
Has anyone tested how -r2785 manages for John 8 in the SBLGNT which omits the Pericope Adulterae? In the SBLGNT module, John 8 starts at verse 12, and John 7 omits verse 53. Question prompted by an unrelated bug reported for And Bible. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/breakage-in-verse-management-at-r2785-tp4652055p4652098.html Sent from the SWORD Dev mailing list archive at Nabble.com. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
Hi Greg,
In your test, on like 19, you turn off auto normalization. This means
SWORD won't mess with the values you set for the components of a verse.
If you setText(Gen.1.1); setChapter(999); setVerse(); and print,
you should get Genesis 999:. If you want normalization, then you
need to remove the line in your test which says key-setAutoNormalize(0);
There is a good encapsulation of how I expect normalization to work in
the test suite. The specific test is:
http://crosswire.org/svn/sword/trunk/tests/versekeytest.cpp
And the expected output is:
http://crosswire.org/svn/sword/trunk/tests/testsuite/versekeytest.good
(the labels in that test still use the old terminology of 'headings',
but this is really 'intros')
On 03/22/2013 02:02 AM, Greg Hellings wrote:
Test code: https://gist.github.com/greg-hellings/5218094
Output with your current patch, Troy, is $ g++ `pkg-config --cflags
sword` `pkg-config --libs sword` test.cpp -o test ./test
intro: 0
bk (1): 1
ch (1): 1
vs (1): 1
-
intro: 0
bk (1): 0
ch (1): 0
vs (1): 0
-
intro: 1
bk (0): 0
ch (0): 0
vs (0): 0
-
The value in parenthsis represents what I thought the value should
be. If I comment out line 19, I get this result $ g++ `pkg-config
--cflags sword` `pkg-config --libs sword` test.cpp -o test ./test
intro: 0
bk (1): 1
ch (1): 1
vs (1): 1
-
intro: 0
bk (1): 1
ch (1): 1
vs (1): 1
-
intro: 1
bk (0): 0
ch (0): 0
vs (0): 0
-
which matches the expected results. So Xiphos is getting around
calling setIntros(1) by instead disabling auto-normalizing. It's odd
to me that you can set a key to a value in the intros while setIntros
is false. That doesn't seem like normalizing to me, that seems more
like bounds checking, but that's not necessarily a bug in the API,
possibly it's a bug in my understanding of intended behavior.
Troy's fix along with shuffling the location of setTestament (a change
I made earlier to Xiphos' Subversion) fixes the known bugs I've seen
in Xiphos regarding chapters not rendering and Genesis 1:1 causing a
SegFault.
--Greg
On Thu, Mar 21, 2013 at 6:51 PM, Greg Hellings
greg.helli...@gmail.com mailto:greg.helli...@gmail.com wrote:
On Thu, Mar 21, 2013 at 6:26 PM, Troy A. Griffitts
scr...@crosswire.org mailto:scr...@crosswire.org wrote:
Thanks Karl,
Yes, each snippet was helpful. Nic's was a quick test which
caused the bug and was easy to use for testing. Greg's snippet
wasn't as helpful as all his comments and stack traces leading
up to his patch. He is preventing book from getting to 0 which
does alleviate the problem but also stops a book from becoming
an intro. Hope that explains.
If the conditional in my code is changed to
if (book (intros?0:1) ) {
Then my code corrects the problem that -- was moving a VerseKey
from Genesis 1:1 to [Testament 1 Intro] when intros is false.
While not a SegFault producing bug, this is still a bug. Similar
checks should be made through the same run of code to ensure
moving to verse 0 and chapter 0 are not possible when intros is
false. Both your fix and an adapted form of mine should be
introduced. Additionally, the issue with OSISFootnotes should
probably be fixed.
I will write up a simple test case for that, if it helps, once I
get back to my development machine.
--Greg
Troy
Karl Kleinpaste k...@kleinpaste.org
mailto:k...@kleinpaste.org wrote:
You didn't also need this snippet from Greg a couple days
ago? --- src/keys/versekey.cpp (revision 2792) +++
src/keys/versekey.cpp (working copy) @@ -1347,7 +1347,9 @@
} 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));
sword-devel mailing list: sword-devel@crosswire.org
mailto:sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above
page
--
Sent from my Android phone with K-9 Mail. Please excuse my
brevity.
___
sword-devel mailing list: sword-devel@crosswire.org
mailto:sword-devel@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your
Re: [sword-devel] breakage in verse management at -r2785?
The presence or absence of a verse in a particular module should not matter. It should merely be a matter of whether the v11n defines it. On Mar 22, 2013, at 5:02 AM, David Haslam dfh...@googlemail.com wrote: Has anyone tested how -r2785 manages for John 8 in the SBLGNT which omits the Pericope Adulterae? In the SBLGNT module, John 8 starts at verse 12, and John 7 omits verse 53. Question prompted by an unrelated bug reported for And Bible. David ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
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.helli...@gmail.com
mailto:greg.helli...@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.helli...@gmail.com mailto:greg.helli...@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 205..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.helli...@gmail.com mailto:greg.helli...@gmail.com wrote:
On Mon, Mar 18, 2013 at 5:07 PM, Troy A. Griffitts
scr...@crosswire.org mailto:scr...@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
Re: [sword-devel] breakage in verse management at -r2785?
You didn't also need this snippet from Greg a couple days ago?
--- src/keys/versekey.cpp (revision 2792)
+++ src/keys/versekey.cpp (working copy)
@@ -1347,7 +1347,9 @@
}
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));
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
Thanks, seems to work for me. :)
On 22/03/2013, at 9:40 AM, Troy A. Griffitts scr...@crosswire.org wrote:
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.helli...@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.helli...@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 205..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.helli...@gmail.com
wrote:
On Mon, Mar 18, 2013 at 5:07 PM, Troy A. Griffitts scr...@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.
Re: [sword-devel] breakage in verse management at -r2785?
Thanks Karl,
Yes, each snippet was helpful. Nic's was a quick test which caused the bug and
was easy to use for testing. Greg's snippet wasn't as helpful as all his
comments and stack traces leading up to his patch. He is preventing book from
getting to 0 which does alleviate the problem but also stops a book from
becoming an intro. Hope that explains.
Troy
Karl Kleinpaste k...@kleinpaste.org wrote:
You didn't also need this snippet from Greg a couple days ago?
--- src/keys/versekey.cpp (revision 2792)
+++ src/keys/versekey.cpp (working copy)
@@ -1347,7 +1347,9 @@
}
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));
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
On Thu, Mar 21, 2013 at 6:26 PM, Troy A. Griffitts scr...@crosswire.orgwrote:
Thanks Karl,
Yes, each snippet was helpful. Nic's was a quick test which caused the bug
and was easy to use for testing. Greg's snippet wasn't as helpful as all
his comments and stack traces leading up to his patch. He is preventing
book from getting to 0 which does alleviate the problem but also stops a
book from becoming an intro. Hope that explains.
If the conditional in my code is changed to
if (book (intros?0:1) ) {
Then my code corrects the problem that -- was moving a VerseKey from
Genesis 1:1 to [Testament 1 Intro] when intros is false. While not a
SegFault producing bug, this is still a bug. Similar checks should be made
through the same run of code to ensure moving to verse 0 and chapter 0 are
not possible when intros is false. Both your fix and an adapted form of
mine should be introduced. Additionally, the issue with OSISFootnotes
should probably be fixed.
I will write up a simple test case for that, if it helps, once I get back
to my development machine.
--Greg
Troy
Karl Kleinpaste k...@kleinpaste.org wrote:
You didn't also need this snippet from Greg a couple days ago?
--- src/keys/versekey.cpp (revision 2792)
+++ src/keys/versekey.cpp (working copy)
@@ -1347,7 +1347,9 @@
}
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));
--
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
sword-devel mailing list: sword-devel@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
Test code: https://gist.github.com/greg-hellings/5218094
Output with your current patch, Troy, is $ g++ `pkg-config --cflags sword`
`pkg-config --libs sword` test.cpp -o test ./test
intro: 0
bk (1): 1
ch (1): 1
vs (1): 1
-
intro: 0
bk (1): 0
ch (1): 0
vs (1): 0
-
intro: 1
bk (0): 0
ch (0): 0
vs (0): 0
-
The value in parenthsis represents what I thought the value should be. If
I comment out line 19, I get this result $ g++ `pkg-config --cflags sword`
`pkg-config --libs sword` test.cpp -o test ./test
intro: 0
bk (1): 1
ch (1): 1
vs (1): 1
-
intro: 0
bk (1): 1
ch (1): 1
vs (1): 1
-
intro: 1
bk (0): 0
ch (0): 0
vs (0): 0
-
which matches the expected results. So Xiphos is getting around calling
setIntros(1) by instead disabling auto-normalizing. It's odd to me that you
can set a key to a value in the intros while setIntros is false. That
doesn't seem like normalizing to me, that seems more like bounds checking,
but that's not necessarily a bug in the API, possibly it's a bug in my
understanding of intended behavior.
Troy's fix along with shuffling the location of setTestament (a change I
made earlier to Xiphos' Subversion) fixes the known bugs I've seen in
Xiphos regarding chapters not rendering and Genesis 1:1 causing a SegFault.
--Greg
On Thu, Mar 21, 2013 at 6:51 PM, Greg Hellings greg.helli...@gmail.comwrote:
On Thu, Mar 21, 2013 at 6:26 PM, Troy A. Griffitts
scr...@crosswire.orgwrote:
Thanks Karl,
Yes, each snippet was helpful. Nic's was a quick test which caused the
bug and was easy to use for testing. Greg's snippet wasn't as helpful as
all his comments and stack traces leading up to his patch. He is preventing
book from getting to 0 which does alleviate the problem but also stops a
book from becoming an intro. Hope that explains.
If the conditional in my code is changed to
if (book (intros?0:1) ) {
Then my code corrects the problem that -- was moving a VerseKey from
Genesis 1:1 to [Testament 1 Intro] when intros is false. While not a
SegFault producing bug, this is still a bug. Similar checks should be made
through the same run of code to ensure moving to verse 0 and chapter 0 are
not possible when intros is false. Both your fix and an adapted form of
mine should be introduced. Additionally, the issue with OSISFootnotes
should probably be fixed.
I will write up a simple test case for that, if it helps, once I get back
to my development machine.
--Greg
Troy
Karl Kleinpaste k...@kleinpaste.org wrote:
You didn't also need this snippet from Greg a couple days ago?
--- src/keys/versekey.cpp (revision 2792)
+++ src/keys/versekey.cpp (working copy)
@@ -1347,7 +1347,9 @@
}
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));
--
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
sword-devel mailing list: sword-devel@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
hmmm... which matches the expected results. So Xiphos is getting around calling setIntros(1) by instead disabling auto-normalizing. It's odd to me that you can set a key to a value in the intros while setIntros is false. That doesn't seem like normalizing to me, that seems more like bounds checking, but that's not necessarily a bug in the API, possibly it's a bug in my understanding of intended behavior. What should the behaviour be when intros are off and you try key-setVerse(0)? should it then go to the last verse in the previous chapter or bump up to verse 1 in the current chapter? If we were already at verse 1 we decremented the key, it should go to the previous chapter's last verse, but in this case (given it's been set explicitly to verse 0), would it be more correct to bump up to the first valid verse in the current chapter (so, verse 0/intro if intros are switched on, or verse 1 if intros are switched off)? My thought is that it shouldn't allow it to stay at verse 0, but when normalize() is called, it should fix it to a valid verse for that versification system (given intros are switched off and there is no such thing as verse 0 in that case)? But then again, I am probably in the same boat as Greg and maybe I just don't understand the intended behaviour of the API in this situation? Thanks, ybic nic... :)___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
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.helli...@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.helli...@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 205..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.helli...@gmail.com
wrote:
On Mon, Mar 18, 2013 at 5:07 PM, Troy A. Griffitts scr...@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
Re: [sword-devel] breakage in verse management at -r2785?
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.helli...@gmail.comwrote:
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 205..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.helli...@gmail.comwrote:
On Mon, Mar 18, 2013 at 5:07 PM, Troy A. Griffitts
scr...@crosswire.orgwrote:
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 0x7527724c in sword::VersificationMgr::Book::getVerseMax
(this=0xa60028, chapter=17424)
at
/home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241
#2 0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290)
at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243
#3 0x7525b65b in sword::VerseKey::normalize (this=0xdcc290,
autocheck=true)
at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353
#4 0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290,
iverse=0)
at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523
#5 0x752596b3 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 0x752570d8 in sword::VerseKey::parse (this=0xeb7fa0,
checkAutoNormalize=true)
at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293
#7 0x004922df in sword::VerseKey::setText (this=0xeb7fa0,
ikey=0xd04b20 Genesis 0:0)
at /usr/local/include/sword/versekey.h:210
#8 0x00492310 in sword::VerseKey::operator= (this=0xeb7fa0,
ikey=0xd04b20 Genesis 0:0)
at /usr/local/include/sword/versekey.h:475
#9 0x752df98f in sword::OSISFootnotes::processText
Re: [sword-devel] breakage in verse management at -r2785?
Troy, Karl, It should also be noted that this update to SWORD causes a segfault in the following code in Xiphos https://gist.github.com/anonymous/5187582 Specifically the line key-setAutoNormalize(oldAutoNorm); on line 38 of that Gist generates a SegFault with the following backtrace. #0 0x75278ef0 in std::vectorint, std::allocatorint ::size (this=0x676e6175685a20) at /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626 #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0x1249a60) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0x1249a60, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bc85 in sword::VerseKey::setAutoNormalize (this=0x1249a60, iautonorm=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1548 #5 0x0049e118 in GTKChapDisp::getVerseBefore (this=0xefc930, imodule=...) at ../src/main/display.cc:1138 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 k...@kleinpaste.orgwrote: 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@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
Also, I just committed a fix that permits Xiphos to display text. The issue was, after attempting to fetch material from 0:0 and n:0 the restoration was being done through a call to setBook setChapter setVerse setTestament I moved the setTestament to be the first call and text display works swimmingly. Except I still see the segfault I mentioned in trying to navigate to Genesis 1:1 in both our KJV and ASVD. Xiphos head SVN should work for other references now, though. --Greg On Mon, Mar 18, 2013 at 9:41 AM, Greg Hellings greg.helli...@gmail.comwrote: Troy, Karl, It should also be noted that this update to SWORD causes a segfault in the following code in Xiphos https://gist.github.com/anonymous/5187582 Specifically the line key-setAutoNormalize(oldAutoNorm); on line 38 of that Gist generates a SegFault with the following backtrace. #0 0x75278ef0 in std::vectorint, std::allocatorint ::size (this=0x676e6175685a20) at /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626 #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0x1249a60) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0x1249a60, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bc85 in sword::VerseKey::setAutoNormalize (this=0x1249a60, iautonorm=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1548 #5 0x0049e118 in GTKChapDisp::getVerseBefore (this=0xefc930, imodule=...) at ../src/main/display.cc:1138 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 k...@kleinpaste.orgwrote: 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@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
On Mon, Mar 18, 2013 at 9:41 AM, Greg Hellings greg.helli...@gmail.comwrote: Troy, Karl, It should also be noted that this update to SWORD causes a segfault in the following code in Xiphos https://gist.github.com/anonymous/5187582 Specifically the line key-setAutoNormalize(oldAutoNorm); on line 38 of that Gist generates a SegFault with the following backtrace. #0 0x75278ef0 in std::vectorint, std::allocatorint ::size (this=0x676e6175685a20) at /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626 #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0x1249a60) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0x1249a60, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bc85 in sword::VerseKey::setAutoNormalize (this=0x1249a60, iautonorm=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1548 #5 0x0049e118 in GTKChapDisp::getVerseBefore (this=0xefc930, imodule=...) at ../src/main/display.cc:1138 I'm still seeing a SegFault as before, after I fixed the issue with other text not displaying. However, the offending line is now display.cc:1130 which is lines 30-32 of the code I pasted above. The stack trace looks like this #0 0x75278ef0 in std::vectorint, std::allocatorint ::size (this=0x676e6175685a20) at /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626 #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0xdcc290, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290, iverse=0) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523 #5 0x752596b3 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 0x752570d8 in sword::VerseKey::parse (this=0xeb7fa0, checkAutoNormalize=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293 #7 0x004922df in sword::VerseKey::setText (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:210 #8 0x00492310 in sword::VerseKey::operator= (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:475 #9 0x752df98f in sword::OSISFootnotes::processText (this=0xef4920, text=..., key=0xd14a00, module=0xef9618) at /home/ghellings/Projects-old/sword/src/modules/filters/osisfootnotes.cpp:65 #10 0x75296fec in sword::SWModule::filterBuffer (this=0xef9618, filters=0xef90b0, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:1352 #11 0x75297aa1 in sword::SWModule::optionFilter (this=0xef9618, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/include/swmodule.h:622 #12 0x75293ea7 in sword::SWModule::renderText (this=0xef9618, buf=0x0, len=-1, render=true) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:826 #13 0x0049219f in sword::SWModule::operator char const* (this=0xef9618) at /usr/local/include/sword/swmodule.h:709 #14 0x0049e093 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 k...@kleinpaste.orgwrote: 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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
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'll try to have a look soon. Troy On 03/18/2013 05:12 PM, Greg Hellings wrote: #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0xdcc290, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290, iverse=0) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523 #5 0x752596b3 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 0x752570d8 in sword::VerseKey::parse (this=0xeb7fa0, checkAutoNormalize=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293 #7 0x004922df in sword::VerseKey::setText (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:210 #8 0x00492310 in sword::VerseKey::operator= (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:475 #9 0x752df98f in sword::OSISFootnotes::processText (this=0xef4920, text=..., key=0xd14a00, module=0xef9618) at /home/ghellings/Projects-old/sword/src/modules/filters/osisfootnotes.cpp:65 #10 0x75296fec in sword::SWModule::filterBuffer (this=0xef9618, filters=0xef90b0, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:1352 #11 0x75297aa1 in sword::SWModule::optionFilter (this=0xef9618, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/include/swmodule.h:622 #12 0x75293ea7 in sword::SWModule::renderText (this=0xef9618, buf=0x0, len=-1, render=true) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:826 #13 0x0049219f in sword::SWModule::operator char const* (this=0xef9618) at /usr/local/include/sword/swmodule.h:709 #14 0x0049e093 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 k...@kleinpaste.org mailto:k...@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@crosswire.org mailto:sword-devel@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@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
On Mon, Mar 18, 2013 at 5:07 PM, Troy A. Griffitts scr...@crosswire.orgwrote: 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 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0xdcc290, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290, iverse=0) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523 #5 0x752596b3 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 0x752570d8 in sword::VerseKey::parse (this=0xeb7fa0, checkAutoNormalize=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293 #7 0x004922df in sword::VerseKey::setText (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:210 #8 0x00492310 in sword::VerseKey::operator= (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:475 #9 0x752df98f in sword::OSISFootnotes::processText (this=0xef4920, text=..., key=0xd14a00, module=0xef9618) at /home/ghellings/Projects-old/sword/src/modules/filters/osisfootnotes.cpp:65 #10 0x75296fec in sword::SWModule::filterBuffer (this=0xef9618, filters=0xef90b0, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:1352 #11 0x75297aa1 in sword::SWModule::optionFilter (this=0xef9618, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/include/swmodule.h:622 #12 0x75293ea7 in sword::SWModule::renderText (this=0xef9618, buf=0x0, len=-1, render=true) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:826 #13 0x0049219f in sword::SWModule::operator char const* (this=0xef9618) at /usr/local/include/sword/swmodule.h:709 #14 0x0049e093 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 k...@kleinpaste.orgwrote: 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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list:
Re: [sword-devel] breakage in verse management at -r2785?
Karl, I'll have a look. Those changes were fairly major and I was worried I might have broken something. The test suite passes, so I will try to include your use case in the test suite to assure better coverage, once we determine what that is. Do you have an idea of how you are using versekey? When you display a chapter, are you iterating on the key or on the module? Any help to reproduce the problem in a snippet of code would be greatly appreciated. I'll let you know what I find. Karl Kleinpaste k...@kleinpaste.org wrote: Someone came into #xiphos to note a problem in Xiphos' operation in recent builds. I hadn't done much with Xiphos in some weeks, so I updated all source and rebuilt my world. I get a similar result as this fellow's screenshot: http://ompldr.org/vaHB0eg/Screenshot%20from%202013-03-10%2019:34:05.jpg Only Gen 1 displays correctly; all other chapters are a similar mess. Building successive Sword revisions through 2788, I found the problem begins at 2785. I won't even pretend to understand all that's going on in the fairly large change to versekey.cpp, but clearly something in this area has done some damage at this point, at least insofar as Xiphos uses it. Can those more well-informed take a close look at what's been done at 2785 and suggest something as to what could have gone wrong here? ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
Regrets for not following up until this evening; I can send mail here
only from home, being firewalled at the office these days.
Troy A. Griffitts scr...@crosswire.org writes:
Do you have an idea of how you are using versekey?
When you display a chapter, are you iterating on the key or on the module?
The essential code is:
VerseKey *key = (VerseKey *)(SWKey *)imodule;
int curVerse = key-getVerse();
int curChapter = key-getChapter();
int curBook = key-getBook();
for (key-setVerse(1);
(key-getBook()== curBook)
(key-getChapter() == curChapter)
!imodule.popError();
imodule++) {
/* ... lots of hacking based on current key ... */
}
I've been wondering literally for years why key is typecast twice, from
module through SWKey to VerseKey, but this code predates my presence and
there's actually quite a lot that I've learned to accept somewhat
uncritically. If there is a better way to loop through this, by all
means re-educate me.
--karl
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
Thanks Karl,
I just checked in a showchapter.cpp example here, which I think
represents your use case:
http://crosswire.org/svn/sword/trunk/examples/classes/showchapter.cpp
It seems to work for me with this execution:
./showchapter jonah.3.1
Could it be the module being used that trips the error? Or maybe the
normalization or intros settings on the key?
Troy
On 03/12/2013 01:31 AM, Karl Kleinpaste wrote:
Regrets for not following up until this evening; I can send mail here
only from home, being firewalled at the office these days.
Troy A. Griffitts scr...@crosswire.org writes:
Do you have an idea of how you are using versekey?
When you display a chapter, are you iterating on the key or on the module?
The essential code is:
VerseKey *key = (VerseKey *)(SWKey *)imodule;
int curVerse = key-getVerse();
int curChapter = key-getChapter();
int curBook = key-getBook();
for (key-setVerse(1);
(key-getBook()== curBook)
(key-getChapter() == curChapter)
!imodule.popError();
imodule++) {
/* ... lots of hacking based on current key ... */
}
I've been wondering literally for years why key is typecast twice, from
module through SWKey to VerseKey, but this code predates my presence and
there's actually quite a lot that I've learned to accept somewhat
uncritically. If there is a better way to loop through this, by all
means re-educate me.
--karl
___
sword-devel mailing list: sword-devel@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
On Mon, Mar 11, 2013 at 7:51 PM, Troy A. Griffitts scr...@crosswire.orgwrote:
Thanks Karl,
I just checked in a showchapter.cpp example here, which I think
represents your use case:
http://crosswire.org/svn/**sword/trunk/examples/classes/**showchapter.cpphttp://crosswire.org/svn/sword/trunk/examples/classes/showchapter.cpp
It seems to work for me with this execution:
./showchapter jonah.3.1
Could it be the module being used that trips the error? Or maybe the
normalization or intros settings on the key?
The latter option seems the most likely. Karl and others have seen this
behavior starting with r2785, which was the big commit you made regarding
the HunKar module's odd behavior in BibleTime when normalization and intros
were present and enabled in certain ways. It's possible that the way Xiphos
accesses the modules is sufficiently different from BibleTime (BT is av11n
aware while Xiphos is not yet) that the code which seems to work OK in
BibleTime breaks in Xiphos now.
--Greg
Troy
On 03/12/2013 01:31 AM, Karl Kleinpaste wrote:
Regrets for not following up until this evening; I can send mail here
only from home, being firewalled at the office these days.
Troy A. Griffitts scr...@crosswire.org writes:
Do you have an idea of how you are using versekey?
When you display a chapter, are you iterating on the key or on the
module?
The essential code is:
VerseKey *key = (VerseKey *)(SWKey *)imodule;
int curVerse = key-getVerse();
int curChapter = key-getChapter();
int curBook = key-getBook();
for (key-setVerse(1);
(key-getBook()== curBook)
(key-getChapter() == curChapter)
!imodule.popError();
imodule++) {
/* ... lots of hacking based on current key ... */
}
I've been wondering literally for years why key is typecast twice, from
module through SWKey to VerseKey, but this code predates my presence and
there's actually quite a lot that I've learned to accept somewhat
uncritically. If there is a better way to loop through this, by all
means re-educate me.
--karl
__**_
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/**mailman/listinfo/sword-develhttp://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
__**_
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/**mailman/listinfo/sword-develhttp://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] breakage in verse management at -r2785?
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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
[sword-devel] breakage in verse management at -r2785?
Someone came into #xiphos to note a problem in Xiphos' operation in recent builds. I hadn't done much with Xiphos in some weeks, so I updated all source and rebuilt my world. I get a similar result as this fellow's screenshot: http://ompldr.org/vaHB0eg/Screenshot%20from%202013-03-10%2019:34:05.jpg Only Gen 1 displays correctly; all other chapters are a similar mess. Building successive Sword revisions through 2788, I found the problem begins at 2785. I won't even pretend to understand all that's going on in the fairly large change to versekey.cpp, but clearly something in this area has done some damage at this point, at least insofar as Xiphos uses it. Can those more well-informed take a close look at what's been done at 2785 and suggest something as to what could have gone wrong here? ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
