RE: [PHP] debugging PHP memory corruption
Hi Andy, Have you tried running it with valgrind? (See [1] for tips). Otherwise, you might have more luck at php-internals mailing list, since it is related to PHP development if you intend to fix either PHP or the plugin. Matijn [1] https://bugs.php.net/bugs-getting-valgrind-log.php Thanks Matijn, We have tried running Valgrind against it, but there is nothing obvious (to us at least) in the output. I'll try the Internals mailing list. Andy The information contained in this email is intended for the personal and confidential use of the addressee only. It may also be privileged information. If you are not the intended recipient then you are hereby notified that you have received this document in error and that any review, distribution or copying of this document is strictly prohibited. If you have received this communication in error, please notify Brendata immediately on: +44 (0)1268 466100, or email 'techni...@brendata.co.uk' Brendata (UK) Ltd Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK Registered Office as above. Registered in England No. 2764339 See our current vacancies at www.brendata.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] debugging PHP memory corruption
We've got a problem with PHP 5.3.8 and a third party (open source) library (WSo2 SOAP). At some point during the request to the PHP script, some structures seem to be getting corrupted causing PHP to crash. Depending on the code in the PHP script, it's either crashing during in a print_r/var_export or crashing when the PHP shuts down (the exact location of the crash moves around when we alter the code). We can reprod this on Win32 and Linux now. But how can we go about debugging where the corruption occurred? The address of the corrupted data is not known until the segfault/access violation occurs so we can't set a watch on it (as far as we can tell). Here's what we see in the debugger on Win32: Unhandled exception at 0x1008eb45 (php5ts.dll) in php-cgi.exe: Access violation reading location 0x4cac5400 php5ts.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr=0x4cab5400) + 0x5 bytes php5ts.dll!zend_hash_destroy(_hashtable * ht=0x034cc0f0) + 0x27 bytes php5ts.dll!zend_objects_free_object_storage(_zend_object * object=0x03489fa0, void * * * tsrm_ls=0x003f42b0) + 0x2b bytes php5ts.dll!zend_objects_store_free_object_storage(_zend_objects_store * objects=0x003f685c, void * * * tsrm_ls=0x003f42b0) + 0x9c bytes php5ts.dll!shutdown_executor(void * * * tsrm_ls=0x003f42b0) + 0x2fe bytes php5ts.dll!zend_deactivate(void * * * tsrm_ls=0x003f42b0) + 0x91 bytes php5ts.dll!php_request_shutdown(void * dummy=0x) + 0x31f bytes php-cgi.exe!main(int argc=1, char * * argv=0x003f31d0) + 0xe89 bytes php-cgi.exe!__tmainCRTStartup() + 0x10f bytes Any tips welcomed. Andy. The information contained in this email is intended for the personal and confidential use of the addressee only. It may also be privileged information. If you are not the intended recipient then you are hereby notified that you have received this document in error and that any review, distribution or copying of this document is strictly prohibited. If you have received this communication in error, please notify Brendata immediately on: +44 (0)1268 466100, or email 'techni...@brendata.co.uk' Brendata (UK) Ltd Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK Registered Office as above. Registered in England No. 2764339 See our current vacancies at www.brendata.co.uk
Re: [PHP] debugging PHP memory corruption
On Wed, Jan 4, 2012 at 3:34 PM, Andrew Morum amo...@brendata.co.uk wrote: We've got a problem with PHP 5.3.8 and a third party (open source) library (WSo2 SOAP). At some point during the request to the PHP script, some structures seem to be getting corrupted causing PHP to crash. Depending on the code in the PHP script, it's either crashing during in a print_r/var_export or crashing when the PHP shuts down (the exact location of the crash moves around when we alter the code). We can reprod this on Win32 and Linux now. But how can we go about debugging where the corruption occurred? The address of the corrupted data is not known until the segfault/access violation occurs so we can't set a watch on it (as far as we can tell). Here's what we see in the debugger on Win32: Any tips welcomed. Andy. Hi Andy, Have you tried running it with valgrind? (See [1] for tips). Otherwise, you might have more luck at php-internals mailing list, since it is related to PHP development if you intend to fix either PHP or the plugin. Matijn [1] https://bugs.php.net/bugs-getting-valgrind-log.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
