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 +Status: Feedback Type: Bug Package: MySQL related Operating System: Unix PHP Version: 5.3.3 Assigned To: andrey Block user comment: N Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2010-08-17 17:53:41] and...@php.net If PHP hits the memory limit then mysqlnd loses all control, because Zend takes it. Can you show more information about the crash? Just the bt, without line numbers doesn't help. valgrind output will be even better. ------------------------------------------------------------------------ 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
