Edit report at http://bugs.php.net/bug.php?id=52613&edit=1
ID: 52613 Updated by: and...@php.net Reported by: manuel at mausz dot at Summary: crash in mysqlnd Status: Assigned Type: Bug Package: MySQL related Operating System: Unix PHP Version: 5.3.3 Assigned To: andrey Block user comment: N New Comment: alrighty, then I will commit it. If something happens feel free to reopen or create a new report with reference to this one. Previous Comments: ------------------------------------------------------------------------ [2010-08-17 19:16:17] manuel at mausz dot at Did that already. No memory corruption for now. If it happens again I'll tell you. ------------------------------------------------------------------------ [2010-08-17 19:04:56] and...@php.net Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! ------------------------------------------------------------------------ [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta ------------------------------------------------------------------------ [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090== at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! ------------------------------------------------------------------------ [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=3900000 crash2.php ==22090== Fatal error: Allowed memory size of 3900000 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090== at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090== by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090== by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090== by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090== by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090== by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090== by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090== by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090== by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090== by 0x8315475: zend_deactivate (zend.c:896) ==22090== by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090== at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090== by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090== by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090== by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090== by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090== by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090== by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090== by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090== by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090== by 0x8315475: zend_deactivate (zend.c:896) ==22090== by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main thread stack size used in this run was 8388608. ==22090== ==22090== HEAP SUMMARY: ==22090== in use at exit: 5,336,261 bytes in 31,521 blocks ==22090== total heap usage: 87,945 allocs, 56,424 frees, 11,136,282 bytes allocated ==22090== ==22090== LEAK SUMMARY: ==22090== definitely lost: 0 bytes in 0 blocks ==22090== indirectly lost: 0 bytes in 0 blocks ==22090== possibly lost: 363,504 bytes in 3,303 blocks ==22090== still reachable: 4,972,757 bytes in 28,218 blocks ==22090== suppressed: 0 bytes in 0 blocks ==22090== Rerun with --leak-check=full to see details of leaked memory ==22090== ==22090== For counts of detected and suppressed errors, rerun with: -v ==22090== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7) Segmentation fault ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52613 -- Edit this bug report at http://bugs.php.net/bug.php?id=52613&edit=1
