[ns] Seg Faults

[Pedro Estrela]

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?
>
> Leonard
>
> 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
> 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
> >
>
>