ndt-users list created

[Clayton Keller <>]

Peter Van Epp wrote:
>         Looks to already be on (in src/Makefile):
>
> CC = gcc
> CCDEPMODE = depmode=gcc3
> CFLAGS = -g -O2
> CPP = gcc -E
> CPPFLAGS =
>
> the CFLAGS = -g turns on debugging so if you have a core from one of the 
> segfaults (I'm not a Linux expert, I usually use FreeBSD but our HCP guys
> are trying to corrupt me, and they use SUSE rather than RedHat these days :-)) 
> which will usually be in the directory where the binary is and called either 
> "core" or possibly "ndt.core" then gdb should work. Some of the shells can
> be set to suppress cores so you may have to find and disable that then run
> it again if you aren't getting a core from the seg fault.
>
> Peter Van Epp / Operations and Technical Support 
> Simon Fraser University, Burnaby, B.C. Canada
>
> On Wed, Aug 31, 2005 at 10:27:45AM -0500, Clayton Keller wrote:
>
> > Peter Van Epp wrote:
> >
> > > <snip>> 
> > >
> > >
> > > > When running without "-m", i receive the following output:
> > > >
> > > > Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
> > > > running 10s outbound test (client to server) . . . . . Server failed: 
> > > > 'Go' flag not received
> > > >
> > > > When the test is run and this error is returned I see a flood of Signal 
> > > > 11 received from process XXXX.
> > >
> > >
> > >         Signal 11 is a seg fault (i.e. usually a programming error) where
> > > the process is trying to access unallocated memory. If the -g compile flag 
> > > is on and you got a core from the process then the output of 
> > >
> > > gdb program core
> > >
> > >
> > > > where
> > >
> > >
> > > (where program is the ndt client and core is the name of the core file)
> > >
> > > would be interesting in that it would tell us where the seg fault is 
> > > occurring.
> > >
> > > Peter Van Epp / Operations and Technical Support 
> > > Simon Fraser University, Burnaby, B.C. Canada
> >
> > How do I enable this compile option? I apologize, but I have not had to 
> > do this in the past.
> >
> > Once I get the core I can run the gdb against the websrv100 process and 
> > can get this information back to the list for analysis.
It's not actually seg faulting or terminating the application 
unexpectedly. I just continue to see the Signal 11's to the CLI when 
running with "-d". And this continues until I kill the web100srv process 
manually.

I can try and run gdb againt the active PID.

i.e. gdb /usr/local/sbin/web100srv PID  ( correct me if that is 
incorrect -- a bit fresh with using gdb ).