Thanks Jerry. This was helpful in localizing where the segmentation
violation is coming from.
Apparently, from trying to do a ns_malloc(10 bytes).
Why would a malloc(10 bytes) cause a segmentation violation? Has nsd8x
process ran out of heap space? But, I thought memory allocations are
dynamic, upto the machine virtual memory?
The stack trace is the following:
Program received signal SIGSEGV, Segmentation fault.
chunk_alloc (ar_ptr=0x4017df00, nb=17) at malloc.c:2832
(gdb) bt
#0 chunk_alloc (ar_ptr=0x4017df00, nb=17) at malloc.c:2832
#1 0x400d413a in __libc_malloc (bytes=10) at malloc.c:2714
#2 0x0811ebe9 in ns_malloc (size=10) at memory.c:126
#3 0x08109e74 in TclpAlloc (nbytes=10) at ./../generic/nsthreads.c:739
#4 0x0809d5af in Tcl_Alloc (size=10) at ./../generic/tclCkalloc.c:846
#5 0x080f25fa in Tcl_GetObjResult (interp=0x8353dc8)
at ./../generic/tclResult.c:413
#6 0x080bf28d in TclExecuteByteCode (interp=0x8353dc8, codePtr=0x84a5d20)
at ./../generic/tclExecute.c:861
#7 0x0809969a in Tcl_EvalObjEx (interp=0x8353dc8, objPtr=0x8460598,
flags=0)
at ./../generic/tclBasic.c:2733
#8 0x080f0997 in TclObjInterpProc (clientData=0x84e2788, interp=0x8353dc8,
objc=1, objv=0x8354098) at ./../generic/tclProc.c:1001
#9 0x080bf1d6 in TclExecuteByteCode (interp=0x8353dc8, codePtr=0x8477d10)
at ./../generic/tclExecute.c:845
#10 0x0809969a in Tcl_EvalObjEx (interp=0x8353dc8, objPtr=0x8444508,
flags=0)
at ./../generic/tclBasic.c:2733
#11 0x0805c5ca in NsAdpRunPrivate (interp=0x8353dc8,
file=0x408c7fd8 "/opt/aolserver/servers/server1/pages/i.adp",
pagePtr=0x84cd618) at tclstubs.cpp:435
#12 0x0805ee3d in NsTclIncludeCmd (parse=0x0, interp=0x8353dc8, argc=2,
argv=0x408c847c) at adp.c:805
#13 0x0805fc43 in Ns_AdpRequest (conn=0x83476d0,
file=0x408c8590 "/opt/aolserver/servers/server1/pages/i.adp")
at adp.c:1479
#14 0x0805fa10 in AdpProc (parserPtr=0x0, conn=0x83476d0) at adp.c:1407
#15 0x08078015 in Ns_ConnRunRequest (conn=0x83476d0) at op.c:196
#16 0x0807e94a in ConnRun (connPtr=0x83476d0) at serv.c:882
#17 0x0807e01a in NsConnThread (arg=0x833b618) at serv.c:671
#18 0x0811e1b2 in NsThreadMain (arg=0x8353570) at thread.c:228
#19 0x40022bfd in pthread_start_thread (arg=0x408c8c00) at manager.c:262
#20 0x40022cdf in pthread_start_thread_event (arg=0x408c8c00) at
manager.c:285
(gdb)
-----Original Message-----
From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf
Of Jerry Asher
Sent: Sunday, October 21, 2001 12:36 PM
To: [EMAIL PROTECTED]
Subject: Re: [AOLSERVER] Trying to debug a C module?
Part of the problem I have had in debugging modules is getting that the
symbols of the module are loaded at runtime, not at link time.
So....
my gdbinit contains:
set args -d -s theashergroup -ft /web/aol33/theashergroup.tcl -u
theashergroup -g web
handler 13 nostop pass
file /web/aol33/bin/nsd8x
Then I start aolserver under gdb
gdb
Set a break at nsd/modload.c/NsLoadModules()
break NsLoadModules
Then run....
and when you hit NsLoadModules, step through it. Your module will
eventually be loaded and its initproc run with a call to Ns_ModuleLoad.
Have fun,
Jerry
========================================================
Jerry Asher [EMAIL PROTECTED]
1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980
Berkeley, CA 94709 Fax: (877) 311-8688
