[sword-devel] Release-critical TODO items

Troy A. Griffitts scribe at crosswire.org
Mon Apr 27 00:04:54 MST 2009


Ben,

I know you realize this, but we're at 2349 now.  I realize the revision 
you're giving is the first revision you see the troubles, but I just 
want to make sure you're seeing the troubles with 2349.  I just ran 
valgrind against a basic test that instantiates a few VerseKey objects 
and didn't see any troubles.  I ran through valgrind and it was clean.

Could you try for me to do a:

make distclean
./autogen.sh
./usrinst.sh
make
sudo make install

and then try your test again?

I wish I had some info, but my tests don't fail here.  Keep me posted 
with what you find.

	-Troy.



Ben Morgan wrote:
> On Mon, Apr 27, 2009 at 2:39 PM, Jonathan Marsden <jmarsden at fastmail.fm 
> <mailto:jmarsden at fastmail.fm>> wrote:
> 
> 
>     3) SWIG issues and related segfaults (Ben)
> 
> 
> This came with r2313, and I'm at a loss how to deal with it...
> Python program (this worked r2312, crashes r2313):
> import Sword
> Sword.VerseKey()
> 
> valgrind gives this (as well as others, but this is the first)
> ==10943== Invalid write of size 1
> ==10943==    at 0x48A26D1: sword::VerseKey::init() (versekey.cpp:62)
> ==10943==    by 0x48A7F13: sword::VerseKey::VerseKey(char const*) 
> (versekey.cpp:103)
> ==10943==    by 0x4818B18: _wrap_new_VerseKey (Sword.cxx:7023)
> ==10943==    by 0x407E65C: PyCFunction_Call (methodobject.c:108)
> ==10943==    by 0x4048846: PyObject_Call (abstract.c:1861)
> ==10943==    by 0x40CA8D2: PyEval_EvalFrameEx (ceval.c:3853)
> ==10943==    by 0x40CDBD1: PyEval_EvalCodeEx (ceval.c:2836)
> ==10943==    by 0x406A7A9: function_call (funcobject.c:517)
> ==10943==    by 0x4048846: PyObject_Call (abstract.c:1861)
> ==10943==    by 0x40500D4: instancemethod_call (classobject.c:2519)
> ==10943==    by 0x4048846: PyObject_Call (abstract.c:1861)
> ==10943==    by 0x40940DD: slot_tp_init (typeobject.c:4943)
> ==10943==  Address 0x45B55D4 is not stack'd, malloc'd or (recently) free'd
> ==10943==
> 
> gdb gives a stack trace of:
> 0x00b86050 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6
> (gdb) bt
> #0  0x00b86050 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6
> #1  0x00569706 in std::_Rb_tree_iterator<std::pair<sword::SWBuf const, 
> sword::SWLocale*> >::operator++ (this=0xbfe04c28)
>     at 
> /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:190
> #2  0x0056798b in sword::LocaleMgr::deleteLocales (this=0x81de948)
>     at ../src/mgr/localemgr.cpp:193
> #3  0x00567a67 in ~LocaleMgr (this=0x81de948) at 
> ../src/mgr/localemgr.cpp:138
> #4  0x00568c34 in ~__staticsystemLocaleMgr (this=0x62abe0)
>     at ../src/mgr/localemgr.cpp:47
> #5  0x005674c8 in __tcf_0 () at ../src/mgr/localemgr.cpp:48
> #6  0x0095e9d9 in exit () from /lib/libc.so.6
> #7  0x00948df4 in __libc_start_main () from /lib/libc.so.6
> #8  0x080484a1 in _start ()
> 
> God Bless,
> Ben
> -------------------------------------------------------------------------------------------
> Multitudes, multitudes,
>    in the valley of decision!
> For the day of the LORD is near
>    in the valley of decision.
> 
> Giôên 3:14 (ESV)
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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




More information about the sword-devel mailing list