Ok, the crash is not occuring because of the ___parse bug (it's fixed, of course). Maybe the original one wasn't either?
It actually serves up the response, but then does some odd things: write(6, "07-11 13:10:47\n<root><header><protocol>1</protocol>\n<oem>YAHALOM...") close(6) = 0 This is what I have doubts about: fcntl64(2, F_GETFL) = 0x401 (flags O_WRONLY|O_APPEND) fcntl64(2, F_SETFL, O_WRONLY|O_APPEND) = 0 fcntl64(2, F_GETFL) = 0x401 (flags O_WRONLY|O_APPEND) fcntl64(0, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(0, F_SETFL, O_RDWR) = 0 fcntl64(0, F_GETFL) = 0x2 (flags O_RDWR) --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ It looks like something you have is trying to fool around with stdin and stderr, which is probably not a good thing for it to be doing. I don't think this is likely mod_dtcl's fault, or Apache's, but let's see if we can figure out what the problem is. Maybe someone is writing Tcl packages that make bad assumptions about what environments they will run in. You might try eliminating pieces of library code one at a time to see if anything makes it go away. You can also dig around and look for occurences of 'stderr' in the code. -- David N. Welton Consulting: http://www.dedasys.com/ Free Software: http://people.debian.org/~davidw/ Apache Tcl: http://tcl.apache.org/ Personal: http://www.efn.org/~davidw/
