Found that TVar default constructor (the one with NO arguments) does NOT
initialise the `parent` member to a null pointer.  Subsequently in the
auto load case (but not the normal profile loading case apparently) the
first time that (QStringList)VarUnit::shortVarName(TVar * var) is called
the call to:


{noted above as the line before the crash was happening} was returning a
garbage (but not NULL) pointer that when used in p->getName() != "_G"
was the cause of the Segment Violation crash.

I am just writing code to initialise ALL the members of the TVar class for ALL 
the constructors (some
members are not initialised in ANY of them).  Will post the Pull Requests here 
that apply the fix shortly.

** Changed in: mudlet
     Assignee: (unassigned) => Stephen Lyons (slysven)

** Changed in: mudlet
       Status: New => In Progress

You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.

  Crash on first use of TVar::getName() during autologin

Status in Mudlet:
  In Progress

Bug description:
  Whilst working on the development branch I decided to enable the autologin 
(check box on "connection preferences" dialog) and found that it seg. faults 
consistently on the first use of TVar::getName()
  whilst loading in the selected profile.  I rechecked on the release_30 
(post-"delta") preview and got precisely the same behaviour at the same point, 
for the latter the top end of the stack trace was:

  1   QString::QString                                        qstring.h      
898  0x467a1a       
  2   TVar::getName                                           TVar.cpp       68 
  3   VarUnit::shortVarName                                   VarUnit.cpp    
153  0x74974a       
  4   VarUnit::addSavedVar                                    VarUnit.cpp    
189  0x749d1d       
  5   XMLimport::readVariableGroup                            XMLimport.cpp  
240  0x7579a6       
  6   XMLimport::readVariablePackage                          XMLimport.cpp  
293  0x757e3c       
  7   XMLimport::readPackage                                  XMLimport.cpp  
588  0x759b72       
  8   XMLimport::importPackage                                XMLimport.cpp  
146  0x756f84       
  9   mudlet::doAutoLogin                                     mudlet.cpp     
2152 0x5fabd1       
  10  mudlet::startAutoLogin                                  mudlet.cpp     
2119 0x5fa57d       
  11  mudlet::qt_static_metacall                              moc_mudlet.cpp 
300  0x76e4d3       
  ... <More>                                                                    

  At 3 we have:

  QStringList VarUnit::shortVarName(TVar * var){
      QStringList names;
      if (!var || var->getName() == "_G"){
          names << "";
          return names;
      names << var->getName();
      TVar * p = var->getParent();
  ==> while (p && p->getName() != "_G"){ <== Where crash is happening
          p = p->getParent();
      return names;

  and looking in the debugger p, although non-zero {and thus passing the first 
test in the while(...)}
  it is NOT a valid entity, i.e. the preceding var->getParent() is NOT 
producing a valid value.

  As this is a regression (it disables autologin) it must be rated at least a 
"High" priority item only the fact that the ability to start a profile 
automatically is a useful rather than an essential feature stops this being a 
"Critical" - as well as indicating how many users (none at all)
  seem to be using it for the latest code versions.  I will investigate further 
and try and triage what introduced it, but I expect some re-factoring has 
eliminated some initialization step that is needed when auto-login is used but 
is not encountered otherwise...!

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to