installModule() crashes if Module Manager not open
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mudlet |
Fix Released
|
Medium
|
Stephen Lyons |
Bug Description
I'm getting this crash using latest release_30 branch (5dcf32ab3a7f78
lua installModule(
Thread 1 (Thread 0x7ffff7f9d7c0 (LWP 12723)):
#0 0x000000000046ac24 in QWidget:
No locals.
#1 0x000000000046abfb in QWidget::isVisible (this=0xf60324) at /usr/include/
No locals.
#2 0x00000000005a0351 in mudlet:
No locals.
#3 0x000000000065f2df in TLuaInterpreter
modName = {static npos = <optimised out>, _M_dataplus = {<std::
pHost = 0x1ce4b60
module = {static null = {<No data fields>}, d = 0x2f18c40}
#4 0x00007ffff797af78 in ?? () from /usr/lib/
No symbol table info available.
If I open the module manager window, the command runs fine.
summary: |
- Crash using installModule + installModule() crashes if Module Manager not open |
Changed in mudlet: | |
status: | New → Confirmed |
assignee: | nobody → Stephen Lyons (slysven) |
status: | Confirmed → In Progress |
Changed in mudlet: | |
status: | Fix Committed → Fix Released |
The function concerned is:
int TLuaInterpreter ::installModule ( lua_State * L)
lua_pushstring ( L, "installModule: wrong first argument (should be a path to module)"); ::luaInterprete rMap[L] ; eSeparators( modName. c_str() ); installPackage( module, 3 ) && mudlet: :self() ->moduleTableVi sible() )
mudlet: :self() ->layoutModules ();
{
string modName;
if ( ! lua_isstring( L, 1 ) )
{
lua_error( L );
return 1;
}
else
modName = lua_tostring( L, 1);
Host * pHost = TLuaInterpreter
QString module = QDir::fromNativ
if( pHost )
if ( pHost->
return 0;
}
The conversion from the supplied argument has not been Utf8-ified (yet) but that is not important, neither is is the conversion from native file separators IMHO. I think the test for `mudlet: :self() ->moduleTableVi sible() ` SHOULD BE BEFORE `pHost- >installPackage ( module, 3 )` - the evaluation order is wrong!
BTW what about the case where there is more than one profile active and the module manager window is open FOR THE OTHER PROFILE? I think we may have issues with that sort of thing where there is a resource that is shared between all the profiles but each profile thinks it can use the common resource without checking that it is the "active" profile...