#477: Carpet commit f33caf3aba96 (hg) breaks timer output in CCTK_Terminate ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: eschnett Type: defect | Status: review Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by rhaas):
alright, I tracked it down to a return statement in Carpet/Carpet/src/OutputGH.cc line 65 which exits OutputGH after start() but without calling stop(). This only triggers if there are no IO methods (so never occured in real runs I assume). Solutions are obviously to add the timer.stop() call right before the return, or to move the timer.start() call after the if statement and return. Best might be though to have helper class that calls start() in its constructor and stop() in its destructor to time blocks (so that the compiler makes sure that stop() is called):
{{{ class timedblock { public: timedblock(Timer& timer_) timer(timer_) {timer.start();}; ~timedblock() {timer.stop();}; private: Timer& timer; } }}}
I have attached a patch to minimally call stop() before the return in OutputGH and some sanity checks in Timers.cc as well as replacing the assert in TimerNode.cc with a CCTK_WARN. All compile and let me run the test_22.par. They produce the proper error message when I undo the fix as well. Ok to apply?
Looking at the timer classes I noticed that most of the ones dealing with names take and return string objects (rather then references to strings). Since this means that temporary storage for the strings has to be allocated (on the heap via new), it might be a better to use references to string objects to avoid the new/delete pair for timers that are measuring very short intervals.