Error in Mac80211::handleLowerMsg (MiXiM)

[wsa]

Hello everyone,

I'm running a simulation using the default BaseNodes with the 802.11
Nic.

The nodes use broadcast to communicate, which works quite well under
my working machine (Windows 7 x64) in debug mode.

When running the simulation on Ubuntu 9.10 machines using opp_runall
in release mode, the simulation crashes from time to time with the
following error message:

Model error: in handleMsgForMe() IDLE/CONTEND, strange message <name
of my message>

It seems like in Mac80211.cc, the message is incorrectly considered to
be a message with a destination address instead of a broadcast
message:

if(af->getDestAddr() == myMacAddr) {
handleMsgForMe(af);
}
else if(af->getDestAddr() == L2BROADCAST) {
handleBroadcastMsg(af);
}

I send broadcast messages by subclassing the BaseApplLayer and using
the following code:

Beacon* beacon = new Beacon( "beacon", BEACON_MESSAGE );
beacon->setBitLength( headerLength );
beacon->setControlInfo( new NetwControlInfo( L3BROADCAST ) );
sendDown( beacon );

Once a packet is received at a node, it is forwarded (broadcast) using
the following modification:

NetwControlInfo* ctrl = check_and_cast<NetwControlInfo*>( beacon-
>getControlInfo() );
ctrl->setNetwAddr( L3BROADCAST );
sendDownDelayed( beacon, delay );

This very odd behavior seems to appear more or less randomly on the
Ubuntu machines (it's not really possible to reproduce the error in a
controlled manner).
Sometimes it helps to modify the omnetpp.ini by adding or removing the
following line (cmdenv-express-mode is set to true):

**.cmdenv-ev-output = true

Has anyone else ever noticed such behavior or is there anything wrong
in my code above?
Thank you very much for any help or advice!

[wsa]

I'm not totally sure if I found the reason, but if I recall correctly,
in release mode variables are not initialized like in debug mode.
Since I didn't subclass my message 'Beacon' from 'ApplPkt', the
destination address wasn't set like this:

beacon->setDestAddr( L3BROADCAST );
beacon->setSrcAddr( myApplAddr() );

Now I'm subclassing from ApplPkt and added the above lines to each
node sending resp. forwarding the packets and for now it seems to run
without errors.

Thanks anyway!

[wsa]

I'm sorry to say this isn't the reason, the code still crashes like
described in the original post.
I'd be happy if someone was able to provide me a hint on what might be
going wrong here.

Thank you!

[Daniel Willkomm]

HI,

I suspect this is not a windows / ubuntu issue. My guess would be that you
somehow do not initialize / delete some variables / messages correctly.

If I remeber correctly, runall runs all configs one after another. However,
inbetween runs omnet does not restart and keeps some state, so if you mess up
with deletion of messages or do not properly initialize some stuff you might
get strange behavior.

I would check, if you get the same errors running each config separately. You
could also check whether you get the same errors using runall in windows.

If the individual configs all run without error, then it is very likely that
you experience what I described above. If so, it may be very hard to debug.
You'll have to dig deep into your code to understand what exactly is causing
the error

Hope this helps

Daniel

--
-----------------------------------------
o Dipl.-Ing. Daniel Willkomm
o TU-Berlin
o Telecommunication Networks Group
o http://www.tkn.tu-berlin.de/~willkomm/
o Mail: will...@tkn.tu-berlin.de

[wsa]

Hello,

thank you for your response.

I've now tried to only start the single run, which seems to cause this
behavior, using the simulation executable (without opp_runall).
Still the error seems to occur as long as one of the following lines
is part of the omnetpp.ini:

cmdenv-express-mode = true
**.cmdenv-ev-output = true

Once I comment out both of these lines, the simulation just runs fine
(also opp_runall seems to work will all runs).
This shouldn't be the case if something is initialized incorrectly?

Is it possible that there is a problem with OMNeT itself? (I'm using
version 4.1)
Might OMNeT behave differently when the above options are set?

Thanks again for any hints or advice!

[Andreas Köpke]

Looks like you face one of the more nasty bugs: a so called Heisenbug.
Something, somewhere in the code is not correct, and you should make all effort
to correct it -- the problem will surface at more places once you continue
with your simulations.

Here is a list of tools that might help:

- valgrind
- stack smashing protection
- a modern alternative to lint

Happy hunting,

Andreas

[wsa]

Thank you very much for the hint on these tools!