|
Bugzilla – Full Text Bug Listing |
| Summary: | LogComponentEnableAll(LOG_LEVEL_ALL) not working as intended (output blocked) | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Tommaso Pecorella <tommaso.pecorella> |
| Component: | ipv6 | Assignee: | Tommaso Pecorella <tommaso.pecorella> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ns-bugs, pdbarnes, tomh |
| Priority: | P3 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | patch to the documentation | ||
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 |
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.