Bug #12448 Updated: Disturbing memory corruption/crash

ID: 12448 Updated by: lobbin Reported By: nick@macaw.demon.co.uk Old Status: Feedback Status: Closed Bug Type: Reproducible crash Operating System: Linux 2 2.16 PHP Version: 4.0.6 New Comment: No feedback. Closing. Previous Comments: ------------------------------------------------------------------------ [2001-12-05 19:46:43] yohgaki@php.net Could you try 4.1.0RC5? http://www.php.net/~zeev/php-4.1.0RC5.tar.gz ------------------------------------------------------------------------ [2001-07-28 07:46:13] nick@macaw.demon.co.uk I've been attemping to track down a case of memory corruption that showed itself with 'new ClassName' returning null or 'gettype()' on the result returning a garbage string. I'm using php as a module with apache, and with the zend optimiser, although the effect is the same with or without the optimiser enabled. Apart from other bugs in 4.0.6 that I've reported, up until now things have been fine with some largish runs of up to a few 1000 lines of code. Whilst this is reproduceable 100% with my application, unfortunately I can't contribute a smaller program yet to demonstrate this despite various attempts, but I'll try some more on this as there's not a lot to go on otherwise. Perhaps someone can do a purify run with a solaris build? The effect of getting a null result from new or garbage from gettype() first showed when new'ing a trivial class before one that amongst other things used shared memory and semaphores via the put_var/get_var routine family. Something that has aparantly been working well and flawlessly so far. It was the result of newing the complex class that was corrupted. Curiously, moving the trivial (empty) class construction after the more complex one 'cured' the problem. The complex constructor was calling a function returning array data by reference that came from calling a function that returned array data by value. This had been obtained via shm_get_var. Another change that made the problem disappear was to return the data either by value or by reference in *both* cases, although performance analysis showed this to be slower in both cases. The presumed crash (the browser lost its connection to the server) occured when I called the function twice that ultimately returned the data from shared memory. Again this didn't happen when returning consistently by value or reference. Of course the workarounds don't mean that the problem wasn't still happening, but perhaps that what is probably corruption didn't have an impact at that point. So the problem may be related to the use of the sem and shm routines, returning 300 element associative arrays of integer to strings by a mixture or reference/value or something else. It may also be in the code outside of php of course. Sorry that I can't give more to go on but there is most definitely a problem lurking somewhere. Please feel free to email me with any things that I might try to get a further handle on the problem with my own application in the (currently likely) event that I can't reproduce with a simpler application. For library versions, ldd on httpd gives the following: libpam.so.0 => /lib/libpam.so.0 (0x40019000) libdl.so.2 => /lib/libdl.so.2 (0x40021000) libz.so.1 => /usr/lib/libz.so.1 (0x40025000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40034000) libresolv.so.2 => /lib/libresolv.so.2 (0x40061000) libm.so.6 => /lib/libm.so.6 (0x40070000) libnsl.so.1 => /lib/libnsl.so.1 (0x4008e000) libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x400a5000) libc.so.6 => /lib/libc.so.6 (0x400ac000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Cheers, Nick ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=12448&edit=1