OMNeT++/OMNEST Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000399OMNeT++simulation kernelpublic2011-08-10 18:322012-02-07 15:58
Reporterjesjones 
Assigned Toandras 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version4.2b1 
Target VersionFixed in Version4.3b1 
Summary0000399: Can't tell where modules are while debugging
DescriptionIt's a serious annoyance to not have an easy way to tell which host a module is on while debugging. Patch below adds a way to do this.
Additional Information----------------------------- include/cmodule.h ------------------------------
index ac40f6e..b033f76 100755
@@ -207,16 +207,17 @@ class SIM_API cModule : public cComponent //implies noncopyable
 
   private:
     enum {
         FL_BUILDINSIDE_CALLED = 128, // whether buildInside() has been called
         FL_RECORD_EVENTS = 256, // enables recording events in this module
     };
 
   protected:
+ std::string fullpath; // useful for debugging (lastmodulefullpath is not reliable)
     mutable char *fullname; // buffer to store full name of object
     int mod_id; // id (subscript into cSimulation)
 
     // Note: parent module is stored in ownerp -- a module is always owned by its parent
     // module. If ownerp cannot be cast to a cModule, the module has no parent module
     // (e.g. the system module which is owned by the global object 'simulation').
     cModule *prevp, *nextp; // pointers to sibling submodules
     cModule *firstsubmodp; // pointer to first submodule

------------------------------ src/sim/cmodule.cc ------------------------------
index d3e6531..89f8af2 100755
@@ -1082,16 +1082,17 @@ int cModule::buildInside()
     // temporarily switch context
     cContextSwitcher tmp(this);
     cContextTypeSwitcher tmp2(CTX_BUILD);
 
     // call doBuildInside() in this context
     doBuildInside();
 
     setFlag(FL_BUILDINSIDE_CALLED, true);
+ fullpath = getFullPath();
 
     return 0;
 }
 
 void cModule::deleteModule()
 {
     // check this module doesn't contain the executing module somehow
     for (cModule *mod = simulation.getContextModule(); mod; mod = mod->getParentModule())
@@ -1154,16 +1155,17 @@ void cModule::changeParentTo(cModule *mod)
         tmp.newParentModule = mod;
         mod->emit(PRE_MODEL_CHANGE, &tmp);
     }
 
     // do it
     cModule *oldparent = getParentModule();
     oldparent->removeSubmodule(this);
     mod->insertSubmodule(this);
+ fullpath = getFullPath();
 
     // notify environment
     EVCB.moduleReparented(this,oldparent);
 
     // notify post-change listeners
     if (hasListeners(POST_MODEL_CHANGE)) {
         cPostModuleReparentNotification tmp;
         tmp.module = this;
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000595)
andras (administrator)
2011-11-15 14:02

cModule does not store full path because that would significantly increase memory footprint for large simulations.

However, in 4.2 we are making use of GDB's python-based pretty printer support (a recent GDB feature), and we are adding pretty printers for OMNeT++ classes. When you debug with CDT and select a module (or some other OMNeT++ class), the full path (plus some other info) will be displayed in the lower part of the watch window.
(0000596)
jesjones (reporter)
2011-11-15 17:59

But not everyone uses gdb. We, for example, use MSVC.
(0000600)
andras (administrator)
2011-11-16 10:56

Good point :)

OK, maybe an extra 'const char *' in cModule is acceptable. It could be an ini file setting whether the simkernel should actually fill them in during simulation, or they'd remain NULL; the default for the setting could be ON when the simulation is compiled for debug, and OFF when it is compiled for release.

Implementation note: the attached patch fails to update the string if the *parent* (or any ancestor) is reparented. changeParentTo() should probably update the fullpath strings in the whole module subtree.
(0000718)
andras (administrator)
2012-02-07 15:58

Done in the 4.3 branch

- Issue History
Date Modified Username Field Change
2011-08-10 18:32 jesjones New Issue
2011-11-15 14:02 andras Note Added: 0000595
2011-11-15 14:02 andras Status new => resolved
2011-11-15 14:02 andras Fixed in Version => 4.2
2011-11-15 14:02 andras Resolution open => no change required
2011-11-15 14:02 andras Assigned To => andras
2011-11-15 17:59 jesjones Note Added: 0000596
2011-11-15 17:59 jesjones Status resolved => feedback
2011-11-15 17:59 jesjones Resolution no change required => reopened
2011-11-16 10:56 andras Note Added: 0000600
2012-02-07 15:58 andras Note Added: 0000718
2012-02-07 15:58 andras Status feedback => resolved
2012-02-07 15:58 andras Fixed in Version 4.2 => 4.3b1
2012-02-07 15:58 andras Resolution reopened => fixed


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker