More on the corrupted defines

I've coaxed some more debugging info out of PHP with the attached patch. A brief synopsis, for those of you just tuning in, is that I'm finding some of my defined constants are getting corrupted, returning garbage when they're used in a script. I've spent a better part of the last week trying to dig into this problem. What I've come up with is rather interesting. The source of the problem seems to be that after the first request handled by an Apache child process, PHP doesn't properly clean up, and much of the memory space is polluted. I don't know enough about the Zend internals to be able to figure out exactly happens, but I've deduced that after the first request handled by a process, some defines (entries in the zend_constants hash table) already have some data associated with them. When zend_register_constant() is called, it finds data for a given key and doesn't reassign it. Typically, when a process starts having problems with defines, it segfaults after processing the script. I've attached my patch; it doesn't do anything more than spit out debugging information to stderr which is caught by Apache's error_log. I have yet to put together a well-packaged tarball of files that will reliably reproduce the problem; I'm going to go work on that next, now that I've got some idea what's happening. For now, I've attached my patch and a copy of my Apache error log that pretty clearly shows what's happening. The error log includes the startup of httpd, and you can see that, for example process id 11074, processes an entire request with no problem, but on the next request with that process, it starts to spew errors. I'm using PHP 4.0.6 compiled with: ./configure --prefix=/usr --with-config-file-path=/etc --with-exec-dir=/usr/bin --enable-force-cgi-redirect --disable-magic-quotes --enable-track-vars --enable-wddx --with-mysql --with-oci8=/home/oracle/product/8.0.5 --with-esoob=/usr/local/easysoft/oob/client --enable-sockets --with-xml --enable-debug --with-apxs=/usr/sbin/apxs and Apache 1.3.14. Will someone take a look at this? I'll try to bundle up a set of scripts that reproduces the error. Thanks, B -- Brian Lalor blalor@insight.com (v) 480-333-3196 (f) 480-760-9298