Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.5.8
-
Fix Version/s: 1.7.40
-
Component/s: core
-
Labels:None
Description
When bug API-24 was fixed it exposed a larger bug - if you change the stringmgr then the old localemgr gets deleted which deletes old locales.
This means that a versekey that is created before the stringmgr is changed will have an invalid locale and will reference an invlaid pointer and probably cause a crash.
As a workaround for 1.5.8 we don't set the default locale to LANG anymore but leave it as the hard-coded default en_US. It is up to the frontends to set the default locale if they want to.
We need to discuss on sword-devel how exactly we want to solve this.
Assigning to Joachim for 1.5.40 because StringMgr is his code.
Attachments
Activity
This bug still exists and can be seen when compiling a patched version of BibleTime SVN against SWORD's HEAD. I worked with Troy on IRC and we tracked the issue to line 213 of localemgr.cpp where the system was segfaulting during BibleTime's initial run. Troy suggested checking the pointer on the line rather than blindly referencing it.
Adding the phrase
if((*it).second != NULL)
to the beginning of line 213 seems to fix the problem - BibleTime started up fine, and it still displayed all of the installed locale possibilities. So... if someone wants to go ahead and test it and then fix it in HEAD if my fix actually is valid, it'd be much appreciated!
Is this resolved? Line 213 is now an empty line.
This is a hard issue, IMO, because we allow for runtime replacement of core facilities which are usually decided at compile time.
We do this so applications like Bibletime can use Qt instead of ICU, and Qt instead of CURL. Is this necessary? Maybe. If so, I would suggest:
removing:
setters for StringMgr and the like.
adding:
an interface:
{ void init(); }sword::InitLib
a method:
sword::initLib(const InitLib &)
a documented rule:
if you ever want to replace StringMgr, et. al. it is only done in your InitLib method, and you must always call sword:initLib before any other sword call is performed.
The downside of this is that it really doesn't solve the problem-- only document it. Why? The current impl lets you safely replace StringMgr, et. al. before any other sword call.
The real problem is a statically scoped variable. When you have a sword statically scoped variable like a VerseKey, it may get instantiated before your call to set StringMgr.
So, I guess, thinking out loud, I am in favor of leaving the ability to change these facilities at runtime, and leaving it up to the client of the engine to swap out these facilities first thing, if they wish to swap them out.