ID: 38819 Updated by: [EMAIL PROTECTED] Reported By: madcoder at gmail dot com -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: 2.6.15-gentoo linux amd64 PHP Version: 5.1.6 New Comment:
What was your configure line and did you enable any of mysql related extensions? If yes, then what is the version of MySQL? Previous Comments: ------------------------------------------------------------------------ [2006-09-19 19:54:19] madcoder at gmail dot com Apparently it looks like pastebin is having problems... I've copied the same output here, for redundancy: http://www.framewerk.org/~madcoder/vgrind.log ------------------------------------------------------------------------ [2006-09-19 19:49:48] madcoder at gmail dot com I ran it through valgrind with --leak-check=full -v --show-reachable=yes, and copied the output here: http://pastebin.com/790150 ------------------------------------------------------------------------ [2006-09-19 19:39:47] madcoder at gmail dot com Now that's interesting... It runs fine with valgrind. Here are the ERROR SUMMARY and LEAK SUMMARY sections: ==7964== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 93 from 1) ==7964== malloc/free: in use at exit: 71,780 bytes in 1,268 blocks. ==7964== malloc/free: 38,082 allocs, 36,814 frees, 3,611,397 bytes allocated. ==7964== For counts of detected errors, rerun with: -v ==7964== searching for pointers to 1,268 not-freed blocks. ==7964== checked 2,962,048 bytes. ==7964== LEAK SUMMARY: ==7964== definitely lost: 32,841 bytes in 4 blocks. ==7964== possibly lost: 0 bytes in 0 blocks. ==7964== still reachable: 38,939 bytes in 1,264 blocks. ==7964== suppressed: 0 bytes in 0 blocks. ==7964== Use --leak-check=full to see details of leaked memory. Running with --leak-check=full, I get the following: ==7968== 73 (32 direct, 41 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 8 ==7968== at 0x4A1AB8E: malloc (vg_replace_malloc.c:149) ==7968== by 0x64825AB: tds_alloc_context (in /usr/lib64/libsybdb.so.4.0) ==7968== by 0x6472C3F: dbinit (in /usr/lib64/libsybdb.so.4.0) ==7968== by 0x1595DC: zm_startup_mssql (php_mssql.c:301) ==7968== by 0x31B325: zend_startup_module_ex (zend_API.c:1397) ==7968== by 0x3224A3: zend_hash_apply (zend_hash.c:666) ==7968== by 0x31B4EE: zend_startup_modules (zend_API.c:1444) ==7968== by 0x2BB230: php_module_startup (main.c:1557) ==7968== by 0x3E460A: main (php_cli.c:681) ==7968== ==7968== 32,768 bytes in 1 blocks are definitely lost in loss record 8 of 8 ==7968== at 0x4A1C10D: calloc (vg_replace_malloc.c:279) ==7968== by 0x6472C16: dbinit (in /usr/lib64/libsybdb.so.4.0) ==7968== by 0x1595DC: zm_startup_mssql (php_mssql.c:301) ==7968== by 0x31B325: zend_startup_module_ex (zend_API.c:1397) ==7968== by 0x3224A3: zend_hash_apply (zend_hash.c:666) ==7968== by 0x31B4EE: zend_startup_modules (zend_API.c:1444) ==7968== by 0x2BB230: php_module_startup (main.c:1557) ==7968== by 0x3E460A: main (php_cli.c:681) ------------------------------------------------------------------------ [2006-09-19 06:24:54] [EMAIL PROTECTED] Doesn't look like PHP problem to me. Could you plz also see if `valgrind /usr/bin/php test.php` show you something interesting? Please put valgrind's log somewhere and paste the URL here. ------------------------------------------------------------------------ [2006-09-18 23:38:16] madcoder at gmail dot com Sorry for the delay (I had to fix an error with gdb not generating backtraces on AMD64...) Here's the backtrace: ----- (gdb) run Starting program: /usr/bin/php -e test.php [Thread debugging using libthread_db enabled] [New Thread 47773184727840 (LWP 28424)] done searching Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47773184727840 (LWP 28424)] 0x00002b730d78de44 in ldap_count_values (vals=0x55e99220) at getvalues.c:153 153 getvalues.c: No such file or directory. in getvalues.c ----- (gdb) bt #0 0x00002b730d78de44 in ldap_count_values (vals=0x55e99220) at getvalues.c:153 #1 0x00005555556a25c0 in zif_ldap_get_entries (ht=1441370656, return_value=0x555555e987a8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1438266616, tsrm_ls=0x555555e9cc60) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068 #2 0x0000555555890d35 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9f13efb0, tsrm_ls=0x555555ba4450) at zend_vm_execute.h:200 #3 0x0000555555899c6a in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fff9f13efb0, tsrm_ls=0x555555ba4450) at zend_vm_execute.h:1640 #4 0x000055555589039b in execute (op_array=0x555555e96ad8, tsrm_ls=0x555555ba4450) at zend_vm_execute.h:92 #5 0x0000555555868a42 in zend_execute_scripts (type=8, tsrm_ls=0x555555ba4450, retval=0x0, file_count=3) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109 #6 0x000055555580f825 in php_execute_script (primary_file=0x7fff9f1415d0, tsrm_ls=0x555555ba4450) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737 #7 0x0000555555939484 in main (argc=3, argv=0x7fff9f141888) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093 ----- Let me know if you need anything else. ------------------------------------------------------------------------ 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/38819 -- Edit this bug report at http://bugs.php.net/?id=38819&edit=1
