[ns] Seg Faults
pedro.estrela at gmail.com
Mon Nov 19 17:22:45 PST 2007
use ifdefs to NOT redefine abort in those RNG files
as such, you'll see aborts everywhere except RNG fucntions
On 11/19/07, Leonard Tracy <lentracy at u.washington.edu> wrote:
> 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?
> On Nov 16, 2007 7:52 PM, Leonard Tracy <lentracy at u.washington.edu> 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
> > 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
> > 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
More information about the Ns-users