[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Daily Snapshot, Solaris, wireless-gridkeeper

To: [email protected]
Subject: Daily Snapshot, Solaris, wireless-gridkeeper
From: Stefan Dresler <[email protected]>
Date: Sun, 05 Sep 1999 18:47:45 +0200
cc: [email protected]
Sender: [email protected]

Dear NS-2'ers,

(weekend is ns-2 maintenance time)

after having problems with the daily snapshot from (around) 99-08-27
-- all tests failed on Solaris as well as on Linux --, I now downloaded
the snapshot on last Saturday again and discovered a problem during
validation.

This is sent in the hope that there is no stupid installation error on
my side, but rather a bug somewhere in the code that needs help to
be fixed.

For those interested in the problems I encountered please continue
reading. There is a list of warnings, one error and one test that
did not pass (wireless-gridkeeper), including debugging info.

For the record:
> uname -a
SunOS luna 5.7 Generic sun4u sparc SUNW,Ultra-1

> gcc -v
Reading specs from 
/usr/local/gnu/Solaris/lib/gcc-lib/sparc-sun-solaris2.6/2.95.1/specs
gcc version 2.95.1 19990816 (release)

---------------------------------------

First I discovered that I should give ns a hint by
setenv V_TCLSH /absolute-path/tclbox/bin/tclsh8.0.4
before running ./configure,
because otherwise in tcl/lib/ns-autoconf.tcl only a relative
path is included, which gives an error message if ns is started in
a directory different from its compilation directory.
Don't know whether this is really necessary or whether it has
been reported before; I didn't know, and it wasn't necessary in 2.1b5,
as the link to tclsh in ns-autoconf.tcl wasn't used then.

---------------------------------------

Then, as mentioned on this list earlier, I had to uncomment
a line in config.h:

<quoted from Sean Murphy>
My workaround was to comment out the offending line in config.h and ensure
that the -fsigned-char flag was set on compilation, to ensure that the
'typedef char int8_t' in the system header file was equivalent to 'typedef
In file included from random.h:41,
                 from random.cc:40:
config.h:58: conflicting types for `typedef signed char int8_t'
/usr/include/sys/int_types.h:62: previous declaration as `typedef char
int8_t'
make: *** [random.o] Error 1

I'm using solaris 2.6 and gcc 2.95
</quote>


...me too :-)


<quote again>
My workaround was to comment out the offending line in config.h and ensure
that the -fsigned-char flag was set on compilation, to ensure that the
'typedef char int8_t' in the system header file was equivalent to 'typedef
signed char int8_t'.
</quote again>

Is the second modification also necessary? Maybe my problem stems from
not making the second change... :-)


---------------------------------------

from the snapshot of 99-08-27, which didn't work at all:

still there (compared to last version I compiled):
rng.cc: In method `int RNG::command(int, const char *const *)':
rng.cc:232: warning: decimal integer constant is so large that it is unsigned

also still there:
traffictrace.cc: In method `int TraceFile::setup()':
traffictrace.cc:150: warning: comparison between signed and unsigned

new:
mac-802_11.cc: In method `int Mac802_11::check_pktCTRL()':
mac-802_11.cc:673: warning: unused variable `struct hdr_mac802_11 * dh'
mac-802_11.cc: In method `int Mac802_11::check_pktRTS()':
mac-802_11.cc:713: warning: unused variable `struct hdr_mac802_11 * dh'
mac-802_11.cc: In method `int Mac802_11::check_pktTx()':
mac-802_11.cc:762: warning: unused variable `struct hdr_mac802_11 * dh'

still there:
dsdv/dsdv.cc: In method `void DSDV_Agent::updateRoute(rtable_ent *, rtable_ent 
*)':
dsdv/dsdv.cc:584: warning: converting of negative value `-1' to `unsigned int'
dsdv/dsdv.cc:585: warning: converting of negative value `-1' to `unsigned int'

new:
tora/tora.cc: In method `void toraAgent::recvTORA(Packet *)':
tora/tora.cc:310: warning: unused variable `struct hdr_ip * ih'

still there:
dsr/dsragent.cc: In method `void DSRAgent::recv(Packet *, Handler * = 0)':
dsr/dsragent.cc:541: warning: comparison between signed and unsigned
dsr/dsragent.cc: In method `void DSRAgent::handlePktWithoutSR(SRPacket &, 
bool)':
dsr/dsragent.cc:617: warning: unused variable `struct hdr_sr * srh'


==============================================================================
ns 2.1b6 of 99-09-04:
==============================================================================

some of the warnings and the error mentioned above, plus:
(this is finally the interesting part of my mail)


./validate:

*** ./test-all-wireless-gridkeeper
Tests: dsdv
../../ns test-suite-wireless-gridkeeper.tcl dsdv QUIET
Loading connection pattern...
Loading scenario file...
Load complete...
Starting Simulation...
Segmentation Fault
Test output differs from reference output
Diagnose with: diff test-output-wireless-gridkeeper/dsdv.test 
test-output-wireless-gridkeeper/dsdv
Differences due to floating-point formatting are not significant.
Some test failed.

...

*** ./test-all-wireless-lan-newnode
Tests: dsdv
../../ns test-suite-wireless-lan-newnode.tcl dsdv QUIET
Loading connection pattern...
Loading scenario file...
Load complete...
Starting Simulation...
NS EXITING...
finishing..
Test output agrees with reference output
All test output agrees with reference output.

validate overall report: some tests failed:
     ./test-all-wireless-gridkeeper
to re-run a specific test, cd tcl/test; ../../ns test-all-TEST-NAME


(...which is actually not really correct, I think; it should be e.g.
	cd tcl/test; ../../ns  test-suite-wireless-gridkeeper.tcl dsdv
 as test-all-* are sh-scripts, not ns-scripts)


using xxgdb:
file ../../ns
run ../../ns test-suite-wireless-gridkeeper.tcl dsdv

Loading connection pattern...
Loading scenario file...
Load complete...
Starting Simulation...

Program received signal SIGSEGV, Segmentation fault.
0xff1454b8 in _malloc_unlocked ()

(xxgdb) info stack
#0  0xff1454b8 in _malloc_unlocked ()
#1  0xff1452b4 in malloc ()
#2  0x1895e0 in TclInitByteCodeObj () at gen/ptypes.cc:110
#3  0x1892ec in SetByteCodeFromAny () at gen/ptypes.cc:110
#4  0x1b5cb0 in TclProcCompileProc () at gen/ptypes.cc:110
#5  0x1b5764 in TclObjInterpProc () at gen/ptypes.cc:110
#6  0x1b5610 in TclProcInterpProc () at gen/ptypes.cc:110
#7  0x1750d4 in OTclDispatch (cd=0x5a0238, in=0x3a6db0, argc=0, argv=0xffbebed0) 
at otcl.c:421
#8  0x179d68 in TclInvokeStringCommand () at gen/ptypes.cc:110
#9  0x1951b8 in TclExecuteByteCode () at gen/ptypes.cc:110
#10 0x17a770 in Tcl_EvalObj () at gen/ptypes.cc:110
#11 0x1b59e8 in TclObjInterpProc () at gen/ptypes.cc:110
#12 0x1b5610 in TclProcInterpProc () at gen/ptypes.cc:110
#13 0x1750d4 in OTclDispatch (cd=0x5a0238, in=0x3a6db0, argc=0, argv=0xffbecb00) 
at otcl.c:421
#14 0x179d68 in TclInvokeStringCommand () at gen/ptypes.cc:110
#15 0x1951b8 in TclExecuteByteCode () at gen/ptypes.cc:110
#16 0x17a770 in Tcl_EvalObj () at gen/ptypes.cc:110
#17 0x1b59e8 in TclObjInterpProc () at gen/ptypes.cc:110
#18 0x1b5610 in TclProcInterpProc () at gen/ptypes.cc:110
#19 0x1750d4 in OTclDispatch (cd=0x5a0238, in=0x3a6db0, argc=0, argv=0xffbed730) 
at otcl.c:421
#20 0x179d68 in TclInvokeStringCommand () at gen/ptypes.cc:110
#21 0x1951b8 in TclExecuteByteCode () at gen/ptypes.cc:110
#22 0x17a770 in Tcl_EvalObj () at gen/ptypes.cc:110
#23 0x1b59e8 in TclObjInterpProc () at gen/ptypes.cc:110
#24 0x1b5610 in TclProcInterpProc () at gen/ptypes.cc:110
#25 0x1750d4 in OTclDispatch (cd=0x5a2000, in=0x3a6db0, argc=0, argv=0xffbee360) 
at otcl.c:421
#26 0x179d68 in TclInvokeStringCommand () at gen/ptypes.cc:110
#27 0x1951b8 in TclExecuteByteCode () at gen/ptypes.cc:110
#28 0x17a770 in Tcl_EvalObj () at gen/ptypes.cc:110
#29 0x1b59e8 in TclObjInterpProc () at gen/ptypes.cc:110
#30 0x1951b8 in TclExecuteByteCode () at gen/ptypes.cc:110
#31 0x17a770 in Tcl_EvalObj () at gen/ptypes.cc:110
#32 0x1a9b2c in Tcl_EvalFile () at gen/ptypes.cc:110
#33 0x1abc20 in Tcl_Main () at gen/ptypes.cc:110
#34 0xa256c in main (argc=3, argv=0xffbef8dc) at tclAppInit.cc:60

(xxgdb) up

(xxgdb) up
#2  0x1895e0 in TclInitByteCodeObj () at gen/ptypes.cc:110

This is the line:
--> EmbeddedTcl et_ns_ptypes(code);
(last line of gen/ptypes.cc)

...which was written there by 'ptypes2tcl.cc'

---------------------------------------

So there is exactly this one test failing, and it seems that in the
version before it was exactly this dsdv test that failed (it simply
did not stop...just not sure whether this was on Solaris or Linux
or both).

Hope the debugging output helps.

If you think this is a problem due to our installation, just tell me :-)
If you like me to perform some additional test(s), please tell me, too.

Yours,
	Stefan

-------------------------------------------------------------------
Stefan Dresler             Phone: +49/721/608-6397
Institute of Telematics    Fax:   +49/721/388097
University of Karlsruhe
Zirkel 2
D-76128 Karlsruhe
Email: [email protected]
Home: http://www.telematik.informatik.uni-karlsruhe.de/~dresler/
-------------------------------------------------------------------
Prev by Date: Contact address for Price list
Next by Date: validate problems?
Prev by thread: Re: validate problems?
Next by thread: Contact address for Price list
Index(es):
- Date
- Thread