segmentation fault in t_splay() calling Tcl_Alloc()
Anthony Davis
an error in gcc, but I wanted to see if anyone else may have seen this
and could offer their advice:
On my system (SCO UNIX 5.0.6 ) Tcl_Alloc maps to malloc and I am
getting a segmentation fault in the libc function t_splay() after
calling Tcl_Alloc() in my application.
GDB output to follow:
(gdb) run
Starting program: /var/opt/K/SCO/Unix/5.0.6Ga/usr/local/src/pcl0.0.1/bin/pclsh
% source test.pcl
Opening file: om1reg.soa
records read: 0
records read: 1
Program received signal SIGSEGV, Segmentation fault.
0x80023aac in t_splay () from /usr/lib/libc.so.1
(gdb) where
#0 0x80023aac in t_splay () from /usr/lib/libc.so.1
#1 0x8002397f in t_delete () from /usr/lib/libc.so.1
#2 0x800231d7 in _real_malloc () from /usr/lib/libc.so.1
#3 0x80023019 in malloc () from /usr/lib/libc.so.1
#4 0x80b952d in TclpAlloc ()
#5 0x8059ac8 in Tcl_Alloc ()
#6 0x809f448 in Tcl_NewStringObj ()
#7 0x80504f6 in Pcl_ReadObjCmd (clientData=0x81200a8,
interp=0x8109114,objc=2, objv=0x810b694) at generic/Pcl_Main.c:340
#8 0x8055efa in TclEvalObjvInternal ()
#9 0x807489a in TclExecuteByteCode ()
#10 0x8073dc0 in TclCompEvalObj ()
#11 0x8056c5e in Tcl_EvalObjEx ()
#12 0x805a6e5 in Tcl_CatchObjCmd ()
#13 0x8055efa in TclEvalObjvInternal ()
#14 0x807489a in TclExecuteByteCode ()
#15 0x8073dc0 in TclCompEvalObj ()
#16 0x8056c5e in Tcl_EvalObjEx ()
#17 0x805c18e in Tcl_ForObjCmd ()
#18 0x8055efa in TclEvalObjvInternal ()
#19 0x805677a in Tcl_EvalEx ()
#20 0x8089d08 in Tcl_FSEvalFile ()
#21 0x806197a in Tcl_SourceObjCmd ()
#22 0x8055efa in TclEvalObjvInternal ()
#23 0x807489a in TclExecuteByteCode ()
#24 0x8073dc0 in TclCompEvalObj ()
#25 0x8056c5e in Tcl_EvalObjEx ()
#26 0x80baa6e in Tcl_RecordAndEvalObj ()
#27 0x808f60b in Tcl_Main ()
#28 0x804b113 in main (argc=1, argv=0x8047cf0) at
generic/pclAppInit.c:99
#29 0x804b00b in _start ()
Any help is greatly appreciated.
Anthony
Ralf Fassel
| Let me first start this message by stating that I believe this to be
| an error in gcc,
Hmm... given the evidence you produced so far, most honorable
opponent, I dare to draw your attention towards other possible
culprits...
| ... and I am getting a segmentation fault in the libc function
| t_splay() after calling Tcl_Alloc() in my application.
Usually segfaults like these result from memory corruption,
i.e. you're thrashing malloc's stack somewhere else, and only at the
next malloc the effect becomes visible.
Does your program call malloc()/free() itself besides Tcl_Alloc()?
Have you checked the pointers there?
R'
Benjamin Riefenstahl
ada...@addpower.com (Anthony Davis) writes:
> Program received signal SIGSEGV, Segmentation fault.
> 0x80023aac in t_splay () from /usr/lib/libc.so.1
> (gdb) where
> #0 0x80023aac in t_splay () from /usr/lib/libc.so.1
> #1 0x8002397f in t_delete () from /usr/lib/libc.so.1
> #2 0x800231d7 in _real_malloc () from /usr/lib/libc.so.1
> #3 0x80023019 in malloc () from /usr/lib/libc.so.1
You are most likly corrupting your heap, i.e. writing over memory that
doesn't belong to you.
Make sure every allocation goes through ckalloc()/ckfree(), and
recompile Tcl and your own code with TCL_MEM_DEBUG. Than reproduce
your situation. You should get error output on stderr.
benny
Anthony Davis
> Have you checked the pointers there?
No I do not have any explicit calls to malloc()/free() anywhere in the
application, I use only Tcl_Alloc and Tcl_Free().
The call to Tcl_Alloc is actually being made from within
Tcl_NewStringObj if this makes a difference at all.
Here is the code snippet where the error occurs:
/* the function PVK_read() is a third party function for reading a
* proprietary data file, it returns a char*. szResult is previously
* allocated with Tcl_Alloc the length defined in the file's
dictionary +1
*/
if(PVX_ERROR==(int)(cbBytesRead=PVK_read(pclFilePtr->fh,szResult,
pclFilePtr->pvkinf->rsz,nPvxRdId))){
PclSetObjResultPvxError(interp,"pclread");
return TCL_ERROR;
}
szResult[cbBytesRead+1]='\0';
/* segmentation fault is on this line in Tcl_NewStringObj */
Tcl_SetObjResult(interp,Tcl_NewStringObj(szResult,strlen(szResult)));
Tcl_Free(szResult);
return TCL_OK;
Hope this helps, I would be glad to find out it is something I am
doing wrong if there is anything you can see let me know.
Anthony
Jeff Hobbs
> Here is the code snippet where the error occurs:
>
> /* the function PVK_read() is a third party function for reading a
> * proprietary data file, it returns a char*. szResult is previously
> * allocated with Tcl_Alloc the length defined in the file's
> dictionary +1
> */
> if(PVX_ERROR==(int)(cbBytesRead=PVK_read(pclFilePtr->fh,szResult,
> szResult[cbBytesRead+1]='\0';
> /* segmentation fault is on this line in Tcl_NewStringObj */
> Tcl_SetObjResult(interp,Tcl_NewStringObj(szResult,strlen(szResult)));
So are you sure that cbBytesRead is going to be correct? Normally if
that returns a string length, then you wouldn't add the +1 to set \0,
because the string is 0-indexed. I'm just wondering if this is an
off-by-one error. Something like purify would indicate this quickly.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Ralf Fassel
| /* the function PVK_read() is a third party function for reading a
| * proprietary data file, it returns a char*.
If PVK_read() really returns a char*, then it does not make sense to
use that value as _index_ into szResult later.
--<snip-snip>--
| szResult[cbBytesRead+1]='\0';
Here^^^.
Other than that, I'd check each and every return value in that code
section in the debugger, maybe add some more intermediate tmp
variables to get at strlen() etc return values.
R'
Anthony Davis
The documentation for PVK_read() says that it will not append a '\0'
to the end of the char* that it returns... when in fact it does.
So when I removed the following line:
> | szResult[cbBytesRead+1]='\0';
I no longer get the error.
Now can anyone tell me why (sorry if this is a stupid question)?
Thanks,
Anthony
Ralf Fassel
| The documentation for PVK_read() says that it will not append a '\0'
| to the end of the char* that it returns... when in fact it does.
First of all: what does this function really _return_? An int (or
size_t) to indicate how many bytes were written, or a char* as you
keep saying? Include the prototype for PVK_read() from the header
file.
If it returns a char*, you cannot take `cbBytesRead' as index, because
this would write at some random memory location, not at the end of the
returned string.
| So when I removed the following line:
| > | szResult[cbBytesRead+1]='\0';
| I no longer get the error.
If you run that code it depends on the value of `cbBytesRead' and the
allocated size of `szResult'. Show the values for both. I.e. not
what you *think* they should be, but a printf() of what they *are*.
BTW, do you get any compiler warnings?
R'