As I resumed some maintenance on Rivet's code I found out
the code that was quite nicely working last summer segfaults
when rivet templates parse other embedded templates. The gcc
compiler and the C library have been upgrade since then but no
other applications, either mine or shipped with debian, seem to
have suffered from that.
The way the segfault occurs is simple: in Rivet_Parse a call
to Tcl_FSStat blasts the pointer value in the first
argument. Arguments being passed in have been
checked running Apache under debugger control
and are valid.
This is the relevant code
TCL_CMD_HEADER( Rivet_Parse )
{
char *filename;
Tcl_StatBuf buf;
Tcl_Obj *fnobj;
...
fnobj = Tcl_NewStringObj(filename, -1);
Tcl_IncrRefCount(fnobj);
retval = Tcl_FSStat(fnobj, &buf);
Tcl_DecrRefCount(fnobj);
...
}
and the backtrace after the process returns from the call
(gdb) bt
#0 Rivet_Parse (clientData=0x0, interp=0x9014e50, objc=2,
objv=0x9018a7c) at rivetCore.c:142
#1 0xb6c44926 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
#2 0xb6c6e7cf in ?? () from /usr/lib/libtcl8.4.so.0
#3 0x09014e50 in ?? ()
#4 0x00000002 in ?? ()
#5 0x09018a7c in ?? ()
#6 0x00000000 in ?? ()
(gdb)
being fnobj no more pointing to a valid Tcl object
the process segfaults on the call to Tcl_DecrRefCount.
The code retval is successful and the buf structure contains the
actual file status. Allocating the pointer on the heap (through the
apr pool) fixes the problem, but it looks a way to put the head
in the sand and pretend the problem is not around
What I ask you for are hints that may help me to single out the culprit
of this behavior.
thank you
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
