Bugzilla – Bug 1286
LogComponentEnableAll(LOG_LEVEL_ALL) not working as intended (output blocked)
Last modified: 2016-03-11 15:40:02 UTC
If you set LogComponentEnableAll(LOG_LEVEL_ALL) the output hangs after some function calls. The simulation goes on, but no log is sent. I don't know if this a MacOS specific issue, but I tracked it down, and the issue seems to be that "primitive" types, like uint8_t, can not use directly the ostreams. Example: uint8_t Ipv6Extension::ProcessOptions (Ptr<Packet>& packet, uint8_t offset, uint8_t length, Ipv6Header const& ipv6Header, Ipv6Address dst, uint8_t *nextHeader, bool& isDropped) { NS_LOG_FUNCTION (this << packet << offset << length << ipv6Header << dst << nextHeader << isDropped); [...] } does block the output. The issue is solved with an explicit cast: uint8_t Ipv6Extension::ProcessOptions (Ptr<Packet>& packet, uint8_t offset, uint8_t length, Ipv6Header const& ipv6Header, Ipv6Address dst, uint8_t *nextHeader, bool& isDropped) { NS_LOG_FUNCTION (this << packet << int(offset) << int(length) << ipv6Header << dst << (int*)(nextHeader) << isDropped); [...] } The only problems are: 1) is this a MacOS specific issue or it's happening also on other platforms?, and, 2) how to fix it in a "generic" way? I fear that the issue is quite spread among the whole ns-3 code.
reproduces on Linux. How to reproduce: NS_LOG="*" ./waf --run loose-routing-ipv6 dies at: 1.01034s 2 Ipv6Extension:Process(0x996b00, 0x99e610, ^@, (Version 6 Traffic class 0x0 Flow Label 0x0 Payload Length 1120 Next Header 43 Hop Limit 64 )2001:0001:0000:0000:0200:00ff:fe00:0001 > 2001:0001:0000:0000:0200:00ff:fe00:0002, 2001:0001:0000:0000:0200:00ff:fe00:0002, I don't know of a general fix for this, offhand.
In other IPv6 parts (such as IPv6L3Protocol), the logs for uint8_t are cast to uint32_t. Back in the time I wrote the IPv6 implementation, I have not found another way to fix that.
Thanks for the feedback. I guess the best approach is: 1) test using a simple program what's the "safest" set of types handled by NS_LOG 2) write a policy about using NS_LOG functions 3) change all the actual occurrence to the safe subset. The alternative might be to use a class inside NS_LOG to handle the castings. I don't know if this is simple or not tho. I'll provide a test program as soon as I can. Tommaso
Created attachment 2307 [details] patch to the documentation I guess that this specific bug can be closed. it is now well known that uint_8 values should *not* be used as they are in cout or NS_LOG, as they do provide strange results. As a result, I'd simply amend the documentation and close this bug.
Can you add a comment that this (char-wide ints interpreted as ints) is a C++ "feature".
changeset 12023:acdb24087b27