Thanks for the suggestion. I am having a problem with implementing this. First off, I get quite a few errors unless I do an #ifdef to make sure that STDLIB_H gets included first. (It complains when stdlib tries to declare abort after). Wrapping an #ifdef STDLIB_H around the macro definitions seems to fix this. I define uan_abrt in a file that is being compiled, uan-tools.cc, but I am failing in the link stage with an undefined reference.
tools/rng.o: In function `RNG::set_seed(unsigned long const*)': rng.cc:(.text+0x13b2): undefined reference to `uan_abrt' tools/rng.o: In function `RNG::set_package_seed(unsigned long const*)': rng.cc:(.text+0x1440): undefined reference to `uan_abrt' tools/rng.o: In function `RNG::set_seed(RNG::RNGSources, int)': rng.cc:(.text+0x14bf): undefined reference to `uan_abrt' rng.cc:(.text+0x14e1): undefined reference to `uan_abrt' tools/rng.o: In function `RNGTest::RNGTest()': rng.cc:(.text+0x1b71): undefined reference to `uan_abrt' tools/rng.o:rng.cc:(.text+0x1be4): more undefined references to `uan_abrt' follow collect2: ld returned 1 exit status Note that the spelling, uan_abrt is correct. Have I done something obvious to other people? Leonard On Nov 16, 2007 7:52 PM, Leonard Tracy <[EMAIL PROTECTED]> wrote: > Hi all, > > Two questions: > > 1. > I've been trying to debug some seg faults I've been having. They > appear to be related to tracing dropped packets. GDB's trace pack > ends in DoWrite called by TclWrite. Has anybody else had experience > with this? I am running NS 2.31 on Linux (Gutsy Ubuntu). I am using > the old format of wireless traces. > > This problem seems to be related to the load placed on the network. I believe > this has to do with a lot of Packets being dropped from the IFQ. > The problem seems to be gone, or at least much less likely to occur, > now that I've altered Queue::reset to use Packet::free as opposed to drop. > > 2. > As a possibly related issue. It seems that NS often quits early. I > am not sure if this > is a problem with my code or something other people have noticed. > I've been running long > simulations (10000 seconds), and 90% (or more) of the time (after > making the above change) NS will > complete normally. The other simulations will end at a random much > earlier time, but NS still > completes without an error code. Does anybody have an idea of what > would cause this? > > Leonard >
