Bugzilla – Bug 980
NSC build failure, not detected by ns-3
Last modified: 2010-09-22 16:22:24 EDT
Building on a recently updated 32-bit Ubuntu 9.10: linux-2.6.18/include/net/sock.h: In function 'skb_copy_to_page': linux-2.6.18/include/net/sock.h:1070: warning: pointer targets in passing argument 1 of 'csum_and_copy_from_user' differ in signedness linux-2.6.18/include/net/checksum.h:30: note: expected 'const unsigned char *' but argument is of type 'char *' linux-2.6.18/nsc/implemented.c: At top level: linux-2.6.18/nsc/implemented.c:180: error: redefinition of '__memcpy' linux-2.6.18/include/asm/string.h:203: note: previous definition of '__memcpy' was here scons: *** [linux-2.6.18/nsc/implemented.globalised.o] Error 1 scons: building terminated because of errors. # Build NSC: failure (ignoring NSC) However, ./waf configure on the ns-3-dev directory subsequently yields: Network Simulation Cradle : enabled As a result, attempts to use NSC in test suite or examples will crash. System details: glibc: Version: 2.10.1-0ubuntu17 gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) Linux ns-ubuntu-karmic 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux This is ns-ubuntu-karmic machine, available from ns-regression.
Also confirmed this on 32-bit Fedora 12 machine. Tracked it to this changeset: changeset: 287:f1fbe61c8daf tag: tip user: Sam Jansen <sam@wand.net.nz> date: Tue Aug 03 14:24:55 2010 -0700 summary: Push linker scripts suggested by Mathieu Lacage.
(In reply to comment #1) > Also confirmed this on 32-bit Fedora 12 machine. Tracked it to this changeset: > > changeset: 287:f1fbe61c8daf > tag: tip > user: Sam Jansen <sam@wand.net.nz> > date: Tue Aug 03 14:24:55 2010 -0700 > summary: Push linker scripts suggested by Mathieu Lacage. Just to add a bit more on this one, I think it is important that this is addressed from the ns-3 side of things. Regardless of whether or not NSC is breaking on some machines, ns-3 should be able to handle it and not enable.
(In reply to comment #2) > (In reply to comment #1) > > Also confirmed this on 32-bit Fedora 12 machine. Tracked it to this changeset: > > > > changeset: 287:f1fbe61c8daf > > tag: tip > > user: Sam Jansen <sam@wand.net.nz> > > date: Tue Aug 03 14:24:55 2010 -0700 > > summary: Push linker scripts suggested by Mathieu Lacage. > > Just to add a bit more on this one, I think it is important that this is > addressed from the ns-3 side of things. Regardless of whether or not NSC is > breaking on some machines, ns-3 should be able to handle it and not enable. I don't think you can expect the ns-3 code to detect magically that the nsc code is not building.
> > I don't think you can expect the ns-3 code to detect magically that the nsc > code is not building. One thing it could do is to check for presence of the nsc libraries used in ns-3 test suites (e.g. nsc_dir/linux-2.6.18/liblinux2.6.18.so). This list of known libraries would need to be maintained.
This should now be fixed. It was a problem on 32-bit only, hence me not picking it up first time around. If others are happy with this, I'll make a new NSC release this week.
The crashes reported here also happened to me recently: http://groups.google.com/group/ns-3-users/browse_thread/thread/9e25e1e714f7be64 IMO, our build system should try to detect the presence of the libraries used in the test suite during the configuration stage.
I think it's reasonable for ns3 to check for the existence of the NSC libraries before running the tests. After all the tests themselves have these library names in them. I think the actual build failure that happened should be fixed now with the latest version of NSC. I'm unsure whether or not this is the case. Do you think there is still an NSC issue here?
(In reply to comment #7) > I think it's reasonable for ns3 to check for the existence of the NSC libraries > before running the tests. After all the tests themselves have these library > names in them. > > I think the actual build failure that happened should be fixed now with the > latest version of NSC. I'm unsure whether or not this is the case. Do you think > there is still an NSC issue here? I don't think it is an NSC issue anymore. I think it should be a minor patch to src/internet-stack/wscript to detect whether liblinux2.6.26.so is missing, so it can report something like: conf.report_optional_feature("nsc", "Network Simulation Cradle", False, "NSC library liblinux2.6.26.so is missing") (liblinux2.6.26.so is the version used in the regression TCP tests)
Created attachment 980 [details] fixes bug: checks for liblinux2.6.26.so Patch attached that should fix this. I did a small tidy up of at least some of the Python code there too - it is starting to get a bit messy. I've tested this out and it is sane and seems the pragmatic solution to checking for NSC existence.
(In reply to comment #9) > Created an attachment (id=980) [details] > fixes bug: checks for liblinux2.6.26.so > > Patch attached that should fix this. I did a small tidy up of at least some of > the Python code there too - it is starting to get a bit messy. > > I've tested this out and it is sane and seems the pragmatic solution to > checking for NSC existence. Thanks; Mitch will apply this early next week if there are no further comments.
When I patched the latest version of ns-3-dev, the following 3 tests no longer worked: CRASH: TestSuite nsc-tcp-loss CRASH: TestSuite ns3-tcp-cwnd CRASH: TestSuite ns3-tcp-interoperability All of the tests were working before the patch Here is my history (let me know if I made any mistakes): 346 hg clone http://code.nsnam.org/ns-3-allinone 347 ls 348 cd ns-3-allinone/ 349 ls 350 ./download.py 351 7./build.py 352 ./build.py 353 ls 354 cd ns-3-dev 355 ls 356 ./waf configure 357 ./waf build 358 ./test.py 359 hg pull 360 hg update 361 patch -p1 < ../../diff.txt 362 hg diff | less 363 ./waf configure 364 ./waf build 365 ./test 366 ./test.py
My machine, ns-test, is running Fedora 12. Maybe the NSC library, liblinux2.6.26.so, has a different name on Fedora?
This seems to be because the tests TestSuite nsc-tcp-loss TestSuite ns3-tcp-cwnd TestSuite ns3-tcp-interoperability Are not explicitly dependent on the variable ENABLE_NSC in the test.py script. It's not immediately evident how they should be configured there. Somehow we need to make sure these tests are not run when ENABLE_NSC=False; this already works for e.g. tcp/tcp-nsc-lfn but the code there seems specific to tests in the examples/ directory. Maybe the maintainer of test.py can point us in the right direction? (who is that?)
Created attachment 984 [details] patch against ns-3-allinone to fix nsc build output dir One other thing we are missing is correct build functionality in ns-3-allinone. Attached is a small patch there. The idea is that we want the resulting NSC libraries to be in the nsc/ directory; rather than in their subdirectories - the current build command doesn't really issue the right scons command-line. Patch should be applied against the head of ns-3-allinone.
(In reply to comment #13) > > Maybe the maintainer of test.py can point us in the right direction? (who is > that?) Craig has been maintaining test.py but I have discussed with him that Mitch is available to handle the open bugs against the test framework, and he agreed.
The combination of the old and new patches made the tests succeed. I am going to update the ns-3-dev and ns-3-allinone repositories.
I have created a new bug 999 for the issue of test suites failing when NSC has not been built.
ns-3-dev changeset: ca451dc20c4d ns-3-allinone changeset: 4f638e1c45cb