ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
Apparently it looks like pastebin is having problems... I've copied
the same output here, for redundancy:
http://www.framewerk.org/~madcoder/vgrind.log
Previous Comments:
------------------------------------------------------------------------
[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] tony2001@php.net
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.
------------------------------------------------------------------------
[2006-09-14 08:28:40] tony2001@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php
for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP 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/38819
--
Edit this bug report at http://bugs.php.net/?id=38819&edit=1