At 03:26 PM 10/12/2002, you wrote:

I am using Redhat 7.2, latest revisions via Up2date.  Aolserver 3.4.2

No core file in evidence, but the gdb instructions you gave were
perfect..  and I definately appreciate the assist here.


here is the result:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6151 (LWP 23047)]
0x401d6ca0 in __res_nquery (statp=0x40503ddc, name=0x404f2ecc
"42.192.99.68.in-addr.arpa",
    class=1, type=12, answer=0x404f32dc "", anslen=65536) at res_query.c:110
110     res_query.c: No such file or directory.
        in res_query.c


stack backtrace:

#0  0x401d6ca0 in __res_nquery (statp=0x40503ddc, name=0x404f2ecc
"42.192.99.68.in-addr.arpa", class=1, type=12, answer=0x404f32dc "",
anslen=65536) at res_query.c:110
#1  0x401cd1f8 in _nss_dns_gethostbyaddr_r (addr=0x405033b0, len=4, af=2,
result=0x4019dca4,buffer=0x84bddd8 "\177", buflen=1024, errnop=0x40503c68,
h_errnop=0x40503374) at nss_dns/dns-host.c:292
#2  0x40162919 in __gethostbyaddr_r (addr=0x405033b0, len=4, type=2,
resbuf=0x4019dca4, buffer=0x84bddd8 "\177", buflen=1024, result=0x40503370,
h_errnop=0x40503374) at ../nss/getXXbyYY_r.c:200
#3  0x401626fb in gethostbyaddr (addr=0x405033b0, len=4, type=2) at
../nss/getXXbyYY.c:131
#4  0x0806dffb in GetHost (dsPtr=0x4050345c, addr=0x821057c "68.99.192.42")
at dns.c:231
#5  0x0806de24 in DnsGet (getProc=0x806dfa0 <GetHost>, dsPtr=0x4050345c,
cachePtr=0x813cdec, key=0x821057c "68.99.192.42") at dns.c:153
#6  0x0806dc5f in Ns_GetHostByAddr (dsPtr=0x4050345c, addr=0x821057c
"68.99.192.42") at dns.c:100
#7  0x4023acc3 in ValidateUserAddr (userPtr=0x81fdeb8, peer=0x821057c
"68.99.192.42") at nsperm.c:819
#8  0x4023a4c1 in AuthProc (server=0x8156fb8 "ariven", method=0x8439640
"GET", url=0x8439660 "/NS/Admin", user=0x83d07b8 "nsadmin", pass=0x9999999
"XXXXXXX", peer=0x821057c "68.99.192.42") at nsperm.c:435
#9  0x08061bb3 in Ns_AuthorizeRequest (server=0x8156fb8 "ariven",
method=0x8439640 "GET", url=0x8439660 "/NS/Admin", user=0x83d07b8
"nsadmin", passwd=0x9999999 "XXXXXXX", peer=0x821057c "68.99.192.42") at
auth.c:76 #10 0x0807e250 in ConnRun (connPtr=0x8210520) at serv.c:873
#11 0x0807dc10 in NsConnThread (arg=0x822b3d0) at serv.c:671
#12 0x0811833b in NsThreadMain (arg=0x822b3e0) at thread.c:228
#13 0x40032c6f in pthread_start_thread (arg=0x40503be0) at manager.c:284
#14 0x40032d5f in pthread_start_thread_event (arg=0x40503be0) at manager.c:308



If the process segfaults, it should leave a file named "core" in the
directory from which the process was started.  There are, however, a
number of reasons why a core file may have been suppressed; to figure this
out, if you don't have a core file, you'd need to say which OS you're
using.

If you have gdb, you can run the aolserver process as follows:

        - Change directories to the aolserver root dir
        - run "gdb bin/nsd8x"
        - Give gdb the command "set args -ft yourconfigfile.tcl"
                (replace "yourconfigfile.tcl" with the name of
                your actual config file)
        - give gdb the "run" command
        - induce the segfault.  You should get a gdb prompt.
        - Give gdb the command "where" and it will produce a stack
backtrace, which should tell you what the thread was executing when it
segfaulted.

If your stack backtrace shows that the process died somewhere inside
"malloc", then something somewhere corrupted the dynamic memory allocation
heap of your process prior to the segfault.  These are really hard to
track down.

Pete.

Reply via email to