Greg,
The bad news: I haven't yet hooked heading logic back up in the new
dynamic versification code. You can probably turn headings off in your
key and it will work. I'll try to get the heading logic back into the
new code soon for you.
The good news: the KJV versification scheme is now supplied dynamically
to the engine and mostly works, thus other versification schemes should
mostly work as well.
Greg Hellings wrote:
> With the latest round of updates to SVN, the patch for mod2osis that I
> included was broken, so I've set about fixing that. However, it also
> broke the osis2mod utility, thus making my testing quite difficult.
> GDB says that the seg fault happens on line 969 of osis2mod.cpp which
> is the first line below:
>
> else if (RawText::createModule(path)) {
> fprintf(stderr, "error: %s: couldn't create
> module at path: %s \n", program, path);
> exit(-3);
> }
>
> However, I'm at a loss as to what is going on here. The program
> segfaults somewhere in that function call to
> RawText::createModule(path) and here is the GDB backtrace of it:
>
> (gdb) r . kjv.xml
> Starting program: /home/hellings1/Public/sword-svn/utilities/osis2mod . kjv.xml
> warning: Lowest section in /usr/lib/libicudata.so.38 is .hash at
> 0000000000000120
> [Thread debugging using libthread_db enabled]
> You are running osis2mod: $Rev: 2183 $
> [New Thread 0x7f6b5b186710 (LWP 7192)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7f6b5b186710 (LWP 7192)]
> 0x0000000000417c12 in __normal_iterator (this=0x7fff631aadf0, __i=@0x20)
> at /usr/include/c++/4.2/bits/stl_iterator.h:653
> 653 __normal_iterator(const _Iterator& __i) : _M_current(__i) { }
> (gdb) bt
> #0 0x0000000000417c12 in __normal_iterator (this=0x7fff631aadf0, __i=@0x20)
> at /usr/include/c++/4.2/bits/stl_iterator.h:653
> #1 0x0000000000417c3b in std::vector<long, std::allocator<long>
>> ::end (this=0x18)
> at /usr/include/c++/4.2/bits/stl_vector.h:346
> #2 0x0000000000416347 in sword::VerseMgr::System::getVerseFromOffset
> (this=0xc25868, offset=1,
> book=0x7fff631aaeb4, chapter=0x7fff631ab00c, verse=0x7fff631ab010)
> at ../src/mgr/versemgr.cpp:237
> #3 0x000000000040ebd8 in sword::VerseKey::Index (this=0x7fff631aaf70, iindex=1)
> at ../src/keys/versekey.cpp:1462
> #4 0x000000000040c88e in sword::VerseKey::increment
> (this=0x7fff631aaf70, step=1)
> at ../src/keys/versekey.cpp:1072
> #5 0x0000000000412566 in sword::VerseKey::operator+=
> (this=0x7fff631aaf70, steps=1)
> at ../include/versekey.h:436
> #6 0x0000000000412589 in sword::VerseKey::operator++
> (this=0x7fff631aaf70) at ../include/versekey.h:436
> #7 0x00000000004222f9 in sword::RawVerse::createModule
> (ipath=0x7fff631ac6ba ".")
> at ../src/modules/common/rawverse.cpp:267
> #8 0x00000000004099bb in sword::RawText::createModule (path=0x7fff631ac6ba ".")
> at ../include/rawtext.h:47
> #9 0x0000000000407c4a in main (argc=3, argv=0x7fff631ab5a8) at osis2mod.cpp:969
>
> This is almost identical to the seg fault that I had with mod2osis.
> With that seg fault the error was happening when a call was made to
> (*inModule) = TOP at the beginning of a for loop to iterate over the
> entire module. I could skirt the issue in mod2osis by just assigning
> the key to Gen.1.1, but this is less than ideal, if the module were,
> say, only comprised of the new testament or some such thing. However,
> the segmentation fault shouldn't be happening at all.
>
> For the meantime, I can check the results using the osis2mod program
> from 1.5.11, but these should obviously be fixed up.
>
> --Greg
>
> _______________________________________________
> 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