[ns] Seg Faults

[Pedro Vale Estrela]

I've encountered this problem previously. Somewhere in NS2 an exit or abort
function is being called, and no error is displayed.

Solution:
a) in config.h undefined exit() and abort(); 
b) redirect both to a macro called my_abort() which records the file and
line number where it is called; 
c) code the my_abort() function to display the line and filename parameters,
(printf)
d) and then cause a segmentation fault "by hand" (to stop execution in the
c++ debugger DDD)

you can check a live example of this in my IST-CIMS package
http://tagus.inesc-id.pt/~pestrela/ns2/?g=ist-cims.html
(note that said config.h code is currently disabled)

I've also put the interesting code lines below.



Please add any insight you gained into the ns2 wiki
(http://nsnam.isi.edu/nsnam/index.php/Main_Page) so that others can learn
about and from your work.

Pedro Estrela
http://tagus.inesc-id.pt/~pestrela/ns2/










Config.h:
---------
This code would be used to redefine abort as a macro, that would call
my_abort (located in utils_ns.cc)
This would cause any abort() or exit() invocation to call my_abort, which
would generate an exception to
be caught inside the debugger.


extern "C" {
	void my_abort(int line, char *file);
	
}


void my_abort(int line, char *file);		// em utils_ns.h


#undef abort
#define abort()    my_abort(__LINE__, __FILE__ )

#undef exit
#define exit(A)   my_abort(__LINE__, __FILE__ )


somewhere.cc:
-------------
void my_abort(int line, char *file)
{
	printf("___ ABORT ___ on file %s, line %d \n", file, line);
	assert(1==2);
}







> -----Original Message-----
> From: ns-users-bounces at ISI.EDU [mailto:ns-users-bounces at ISI.EDU] On Behalf
> Of Leonard Tracy
> Sent: sábado, 17 de Novembro de 2007 3:53
> To: NS Users
> Subject: [ns] Seg Faults
> 
> 
> 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