Bugzilla – Bug 1853
NS_LOG_FUNCTION broken on OSX 10.9
Last modified: 2014-02-21 19:32:53 UTC
On 10.9 with new STL library, when function logging is enabled, the first NS_LOG_FUNCTION will cause segfault: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000001dcd64ffc 0x00007fff8ef6b8d3 in std::__1::ios_base::__call_callbacks () (gdb) bt #0 0x00007fff8ef6b8d3 in std::__1::ios_base::__call_callbacks () #1 0x00007fff8ef6b876 in std::__1::ios_base::~ios_base () #2 0x00000001000b4866 in ns3::ParameterLogger::~ParameterLogger (this=0x7fff5fbfd228) at log.h:400 (http://code.nsnam.org/ns-3-dev/file/ed02f0e3b1e7/src/core/model/log.h#l434) Basically, something funky is happening in new STL libraries std::ostream destructor, since ParameterLogger is inherited from it. The solution to this problem is actually very simple---remove inheritance from std::ostream, since it is never actually used...
Hi, I'm not able to reproduce the bug. Can you provide more info like actual compiler used and stl version (if they're not the ones shipped with Xcode) ? Thanks, T.
Huh... I though I have checked that the logger code hasn't been modified (I'm not using the dev version directly), but I wasn't very careful. Just figured out that the issue was reported before and solved in a different way as part of #1792 (I forgot to check .cc file last time). In any case. I would still suggest removing inheritance from std::ostream, since it is not used at all. *** This bug has been marked as a duplicate of bug 1792 ***
Reopened to track suggestion to remove unnecessary inheritance.
Created attachment 1782 [details] patch to remove inheritance from std::ostream Remove inheritance from std::ostream
Alex: could you please try the patch? Thanks, Peter
The patched code generates warning in clang---Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) ./ns3/log.h:444:5: warning: switch condition has boolean value switch (m_first) ^ ~~~~~~~
Created attachment 1784 [details] Patch v2. Updated patch, replacing switch (bool)
No warning with the second patch and no segfaults
Actually. There is still segfault with NS_LOG=*, but it is probably completely different story (though I thought we have already fixed that...) (first column is stack size.... it's huge) #51813 0x0000000103dd9906 in ns3::Time::Mark (time=0x7fff5fbfeb10) at ../src/core/model/time.cc:284 #51814 0x0000000100193c8c in ns3::Time::Time (this=0x7fff5fbfeb10, v=0) at nstime.h:176 #51815 0x0000000100193c3d in ns3::Time::Time (this=0x7fff5fbfeb10, v=0) at nstime.h:178 #51816 0x0000000101eed86c in ns3::TimeStep (ts=0) at nstime.h:987 #51817 0x0000000103e0a6c0 in ns3::DefaultSimulatorImpl::Now (this=0x10512acf0) at ../src/core/model/default-simulator-impl.cc:302 #51818 0x0000000103e03373 in ns3::Simulator::Now () at ../src/core/model/simulator.cc:185 #51819 0x0000000103e041e0 in ns3::TimePrinter (os=@0x7fff7b080438) at ../src/core/model/simulator.cc:61 #51820 0x0000000103f40b21 in ns3::CriticalSection::CriticalSection (this=0x7fff5fbfee98, mutex=@0x103f78780) at ../src/core/model/unix-system-mutex.cc:131 #51821 0x0000000103f40a7d in ns3::CriticalSection::CriticalSection (this=0x7fff5fbfee98, mutex=@0x103f78780) at ../src/core/model/unix-system-mutex.cc:133 #51822 0x0000000103dd9906 in ns3::Time::Mark (time=0x7fff5fbff0c0) at ../src/core/model/time.cc:284 #51823 0x0000000100193c8c in ns3::Time::Time (this=0x7fff5fbff0c0, v=0) at nstime.h:176 #51824 0x0000000100193c3d in ns3::Time::Time (this=0x7fff5fbff0c0, v=0) at nstime.h:178 #51825 0x0000000101eed86c in ns3::TimeStep (ts=0) at nstime.h:987 #51826 0x0000000103e0a6c0 in ns3::DefaultSimulatorImpl::Now (this=0x10512acf0) at ../src/core/model/default-simulator-impl.cc:302 #51827 0x0000000103e03373 in ns3::Simulator::Now () at ../src/core/model/simulator.cc:185 #51828 0x0000000103e041e0 in ns3::TimePrinter (os=@0x7fff7b080438) at ../src/core/model/simulator.cc:61 #51829 0x0000000103f40b21 in ns3::CriticalSection::CriticalSection (this=0x7fff5fbff448, mutex=@0x103f78780) at ../src/core/model/unix-system-mutex.cc:131 #51830 0x0000000103f40a7d in ns3::CriticalSection::CriticalSection (this=0x7fff5fbff448, mutex=@0x103f78780) at ../src/core/model/unix-system-mutex.cc:133 #51831 0x0000000103dd9906 in ns3::Time::Mark (time=0x7fff5fbff670) at ../src/core/model/time.cc:284 #51832 0x0000000100193c8c in ns3::Time::Time (this=0x7fff5fbff670, v=0) at nstime.h:176 #51833 0x0000000100193c3d in ns3::Time::Time (this=0x7fff5fbff670, v=0) at nstime.h:178 #51834 0x0000000101eed86c in ns3::TimeStep (ts=0) at nstime.h:987 #51835 0x0000000103e0a6c0 in ns3::DefaultSimulatorImpl::Now (this=0x10512acf0) at ../src/core/model/default-simulator-impl.cc:302 #51836 0x0000000103e03373 in ns3::Simulator::Now () at ../src/core/model/simulator.cc:185 #51837 0x0000000103e041e0 in ns3::TimePrinter (os=@0x7fff7b080438) at ../src/core/model/simulator.cc:61 #51838 0x0000000103e094da in ns3::DefaultSimulatorImpl::Stop (this=0x10512acf0, time=@0x7fff5fbff848) at ../src/core/model/default-simulator-impl.cc:212 #51839 0x0000000103e03318 in ns3::Simulator::Stop (time=@0x7fff5fbff848) at ../src/core/model/simulator.cc:176 #51840 0x00000001000026f0 in main (argc=1, argv=0x7fff5fbff880) at ../scratch/tmp.cc:23 (gdb) example that failed was a trivial one (and I'm using the latest ns-3-dev): #include "ns3/core-module.h" using namespace ns3; int main (int argc, char *argv[]) { Simulator::Stop(Seconds(10)); Simulator::Run (); Simulator::Destroy (); }
Patch r10624 c3e9a5530654 http://code.nsnam.org/ns-3-dev/rev/c3e9a5530654