[Ns-developers] Building and test problems

[Tom Henderson]

Fabian Mauchle wrote:
> -----Ursprüngliche Nachricht-----
> Von: ns-developers-bounces at ISI.EDU [mailto:ns-developers-bounces at ISI.EDU] Im
> Auftrag von Mathieu Lacage
> Gesendet: Mittwoch, 20. Mai 2009 13:08
> An: Faker Moatamri
> Cc: ns-developers at ISI.EDU
> Betreff: Re: [Ns-developers] Building and test problems
> 
> On Wed, 2009-05-20 at 12:01 +0200, Faker Moatamri wrote:
>> Hi All,
>>
>> After the last push on the server, ns-3-dev doesn't build anymore 
>> resulting in failure emails from buildbot. The reason that it doesnt 
>> build is that the python bindings are not up to date, so we just need to 
>> execute ./waf --python-scan .
> 
> I did re-run them yesterday so, theoretically, they are uptodate.
> Gustavo, do you have any idea of what the problem could be ? Could it be
> that I did not use the right version of pybindgen to generate them ? 
> 
>> After getting it to build, the check test and the regression tests fail 
>> saying:
>>
>> Event is still running while destroying.
>> Command 
>>
> ['/auto/elvis/u/elvis/1/user/fmoatamr/src/fresh/build/debug/utils/run-tests'
> ] 
>> exited with code -11
>>
>> Event is still running while destroying.
>> Command 
>>
> ['/auto/elvis/u/elvis/1/user/fmoatamr/src/fresh/build/debug/examples/simple-
> point-to-point-olsr'] 
>> exited with code -11
>> FAIL test-simple-point-to-point-olsr
>>
>> I guess this is related to the bug 568...
> 
> I thought I had run the regression tests but I obviously failed to do
> so. Do you think you could try to see what the problem is ?
> 
> Mathieu
> --------------------
> Same to me :(
> 
> The second failing test is simply a mistakenly default-initialized Timer in
> olsr-routing-protocol.cc
> Just add m_queuedMessagesTimer (Timer::CANCEL_ON_DESTROY) to the
> initialization list in the constructor.
> 
> The first is in the unit test for the Timer. The scheduled event is the last
> do be run, and is still reported Running after Simulator::Run() has finished
> and the call to Simulator::Destroy().
> 
> A possible solution would be to increment the Simulator::m_currentUid after
> the for-loop in Simulator::Run() implementations.

I simply initialized this timer to CANCEL_ON_DESTROY to get things 
working again (previously, this timer did not have any cancellation 
policy due to the initialization bug); if someone wants to make this 
test more sophisticated, feel free to change it in the future.

- Tom