Ask a Question related to PHP Bugs, Design and Development.
-
madcoder at gmail dot com #1
#38819 [NEW]: segfault in ldap_get_entries()
From: madcoder at gmail dot com
Operating system: 2.6.15-gentoo linux amd64
PHP version: 5.1.6
PHP Bug Type: LDAP related
Bug description: segfault in ldap_get_entries()
Description:
------------
I'm getting a segmentation fault when calling ldap_get_entries() after an
ldap search. I get no errors after any of the function calls prior to
ldap_get_entries() (as suggested by ldap_errno() == 0).
Running a similar ldapsearch command line query returns results as
expected.
A similar configuration on another linux installation of the same version
works with no problems. The major difference between those two servers is
the CPU (the working one is an Intel P4, the one that is segfaulting is an
AMD 64-bit Athlon XP)
Reproduce code:
---------------
<?php
$_SERVER['ldap'] = ldap_connect("ldap://server.domain");
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
ldap_start_tls($_SERVER['ldap']);
ldap_bind($_SERVER['ldap'], 'user@domain', 'password');
$r = ldap_search($_SERVER['ldap'], 'dc=fq,dc=domain,dc=name',
'(sAMAccountName=someUser)');
echo "done searching\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
echo "done fetching\n";
?>
Expected result:
----------------
"done fetching\n" should be printed, and $info should contain an array of
entries returned from the LDAP server.
Actual result:
--------------
# php -e test.php
done searching
Segmentation fault (core dumped)
----------
# gdb php core
GNU gdb 6.4
(gdb) bt
#0 0x00002aaaac8cbf4b in ?? ()
#1 0xa6e95d9926b7ed00 in ?? ()
#2 0x0000555555dbe260 in ?? ()
#3 0x0000555555de16c0 in ?? ()
#4 0x00005555556a92b5 in ?? ()
#5 0x000000000000000f in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x000000000000000f in ?? ()
#8 0x00002aaaaea76cf0 in ?? ()
#9 0x0000000000000003 in ?? ()
#10 0x0000000000000000 in ?? ()
(I realize this backtrace is not helpful... I've tried re-emerging the
php ebuild several times with the debug USE flag enabled, and it seems all
the debug info is still being stripped from the binaries. I will try
compiling from source with the appropriate options and reply with a more
useful backtrace)
--
Edit bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
--
Try a CVS snapshot (PHP 4.4): [url]http://bugs.php.net/fix.php?id=38819&r=trysnapshot44[/url]
Try a CVS snapshot (PHP 5.2): [url]http://bugs.php.net/fix.php?id=38819&r=trysnapshot52[/url]
Try a CVS snapshot (PHP 6.0): [url]http://bugs.php.net/fix.php?id=38819&r=trysnapshot60[/url]
Fixed in CVS: [url]http://bugs.php.net/fix.php?id=38819&r=fixedcvs[/url]
Fixed in release: [url]http://bugs.php.net/fix.php?id=38819&r=alreadyfixed[/url]
Need backtrace: [url]http://bugs.php.net/fix.php?id=38819&r=needtrace[/url]
Need Reproduce Script: [url]http://bugs.php.net/fix.php?id=38819&r=needscript[/url]
Try newer version: [url]http://bugs.php.net/fix.php?id=38819&r=oldversion[/url]
Not developer issue: [url]http://bugs.php.net/fix.php?id=38819&r=support[/url]
Expected behavior: [url]http://bugs.php.net/fix.php?id=38819&r=notwrong[/url]
Not enough info: [url]http://bugs.php.net/fix.php?id=38819&r=notenoughinfo[/url]
Submitted twice: [url]http://bugs.php.net/fix.php?id=38819&r=submittedtwice[/url]
register_globals: [url]http://bugs.php.net/fix.php?id=38819&r=globals[/url]
PHP 3 support discontinued: [url]http://bugs.php.net/fix.php?id=38819&r=php3[/url]
Daylight Savings: [url]http://bugs.php.net/fix.php?id=38819&r=dst[/url]
IIS Stability: [url]http://bugs.php.net/fix.php?id=38819&r=isapi[/url]
Install GNU Sed: [url]http://bugs.php.net/fix.php?id=38819&r=gnused[/url]
Floating point limitations: [url]http://bugs.php.net/fix.php?id=38819&r=float[/url]
No Zend Extensions: [url]http://bugs.php.net/fix.php?id=38819&r=nozend[/url]
MySQL Configuration Error: [url]http://bugs.php.net/fix.php?id=38819&r=mysqlcfg[/url]
madcoder at gmail dot com Guest
-
#40671 [NEW]: segfault in ldap_get_entries() & LDAP functions implemented poorly
From: cardoe at gentoo dot org Operating system: Linux PHP version: 5.2.1 PHP Bug Type: LDAP related Bug description: ... -
#40026 [NEW]: ldap_get_entries dies with no errors
From: sharul at utm dot my Operating system: Debian Sarge PHP version: 5.2.0 PHP Bug Type: LDAP related Bug description: ... -
GC Segfault [LONG]
Hello Rubyists! let me apologize first: I have no means of condensing my problem to a few lines of code. I'll explain: I'm currently building... -
[PHP-DEV] Yet Another Segfault
I came across the following segfault while working on PHPUnit. So far I have not been able to come up with a minimal reproducing script, but maybe... -
Segfault on 4.1.2 on RH 7.2
Yes, yes, I know it's ancient -- but it's also what's out there for RPMs, and if I need to go to source I will, but for now... One single... -
tony2001@php.net #2 #38819 [Opn->Fbk]: segfault in ldap_get_entries()
ID: 38819
Updated by: [email]tony2001@php.net[/email]
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:
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
[url]http://bugs.php.net/bugs-generating-backtrace.php[/url] for *NIX and
[url]http://bugs.php.net/bugs-generating-backtrace-win32.php[/url] 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.
Previous Comments:
------------------------------------------------------------------------
[2006-09-14 01:29:55] madcoder at gmail dot com
Description:
------------
I'm getting a segmentation fault when calling ldap_get_entries() after
an ldap search. I get no errors after any of the function calls prior
to ldap_get_entries() (as suggested by ldap_errno() == 0).
Running a similar ldapsearch command line query returns results as
expected.
A similar configuration on another linux installation of the same
version works with no problems. The major difference between those two
servers is the CPU (the working one is an Intel P4, the one that is
segfaulting is an AMD 64-bit Athlon XP)
Reproduce code:
---------------
<?php
$_SERVER['ldap'] = ldap_connect("ldap://server.domain");
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
ldap_start_tls($_SERVER['ldap']);
ldap_bind($_SERVER['ldap'], 'user@domain', 'password');
$r = ldap_search($_SERVER['ldap'], 'dc=fq,dc=domain,dc=name',
'(sAMAccountName=someUser)');
echo "done searching\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
echo "done fetching\n";
?>
Expected result:
----------------
"done fetching\n" should be printed, and $info should contain an array
of entries returned from the LDAP server.
Actual result:
--------------
# php -e test.php
done searching
Segmentation fault (core dumped)
----------
# gdb php core
GNU gdb 6.4
(gdb) bt
#0 0x00002aaaac8cbf4b in ?? ()
#1 0xa6e95d9926b7ed00 in ?? ()
#2 0x0000555555dbe260 in ?? ()
#3 0x0000555555de16c0 in ?? ()
#4 0x00005555556a92b5 in ?? ()
#5 0x000000000000000f in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x000000000000000f in ?? ()
#8 0x00002aaaaea76cf0 in ?? ()
#9 0x0000000000000003 in ?? ()
#10 0x0000000000000000 in ?? ()
(I realize this backtrace is not helpful... I've tried re-emerging the
php ebuild several times with the debug USE flag enabled, and it seems
all the debug info is still being stripped from the binaries. I will
try compiling from source with the appropriate options and reply with a
more useful backtrace)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
tony2001@php.net Guest
-
madcoder at gmail dot com #3 #38819 [Fbk->Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2006-09-14 08:28:40] [email]tony2001@php.net[/email]
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
[url]http://bugs.php.net/bugs-generating-backtrace.php[/url] for *NIX and
[url]http://bugs.php.net/bugs-generating-backtrace-win32.php[/url] 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.
------------------------------------------------------------------------
[2006-09-14 01:29:55] madcoder at gmail dot com
Description:
------------
I'm getting a segmentation fault when calling ldap_get_entries() after
an ldap search. I get no errors after any of the function calls prior
to ldap_get_entries() (as suggested by ldap_errno() == 0).
Running a similar ldapsearch command line query returns results as
expected.
A similar configuration on another linux installation of the same
version works with no problems. The major difference between those two
servers is the CPU (the working one is an Intel P4, the one that is
segfaulting is an AMD 64-bit Athlon XP)
Reproduce code:
---------------
<?php
$_SERVER['ldap'] = ldap_connect("ldap://server.domain");
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
ldap_start_tls($_SERVER['ldap']);
ldap_bind($_SERVER['ldap'], 'user@domain', 'password');
$r = ldap_search($_SERVER['ldap'], 'dc=fq,dc=domain,dc=name',
'(sAMAccountName=someUser)');
echo "done searching\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
echo "done fetching\n";
?>
Expected result:
----------------
"done fetching\n" should be printed, and $info should contain an array
of entries returned from the LDAP server.
Actual result:
--------------
# php -e test.php
done searching
Segmentation fault (core dumped)
----------
# gdb php core
GNU gdb 6.4
(gdb) bt
#0 0x00002aaaac8cbf4b in ?? ()
#1 0xa6e95d9926b7ed00 in ?? ()
#2 0x0000555555dbe260 in ?? ()
#3 0x0000555555de16c0 in ?? ()
#4 0x00005555556a92b5 in ?? ()
#5 0x000000000000000f in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x000000000000000f in ?? ()
#8 0x00002aaaaea76cf0 in ?? ()
#9 0x0000000000000003 in ?? ()
#10 0x0000000000000000 in ?? ()
(I realize this backtrace is not helpful... I've tried re-emerging the
php ebuild several times with the debug USE flag enabled, and it seems
all the debug info is still being stripped from the binaries. I will
try compiling from source with the appropriate options and reply with a
more useful backtrace)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
-
tony2001@php.net #4 #38819 [Opn->Fbk]: segfault in ldap_get_entries()
ID: 38819
Updated by: [email]tony2001@php.net[/email]
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:
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.
Previous Comments:
------------------------------------------------------------------------
[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] [email]tony2001@php.net[/email]
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
[url]http://bugs.php.net/bugs-generating-backtrace.php[/url] for *NIX and
[url]http://bugs.php.net/bugs-generating-backtrace-win32.php[/url] 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.
------------------------------------------------------------------------
[2006-09-14 01:29:55] madcoder at gmail dot com
Description:
------------
I'm getting a segmentation fault when calling ldap_get_entries() after
an ldap search. I get no errors after any of the function calls prior
to ldap_get_entries() (as suggested by ldap_errno() == 0).
Running a similar ldapsearch command line query returns results as
expected.
A similar configuration on another linux installation of the same
version works with no problems. The major difference between those two
servers is the CPU (the working one is an Intel P4, the one that is
segfaulting is an AMD 64-bit Athlon XP)
Reproduce code:
---------------
<?php
$_SERVER['ldap'] = ldap_connect("ldap://server.domain");
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
ldap_start_tls($_SERVER['ldap']);
ldap_bind($_SERVER['ldap'], 'user@domain', 'password');
$r = ldap_search($_SERVER['ldap'], 'dc=fq,dc=domain,dc=name',
'(sAMAccountName=someUser)');
echo "done searching\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
echo "done fetching\n";
?>
Expected result:
----------------
"done fetching\n" should be printed, and $info should contain an array
of entries returned from the LDAP server.
Actual result:
--------------
# php -e test.php
done searching
Segmentation fault (core dumped)
----------
# gdb php core
GNU gdb 6.4
(gdb) bt
#0 0x00002aaaac8cbf4b in ?? ()
#1 0xa6e95d9926b7ed00 in ?? ()
#2 0x0000555555dbe260 in ?? ()
#3 0x0000555555de16c0 in ?? ()
#4 0x00005555556a92b5 in ?? ()
#5 0x000000000000000f in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x000000000000000f in ?? ()
#8 0x00002aaaaea76cf0 in ?? ()
#9 0x0000000000000003 in ?? ()
#10 0x0000000000000000 in ?? ()
(I realize this backtrace is not helpful... I've tried re-emerging the
php ebuild several times with the debug USE flag enabled, and it seems
all the debug info is still being stripped from the binaries. I will
try compiling from source with the appropriate options and reply with a
more useful backtrace)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
tony2001@php.net Guest
-
madcoder at gmail dot com #5 #38819 [Fbk->Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
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)
Previous Comments:
------------------------------------------------------------------------
[2006-09-19 06:24:54] [email]tony2001@php.net[/email]
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] [email]tony2001@php.net[/email]
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
[url]http://bugs.php.net/bugs-generating-backtrace.php[/url] for *NIX and
[url]http://bugs.php.net/bugs-generating-backtrace-win32.php[/url] 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.
------------------------------------------------------------------------
[2006-09-14 01:29:55] madcoder at gmail dot com
Description:
------------
I'm getting a segmentation fault when calling ldap_get_entries() after
an ldap search. I get no errors after any of the function calls prior
to ldap_get_entries() (as suggested by ldap_errno() == 0).
Running a similar ldapsearch command line query returns results as
expected.
A similar configuration on another linux installation of the same
version works with no problems. The major difference between those two
servers is the CPU (the working one is an Intel P4, the one that is
segfaulting is an AMD 64-bit Athlon XP)
Reproduce code:
---------------
<?php
$_SERVER['ldap'] = ldap_connect("ldap://server.domain");
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
ldap_start_tls($_SERVER['ldap']);
ldap_bind($_SERVER['ldap'], 'user@domain', 'password');
$r = ldap_search($_SERVER['ldap'], 'dc=fq,dc=domain,dc=name',
'(sAMAccountName=someUser)');
echo "done searching\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
echo "done fetching\n";
?>
Expected result:
----------------
"done fetching\n" should be printed, and $info should contain an array
of entries returned from the LDAP server.
Actual result:
--------------
# php -e test.php
done searching
Segmentation fault (core dumped)
----------
# gdb php core
GNU gdb 6.4
(gdb) bt
#0 0x00002aaaac8cbf4b in ?? ()
#1 0xa6e95d9926b7ed00 in ?? ()
#2 0x0000555555dbe260 in ?? ()
#3 0x0000555555de16c0 in ?? ()
#4 0x00005555556a92b5 in ?? ()
#5 0x000000000000000f in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x000000000000000f in ?? ()
#8 0x00002aaaaea76cf0 in ?? ()
#9 0x0000000000000003 in ?? ()
#10 0x0000000000000000 in ?? ()
(I realize this backtrace is not helpful... I've tried re-emerging the
php ebuild several times with the debug USE flag enabled, and it seems
all the debug info is still being stripped from the binaries. I will
try compiling from source with the appropriate options and reply with a
more useful backtrace)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
-
madcoder at gmail dot com #6 #38819 [Opn]: segfault in ldap_get_entries()
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:
I ran it through valgrind with --leak-check=full -v
--show-reachable=yes, and copied the output here:
[url]http://pastebin.com/790150[/url]
Previous Comments:
------------------------------------------------------------------------
[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]tony2001@php.net[/email]
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] [email]tony2001@php.net[/email]
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
[url]http://bugs.php.net/bugs-generating-backtrace.php[/url] for *NIX and
[url]http://bugs.php.net/bugs-generating-backtrace-win32.php[/url] 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.
------------------------------------------------------------------------
[2006-09-14 01:29:55] madcoder at gmail dot com
Description:
------------
I'm getting a segmentation fault when calling ldap_get_entries() after
an ldap search. I get no errors after any of the function calls prior
to ldap_get_entries() (as suggested by ldap_errno() == 0).
Running a similar ldapsearch command line query returns results as
expected.
A similar configuration on another linux installation of the same
version works with no problems. The major difference between those two
servers is the CPU (the working one is an Intel P4, the one that is
segfaulting is an AMD 64-bit Athlon XP)
Reproduce code:
---------------
<?php
$_SERVER['ldap'] = ldap_connect("ldap://server.domain");
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
ldap_start_tls($_SERVER['ldap']);
ldap_bind($_SERVER['ldap'], 'user@domain', 'password');
$r = ldap_search($_SERVER['ldap'], 'dc=fq,dc=domain,dc=name',
'(sAMAccountName=someUser)');
echo "done searching\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
echo "done fetching\n";
?>
Expected result:
----------------
"done fetching\n" should be printed, and $info should contain an array
of entries returned from the LDAP server.
Actual result:
--------------
# php -e test.php
done searching
Segmentation fault (core dumped)
----------
# gdb php core
GNU gdb 6.4
(gdb) bt
#0 0x00002aaaac8cbf4b in ?? ()
#1 0xa6e95d9926b7ed00 in ?? ()
#2 0x0000555555dbe260 in ?? ()
#3 0x0000555555de16c0 in ?? ()
#4 0x00005555556a92b5 in ?? ()
#5 0x000000000000000f in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x000000000000000f in ?? ()
#8 0x00002aaaaea76cf0 in ?? ()
#9 0x0000000000000003 in ?? ()
#10 0x0000000000000000 in ?? ()
(I realize this backtrace is not helpful... I've tried re-emerging the
php ebuild several times with the debug USE flag enabled, and it seems
all the debug info is still being stripped from the binaries. I will
try compiling from source with the appropriate options and reply with a
more useful backtrace)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
-
madcoder at gmail dot com #7 #38819 [Opn]: segfault in ldap_get_entries()
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:
[url]http://www.framewerk.org/~madcoder/vgrind.log[/url]
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:
[url]http://pastebin.com/790150[/url]
------------------------------------------------------------------------
[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]tony2001@php.net[/email]
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] [email]tony2001@php.net[/email]
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
[url]http://bugs.php.net/bugs-generating-backtrace.php[/url] for *NIX and
[url]http://bugs.php.net/bugs-generating-backtrace-win32.php[/url] 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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
-
tony2001@php.net #8 #38819 [Opn->Fbk]: segfault in ldap_get_entries()
ID: 38819
Updated by: [email]tony2001@php.net[/email]
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:
[url]http://www.framewerk.org/~madcoder/vgrind.log[/url]
------------------------------------------------------------------------
[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:
[url]http://pastebin.com/790150[/url]
------------------------------------------------------------------------
[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]tony2001@php.net[/email]
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
tony2001@php.net Guest
-
madcoder at gmail dot com #9 #38819 [Fbk->Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
My configure line (generated by gentoo's portage):
-----
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64'
'--enable-cli' '--disable-cgi' '--with-apxs2=/usr/sbin/apxs2'
'--enable-maintainer-zts' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--disable-ctype' '--without-curl' '--without-curlwrappers'
'--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--enable-ftp' '--with-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-mbstring' '--with-mcrypt' '--enable-memory-limit'
'--without-mhash' '--without-ming' '--without-msql' '--with-mssql'
'--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr'
'--disable-pcntl' '--disable-pdo' '--with-pgsql' '--disable-posix'
'--with-pspell' '--without-recode' '--disable-shmop' '--with-snmp'
'--enable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--with-tidy' '--disable-wddx'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--with-xsl' '--with-zlib' '--enable-debug' '--enable-dba'
'--without-cdb' '--with-db4' '--without-flatfile' '--with-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr/X11R6' '--with-gd' '--with-ldap'
'--without-ldap-sasl' '--with-mysql=/usr/lib/mysql'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-mysqli'
'--with-readline' '--without-libedit' '--without-mm'
'--with-sqlite=/usr' '--disable-sqlite-utf8'
-----
The version of MySQL is:
Client API version 4.1.21
My Gentoo portage USE flags for dev-lang/php:
[ebuild R ] dev-lang/php-5.1.6-r4 USE="apache2 berkdb bzip2 cli
crypt debug fastbuild ftp gd gdbm ldap memlimit mssql mysql ncurses nls
pcre pdo-external postgres readline reflection session simplexml snmp
soap sockets spell spl sqlite ssl threads tidy tokenizer xml xpm xsl
zlib -apache -bcmath -calendar -cdb -cgi -cjk -concurrentmodphp -ctype
-curl -curlwrappers -db2 -dbase -discard-path -doc -exif -flatfile
-force-cgi-redirect -gd-external -gmp -hardenedphp -hash -hyperwave-api
-iconv -imap -inifile -interbase -iodbc -ipv6 -java-external -kerberos
-libedit -mcve -mhash -ming -msql -mysqli -oci8 -odbc -pcntl -pdo -pic
-posix -qdbm -recode -sapdb -sasl -sharedext -sharedmem -sysvipc
-truetype -unicode -vm-goto -vm-switch -wddx -xmlreader -xmlrpc
-xmlwriter -yaz -zip"
I have also compiled with pdo-external, including dblib, mysql, pgsql,
and sqlite support. The pdo-mysql version is the same library
(4.1.21).
I can recompile without mysql support to see if that might be part of
it? Or PDO?
Previous Comments:
------------------------------------------------------------------------
[2006-09-23 11:32:03] [email]tony2001@php.net[/email]
What was your configure line and did you enable any of mysql related
extensions? If yes, then what is the version of MySQL?
------------------------------------------------------------------------
[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:
[url]http://www.framewerk.org/~madcoder/vgrind.log[/url]
------------------------------------------------------------------------
[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:
[url]http://pastebin.com/790150[/url]
------------------------------------------------------------------------
[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]tony2001@php.net[/email]
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.
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
-
tony2001@php.net #10 #38819 [Opn->Fbk]: segfault in ldap_get_entries()
ID: 38819
Updated by: [email]tony2001@php.net[/email]
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:
Yes, please recompile it with just ./configure --enable-debug
--with-ldap --disable-all and try again.
Previous Comments:
------------------------------------------------------------------------
[2006-09-24 03:59:33] madcoder at gmail dot com
My configure line (generated by gentoo's portage):
-----
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64'
'--enable-cli' '--disable-cgi' '--with-apxs2=/usr/sbin/apxs2'
'--enable-maintainer-zts' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--disable-ctype' '--without-curl' '--without-curlwrappers'
'--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--enable-ftp' '--with-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-mbstring' '--with-mcrypt' '--enable-memory-limit'
'--without-mhash' '--without-ming' '--without-msql' '--with-mssql'
'--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr'
'--disable-pcntl' '--disable-pdo' '--with-pgsql' '--disable-posix'
'--with-pspell' '--without-recode' '--disable-shmop' '--with-snmp'
'--enable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--with-tidy' '--disable-wddx'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--with-xsl' '--with-zlib' '--enable-debug' '--enable-dba'
'--without-cdb' '--with-db4' '--without-flatfile' '--with-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr/X11R6' '--with-gd' '--with-ldap'
'--without-ldap-sasl' '--with-mysql=/usr/lib/mysql'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-mysqli'
'--with-readline' '--without-libedit' '--without-mm'
'--with-sqlite=/usr' '--disable-sqlite-utf8'
-----
The version of MySQL is:
Client API version 4.1.21
My Gentoo portage USE flags for dev-lang/php:
[ebuild R ] dev-lang/php-5.1.6-r4 USE="apache2 berkdb bzip2 cli
crypt debug fastbuild ftp gd gdbm ldap memlimit mssql mysql ncurses nls
pcre pdo-external postgres readline reflection session simplexml snmp
soap sockets spell spl sqlite ssl threads tidy tokenizer xml xpm xsl
zlib -apache -bcmath -calendar -cdb -cgi -cjk -concurrentmodphp -ctype
-curl -curlwrappers -db2 -dbase -discard-path -doc -exif -flatfile
-force-cgi-redirect -gd-external -gmp -hardenedphp -hash -hyperwave-api
-iconv -imap -inifile -interbase -iodbc -ipv6 -java-external -kerberos
-libedit -mcve -mhash -ming -msql -mysqli -oci8 -odbc -pcntl -pdo -pic
-posix -qdbm -recode -sapdb -sasl -sharedext -sharedmem -sysvipc
-truetype -unicode -vm-goto -vm-switch -wddx -xmlreader -xmlrpc
-xmlwriter -yaz -zip"
I have also compiled with pdo-external, including dblib, mysql, pgsql,
and sqlite support. The pdo-mysql version is the same library
(4.1.21).
I can recompile without mysql support to see if that might be part of
it? Or PDO?
------------------------------------------------------------------------
[2006-09-23 11:32:03] [email]tony2001@php.net[/email]
What was your configure line and did you enable any of mysql related
extensions? If yes, then what is the version of MySQL?
------------------------------------------------------------------------
[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:
[url]http://www.framewerk.org/~madcoder/vgrind.log[/url]
------------------------------------------------------------------------
[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:
[url]http://pastebin.com/790150[/url]
------------------------------------------------------------------------
[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)
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
tony2001@php.net Guest
-
madcoder at gmail dot com #11 #38819 [Fbk->Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
I've recompiled PHP with:
# emerge -pv php
[ebuild R ] dev-lang/php-5.1.6-r4 USE="debug ldap -apache -apache2
-bcmath -berkdb -bzip2 -calendar -cdb -cgi -cjk -cli -concurrentmodphp
-crypt -ctype -curl -curlwrappers -db2 -dbase -discard-path -doc -exif
-flatfile -force-cgi-redirect -ftp -gd -gd-external -gdbm -gmp
-hardenedphp -hash -hyperwave-api -iconv -imap -inifile -interbase
-iodbc -ipv6 -java-external -kerberos -libedit -mcve -memlimit -mhash
-ming -msql -mssql -mysql -mysqli -ncurses -nls -oci8 -odbc -pcntl
-pcre -pdo -pdo-external -pic -posix -postgres -qdbm -readline -recode
-reflection -sapdb -sasl -session -sharedext -sharedmem -simplexml
-snmp -soap -sockets -spell -spl -sqlite -ssl -sysvipc -threads -tidy
-tokenizer -truetype -unicode -vm-goto -vm-switch -wddx -xml -xmlreader
-xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zlib"
(enabling only ldap and debug)
It results in the following configure line, as reported by phpinfo():
Configure Command => './configure' '--prefix=/usr/lib64/php5'
'--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man'
'--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc'
'--cache-file=./config.cache' '--with-libdir=lib64' '--enable-cli'
'--disable-cgi' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--without-bz2'
'--disable-calendar' '--disable-ctype' '--without-curl'
'--without-curlwrappers' '--disable-dbase' '--disable-dom'
'--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--disable-ftp' '--without-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-libxml' '--disable-mbstring' '--without-mcrypt'
'--disable-memory-limit' '--without-mhash' '--without-ming'
'--without-msql' '--without-mssql' '--without-ncurses'
'--without-openssl' '--without-openssl-dir' '--disable-pcntl'
'--without-pcre-regex' '--disable-pdo' '--without-pgsql'
'--disable-posix' '--without-pspell' '--without-recode'
'--disable-reflection' '--disable-simplexml' '--disable-shmop'
'--without-snmp' '--disable-soap' '--disable-sockets' '--disable-spl'
'--without-sybase' '--without-sybase-ct' '--disable-sysvmsg'
'--disable-sysvsem' '--disable-sysvshm' '--without-tidy'
'--disable-tokenizer' '--disable-wddx' '--disable-xml'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--without-xsl' '--without-zlib' '--enable-debug' '--without-cdb'
'--without-db4' '--without-flatfile' '--without-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--without-jpeg-dir' '--without-png-dir' '--without-xpm-dir'
'--without-gd' '--with-ldap' '--without-ldap-sasl' '--without-mysqli'
'--without-readline' '--without-libedit' '--disable-session'
'--without-sqlite'
And it still segfaults:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
Previous Comments:
------------------------------------------------------------------------
[2006-09-25 07:13:50] [email]tony2001@php.net[/email]
Yes, please recompile it with just ./configure --enable-debug
--with-ldap --disable-all and try again.
------------------------------------------------------------------------
[2006-09-24 03:59:33] madcoder at gmail dot com
My configure line (generated by gentoo's portage):
-----
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64'
'--enable-cli' '--disable-cgi' '--with-apxs2=/usr/sbin/apxs2'
'--enable-maintainer-zts' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--disable-ctype' '--without-curl' '--without-curlwrappers'
'--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--enable-ftp' '--with-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-mbstring' '--with-mcrypt' '--enable-memory-limit'
'--without-mhash' '--without-ming' '--without-msql' '--with-mssql'
'--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr'
'--disable-pcntl' '--disable-pdo' '--with-pgsql' '--disable-posix'
'--with-pspell' '--without-recode' '--disable-shmop' '--with-snmp'
'--enable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--with-tidy' '--disable-wddx'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--with-xsl' '--with-zlib' '--enable-debug' '--enable-dba'
'--without-cdb' '--with-db4' '--without-flatfile' '--with-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr/X11R6' '--with-gd' '--with-ldap'
'--without-ldap-sasl' '--with-mysql=/usr/lib/mysql'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-mysqli'
'--with-readline' '--without-libedit' '--without-mm'
'--with-sqlite=/usr' '--disable-sqlite-utf8'
-----
The version of MySQL is:
Client API version 4.1.21
My Gentoo portage USE flags for dev-lang/php:
[ebuild R ] dev-lang/php-5.1.6-r4 USE="apache2 berkdb bzip2 cli
crypt debug fastbuild ftp gd gdbm ldap memlimit mssql mysql ncurses nls
pcre pdo-external postgres readline reflection session simplexml snmp
soap sockets spell spl sqlite ssl threads tidy tokenizer xml xpm xsl
zlib -apache -bcmath -calendar -cdb -cgi -cjk -concurrentmodphp -ctype
-curl -curlwrappers -db2 -dbase -discard-path -doc -exif -flatfile
-force-cgi-redirect -gd-external -gmp -hardenedphp -hash -hyperwave-api
-iconv -imap -inifile -interbase -iodbc -ipv6 -java-external -kerberos
-libedit -mcve -mhash -ming -msql -mysqli -oci8 -odbc -pcntl -pdo -pic
-posix -qdbm -recode -sapdb -sasl -sharedext -sharedmem -sysvipc
-truetype -unicode -vm-goto -vm-switch -wddx -xmlreader -xmlrpc
-xmlwriter -yaz -zip"
I have also compiled with pdo-external, including dblib, mysql, pgsql,
and sqlite support. The pdo-mysql version is the same library
(4.1.21).
I can recompile without mysql support to see if that might be part of
it? Or PDO?
------------------------------------------------------------------------
[2006-09-23 11:32:03] [email]tony2001@php.net[/email]
What was your configure line and did you enable any of mysql related
extensions? If yes, then what is the version of MySQL?
------------------------------------------------------------------------
[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:
[url]http://www.framewerk.org/~madcoder/vgrind.log[/url]
------------------------------------------------------------------------
[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:
[url]http://pastebin.com/790150[/url]
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
-
tony2001@php.net #12 #38819 [Opn->Fbk]: segfault in ldap_get_entries()
ID: 38819
Updated by: [email]tony2001@php.net[/email]
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 is the backtrace and how to reproduce it?
Previous Comments:
------------------------------------------------------------------------
[2006-09-25 21:42:38] madcoder at gmail dot com
I've recompiled PHP with:
# emerge -pv php
[ebuild R ] dev-lang/php-5.1.6-r4 USE="debug ldap -apache -apache2
-bcmath -berkdb -bzip2 -calendar -cdb -cgi -cjk -cli -concurrentmodphp
-crypt -ctype -curl -curlwrappers -db2 -dbase -discard-path -doc -exif
-flatfile -force-cgi-redirect -ftp -gd -gd-external -gdbm -gmp
-hardenedphp -hash -hyperwave-api -iconv -imap -inifile -interbase
-iodbc -ipv6 -java-external -kerberos -libedit -mcve -memlimit -mhash
-ming -msql -mssql -mysql -mysqli -ncurses -nls -oci8 -odbc -pcntl
-pcre -pdo -pdo-external -pic -posix -postgres -qdbm -readline -recode
-reflection -sapdb -sasl -session -sharedext -sharedmem -simplexml
-snmp -soap -sockets -spell -spl -sqlite -ssl -sysvipc -threads -tidy
-tokenizer -truetype -unicode -vm-goto -vm-switch -wddx -xml -xmlreader
-xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zlib"
(enabling only ldap and debug)
It results in the following configure line, as reported by phpinfo():
Configure Command => './configure' '--prefix=/usr/lib64/php5'
'--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man'
'--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc'
'--cache-file=./config.cache' '--with-libdir=lib64' '--enable-cli'
'--disable-cgi' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--without-bz2'
'--disable-calendar' '--disable-ctype' '--without-curl'
'--without-curlwrappers' '--disable-dbase' '--disable-dom'
'--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--disable-ftp' '--without-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-libxml' '--disable-mbstring' '--without-mcrypt'
'--disable-memory-limit' '--without-mhash' '--without-ming'
'--without-msql' '--without-mssql' '--without-ncurses'
'--without-openssl' '--without-openssl-dir' '--disable-pcntl'
'--without-pcre-regex' '--disable-pdo' '--without-pgsql'
'--disable-posix' '--without-pspell' '--without-recode'
'--disable-reflection' '--disable-simplexml' '--disable-shmop'
'--without-snmp' '--disable-soap' '--disable-sockets' '--disable-spl'
'--without-sybase' '--without-sybase-ct' '--disable-sysvmsg'
'--disable-sysvsem' '--disable-sysvshm' '--without-tidy'
'--disable-tokenizer' '--disable-wddx' '--disable-xml'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--without-xsl' '--without-zlib' '--enable-debug' '--without-cdb'
'--without-db4' '--without-flatfile' '--without-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--without-jpeg-dir' '--without-png-dir' '--without-xpm-dir'
'--without-gd' '--with-ldap' '--without-ldap-sasl' '--without-mysqli'
'--without-readline' '--without-libedit' '--disable-session'
'--without-sqlite'
And it still segfaults:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
------------------------------------------------------------------------
[2006-09-25 07:13:50] [email]tony2001@php.net[/email]
Yes, please recompile it with just ./configure --enable-debug
--with-ldap --disable-all and try again.
------------------------------------------------------------------------
[2006-09-24 03:59:33] madcoder at gmail dot com
My configure line (generated by gentoo's portage):
-----
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64'
'--enable-cli' '--disable-cgi' '--with-apxs2=/usr/sbin/apxs2'
'--enable-maintainer-zts' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--disable-ctype' '--without-curl' '--without-curlwrappers'
'--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--enable-ftp' '--with-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-mbstring' '--with-mcrypt' '--enable-memory-limit'
'--without-mhash' '--without-ming' '--without-msql' '--with-mssql'
'--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr'
'--disable-pcntl' '--disable-pdo' '--with-pgsql' '--disable-posix'
'--with-pspell' '--without-recode' '--disable-shmop' '--with-snmp'
'--enable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--with-tidy' '--disable-wddx'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--with-xsl' '--with-zlib' '--enable-debug' '--enable-dba'
'--without-cdb' '--with-db4' '--without-flatfile' '--with-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr/X11R6' '--with-gd' '--with-ldap'
'--without-ldap-sasl' '--with-mysql=/usr/lib/mysql'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-mysqli'
'--with-readline' '--without-libedit' '--without-mm'
'--with-sqlite=/usr' '--disable-sqlite-utf8'
-----
The version of MySQL is:
Client API version 4.1.21
My Gentoo portage USE flags for dev-lang/php:
[ebuild R ] dev-lang/php-5.1.6-r4 USE="apache2 berkdb bzip2 cli
crypt debug fastbuild ftp gd gdbm ldap memlimit mssql mysql ncurses nls
pcre pdo-external postgres readline reflection session simplexml snmp
soap sockets spell spl sqlite ssl threads tidy tokenizer xml xpm xsl
zlib -apache -bcmath -calendar -cdb -cgi -cjk -concurrentmodphp -ctype
-curl -curlwrappers -db2 -dbase -discard-path -doc -exif -flatfile
-force-cgi-redirect -gd-external -gmp -hardenedphp -hash -hyperwave-api
-iconv -imap -inifile -interbase -iodbc -ipv6 -java-external -kerberos
-libedit -mcve -mhash -ming -msql -mysqli -oci8 -odbc -pcntl -pdo -pic
-posix -qdbm -recode -sapdb -sasl -sharedext -sharedmem -sysvipc
-truetype -unicode -vm-goto -vm-switch -wddx -xmlreader -xmlrpc
-xmlwriter -yaz -zip"
I have also compiled with pdo-external, including dblib, mysql, pgsql,
and sqlite support. The pdo-mysql version is the same library
(4.1.21).
I can recompile without mysql support to see if that might be part of
it? Or PDO?
------------------------------------------------------------------------
[2006-09-23 11:32:03] [email]tony2001@php.net[/email]
What was your configure line and did you enable any of mysql related
extensions? If yes, then what is the version of MySQL?
------------------------------------------------------------------------
[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:
[url]http://www.framewerk.org/~madcoder/vgrind.log[/url]
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
tony2001@php.net Guest
-
madcoder at gmail dot com #13 #38819 [Fbk->Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
It's pretty much the same as before...
(gdb) bt
#0 0x00002aae16a8de44 in ldap_count_values (vals=0x559cadc0)
at getvalues.c:153
#1 0x00005555555db423 in zif_ldap_get_entries (ht=1436331456,
return_value=0x5555559ca5c0, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1435796224)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068
#2 0x00005555556e4d20 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff942851d0) at zend_vm_execute.h:200
#3 0x00005555556ed112 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7fff942851d0) at zend_vm_execute.h:1640
#4 0x00005555556e43f9 in execute (op_array=0x5555559c7ae0)
at zend_vm_execute.h:92
#5 0x00005555556bf1d8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109
#6 0x0000555555670784 in php_execute_script
(primary_file=0x7fff94287790)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737
#7 0x00005555557756f4 in main (argc=3, argv=0x7fff942879c8)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093
The ldap code to reproduce the problem is the same as at the beginning
of this report... The difference between the code I posted originally
and the code that gave me the above output (showing "Count: 1"), is
this:
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$r) . "
entries\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
(that is, I added the Count line *after* the original post; everything
else is the same)
Previous Comments:
------------------------------------------------------------------------
[2006-09-25 21:56:59] [email]tony2001@php.net[/email]
What is the backtrace and how to reproduce it?
------------------------------------------------------------------------
[2006-09-25 21:42:38] madcoder at gmail dot com
I've recompiled PHP with:
# emerge -pv php
[ebuild R ] dev-lang/php-5.1.6-r4 USE="debug ldap -apache -apache2
-bcmath -berkdb -bzip2 -calendar -cdb -cgi -cjk -cli -concurrentmodphp
-crypt -ctype -curl -curlwrappers -db2 -dbase -discard-path -doc -exif
-flatfile -force-cgi-redirect -ftp -gd -gd-external -gdbm -gmp
-hardenedphp -hash -hyperwave-api -iconv -imap -inifile -interbase
-iodbc -ipv6 -java-external -kerberos -libedit -mcve -memlimit -mhash
-ming -msql -mssql -mysql -mysqli -ncurses -nls -oci8 -odbc -pcntl
-pcre -pdo -pdo-external -pic -posix -postgres -qdbm -readline -recode
-reflection -sapdb -sasl -session -sharedext -sharedmem -simplexml
-snmp -soap -sockets -spell -spl -sqlite -ssl -sysvipc -threads -tidy
-tokenizer -truetype -unicode -vm-goto -vm-switch -wddx -xml -xmlreader
-xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zlib"
(enabling only ldap and debug)
It results in the following configure line, as reported by phpinfo():
Configure Command => './configure' '--prefix=/usr/lib64/php5'
'--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man'
'--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc'
'--cache-file=./config.cache' '--with-libdir=lib64' '--enable-cli'
'--disable-cgi' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--without-bz2'
'--disable-calendar' '--disable-ctype' '--without-curl'
'--without-curlwrappers' '--disable-dbase' '--disable-dom'
'--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--disable-ftp' '--without-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-libxml' '--disable-mbstring' '--without-mcrypt'
'--disable-memory-limit' '--without-mhash' '--without-ming'
'--without-msql' '--without-mssql' '--without-ncurses'
'--without-openssl' '--without-openssl-dir' '--disable-pcntl'
'--without-pcre-regex' '--disable-pdo' '--without-pgsql'
'--disable-posix' '--without-pspell' '--without-recode'
'--disable-reflection' '--disable-simplexml' '--disable-shmop'
'--without-snmp' '--disable-soap' '--disable-sockets' '--disable-spl'
'--without-sybase' '--without-sybase-ct' '--disable-sysvmsg'
'--disable-sysvsem' '--disable-sysvshm' '--without-tidy'
'--disable-tokenizer' '--disable-wddx' '--disable-xml'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--without-xsl' '--without-zlib' '--enable-debug' '--without-cdb'
'--without-db4' '--without-flatfile' '--without-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--without-jpeg-dir' '--without-png-dir' '--without-xpm-dir'
'--without-gd' '--with-ldap' '--without-ldap-sasl' '--without-mysqli'
'--without-readline' '--without-libedit' '--disable-session'
'--without-sqlite'
And it still segfaults:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
------------------------------------------------------------------------
[2006-09-25 07:13:50] [email]tony2001@php.net[/email]
Yes, please recompile it with just ./configure --enable-debug
--with-ldap --disable-all and try again.
------------------------------------------------------------------------
[2006-09-24 03:59:33] madcoder at gmail dot com
My configure line (generated by gentoo's portage):
-----
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64'
'--enable-cli' '--disable-cgi' '--with-apxs2=/usr/sbin/apxs2'
'--enable-maintainer-zts' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--disable-ctype' '--without-curl' '--without-curlwrappers'
'--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--enable-ftp' '--with-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-mbstring' '--with-mcrypt' '--enable-memory-limit'
'--without-mhash' '--without-ming' '--without-msql' '--with-mssql'
'--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr'
'--disable-pcntl' '--disable-pdo' '--with-pgsql' '--disable-posix'
'--with-pspell' '--without-recode' '--disable-shmop' '--with-snmp'
'--enable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--with-tidy' '--disable-wddx'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--with-xsl' '--with-zlib' '--enable-debug' '--enable-dba'
'--without-cdb' '--with-db4' '--without-flatfile' '--with-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr/X11R6' '--with-gd' '--with-ldap'
'--without-ldap-sasl' '--with-mysql=/usr/lib/mysql'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-mysqli'
'--with-readline' '--without-libedit' '--without-mm'
'--with-sqlite=/usr' '--disable-sqlite-utf8'
-----
The version of MySQL is:
Client API version 4.1.21
My Gentoo portage USE flags for dev-lang/php:
[ebuild R ] dev-lang/php-5.1.6-r4 USE="apache2 berkdb bzip2 cli
crypt debug fastbuild ftp gd gdbm ldap memlimit mssql mysql ncurses nls
pcre pdo-external postgres readline reflection session simplexml snmp
soap sockets spell spl sqlite ssl threads tidy tokenizer xml xpm xsl
zlib -apache -bcmath -calendar -cdb -cgi -cjk -concurrentmodphp -ctype
-curl -curlwrappers -db2 -dbase -discard-path -doc -exif -flatfile
-force-cgi-redirect -gd-external -gmp -hardenedphp -hash -hyperwave-api
-iconv -imap -inifile -interbase -iodbc -ipv6 -java-external -kerberos
-libedit -mcve -mhash -ming -msql -mysqli -oci8 -odbc -pcntl -pdo -pic
-posix -qdbm -recode -sapdb -sasl -sharedext -sharedmem -sysvipc
-truetype -unicode -vm-goto -vm-switch -wddx -xmlreader -xmlrpc
-xmlwriter -yaz -zip"
I have also compiled with pdo-external, including dblib, mysql, pgsql,
and sqlite support. The pdo-mysql version is the same library
(4.1.21).
I can recompile without mysql support to see if that might be part of
it? Or PDO?
------------------------------------------------------------------------
[2006-09-23 11:32:03] [email]tony2001@php.net[/email]
What was your configure line and did you enable any of mysql related
extensions? If yes, then what is the version of MySQL?
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
-
tony2001@php.net #14 #38819 [Opn->Fbk]: segfault in ldap_get_entries()
ID: 38819
Updated by: [email]tony2001@php.net[/email]
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:
I intentionally said "how to reproduce it", not "what is the reproduce
code". It's clear to me that you're still using the same code, but this
code doesn't make much sense to me since I don't have your data, your
variables etc.
Hence the question - how to reproduce it?
Previous Comments:
------------------------------------------------------------------------
[2006-09-25 23:20:32] madcoder at gmail dot com
It's pretty much the same as before...
(gdb) bt
#0 0x00002aae16a8de44 in ldap_count_values (vals=0x559cadc0)
at getvalues.c:153
#1 0x00005555555db423 in zif_ldap_get_entries (ht=1436331456,
return_value=0x5555559ca5c0, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1435796224)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068
#2 0x00005555556e4d20 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff942851d0) at zend_vm_execute.h:200
#3 0x00005555556ed112 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7fff942851d0) at zend_vm_execute.h:1640
#4 0x00005555556e43f9 in execute (op_array=0x5555559c7ae0)
at zend_vm_execute.h:92
#5 0x00005555556bf1d8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109
#6 0x0000555555670784 in php_execute_script
(primary_file=0x7fff94287790)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737
#7 0x00005555557756f4 in main (argc=3, argv=0x7fff942879c8)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093
The ldap code to reproduce the problem is the same as at the beginning
of this report... The difference between the code I posted originally
and the code that gave me the above output (showing "Count: 1"), is
this:
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$r) . "
entries\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
(that is, I added the Count line *after* the original post; everything
else is the same)
------------------------------------------------------------------------
[2006-09-25 21:56:59] [email]tony2001@php.net[/email]
What is the backtrace and how to reproduce it?
------------------------------------------------------------------------
[2006-09-25 21:42:38] madcoder at gmail dot com
I've recompiled PHP with:
# emerge -pv php
[ebuild R ] dev-lang/php-5.1.6-r4 USE="debug ldap -apache -apache2
-bcmath -berkdb -bzip2 -calendar -cdb -cgi -cjk -cli -concurrentmodphp
-crypt -ctype -curl -curlwrappers -db2 -dbase -discard-path -doc -exif
-flatfile -force-cgi-redirect -ftp -gd -gd-external -gdbm -gmp
-hardenedphp -hash -hyperwave-api -iconv -imap -inifile -interbase
-iodbc -ipv6 -java-external -kerberos -libedit -mcve -memlimit -mhash
-ming -msql -mssql -mysql -mysqli -ncurses -nls -oci8 -odbc -pcntl
-pcre -pdo -pdo-external -pic -posix -postgres -qdbm -readline -recode
-reflection -sapdb -sasl -session -sharedext -sharedmem -simplexml
-snmp -soap -sockets -spell -spl -sqlite -ssl -sysvipc -threads -tidy
-tokenizer -truetype -unicode -vm-goto -vm-switch -wddx -xml -xmlreader
-xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zlib"
(enabling only ldap and debug)
It results in the following configure line, as reported by phpinfo():
Configure Command => './configure' '--prefix=/usr/lib64/php5'
'--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man'
'--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc'
'--cache-file=./config.cache' '--with-libdir=lib64' '--enable-cli'
'--disable-cgi' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--without-bz2'
'--disable-calendar' '--disable-ctype' '--without-curl'
'--without-curlwrappers' '--disable-dbase' '--disable-dom'
'--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--disable-ftp' '--without-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-libxml' '--disable-mbstring' '--without-mcrypt'
'--disable-memory-limit' '--without-mhash' '--without-ming'
'--without-msql' '--without-mssql' '--without-ncurses'
'--without-openssl' '--without-openssl-dir' '--disable-pcntl'
'--without-pcre-regex' '--disable-pdo' '--without-pgsql'
'--disable-posix' '--without-pspell' '--without-recode'
'--disable-reflection' '--disable-simplexml' '--disable-shmop'
'--without-snmp' '--disable-soap' '--disable-sockets' '--disable-spl'
'--without-sybase' '--without-sybase-ct' '--disable-sysvmsg'
'--disable-sysvsem' '--disable-sysvshm' '--without-tidy'
'--disable-tokenizer' '--disable-wddx' '--disable-xml'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--without-xsl' '--without-zlib' '--enable-debug' '--without-cdb'
'--without-db4' '--without-flatfile' '--without-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--without-jpeg-dir' '--without-png-dir' '--without-xpm-dir'
'--without-gd' '--with-ldap' '--without-ldap-sasl' '--without-mysqli'
'--without-readline' '--without-libedit' '--disable-session'
'--without-sqlite'
And it still segfaults:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
------------------------------------------------------------------------
[2006-09-25 07:13:50] [email]tony2001@php.net[/email]
Yes, please recompile it with just ./configure --enable-debug
--with-ldap --disable-all and try again.
------------------------------------------------------------------------
[2006-09-24 03:59:33] madcoder at gmail dot com
My configure line (generated by gentoo's portage):
-----
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64'
'--enable-cli' '--disable-cgi' '--with-apxs2=/usr/sbin/apxs2'
'--enable-maintainer-zts' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--disable-ctype' '--without-curl' '--without-curlwrappers'
'--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--enable-ftp' '--with-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-mbstring' '--with-mcrypt' '--enable-memory-limit'
'--without-mhash' '--without-ming' '--without-msql' '--with-mssql'
'--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr'
'--disable-pcntl' '--disable-pdo' '--with-pgsql' '--disable-posix'
'--with-pspell' '--without-recode' '--disable-shmop' '--with-snmp'
'--enable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--with-tidy' '--disable-wddx'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--with-xsl' '--with-zlib' '--enable-debug' '--enable-dba'
'--without-cdb' '--with-db4' '--without-flatfile' '--with-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr/X11R6' '--with-gd' '--with-ldap'
'--without-ldap-sasl' '--with-mysql=/usr/lib/mysql'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-mysqli'
'--with-readline' '--without-libedit' '--without-mm'
'--with-sqlite=/usr' '--disable-sqlite-utf8'
-----
The version of MySQL is:
Client API version 4.1.21
My Gentoo portage USE flags for dev-lang/php:
[ebuild R ] dev-lang/php-5.1.6-r4 USE="apache2 berkdb bzip2 cli
crypt debug fastbuild ftp gd gdbm ldap memlimit mssql mysql ncurses nls
pcre pdo-external postgres readline reflection session simplexml snmp
soap sockets spell spl sqlite ssl threads tidy tokenizer xml xpm xsl
zlib -apache -bcmath -calendar -cdb -cgi -cjk -concurrentmodphp -ctype
-curl -curlwrappers -db2 -dbase -discard-path -doc -exif -flatfile
-force-cgi-redirect -gd-external -gmp -hardenedphp -hash -hyperwave-api
-iconv -imap -inifile -interbase -iodbc -ipv6 -java-external -kerberos
-libedit -mcve -mhash -ming -msql -mysqli -oci8 -odbc -pcntl -pdo -pic
-posix -qdbm -recode -sapdb -sasl -sharedext -sharedmem -sysvipc
-truetype -unicode -vm-goto -vm-switch -wddx -xmlreader -xmlrpc
-xmlwriter -yaz -zip"
I have also compiled with pdo-external, including dblib, mysql, pgsql,
and sqlite support. The pdo-mysql version is the same library
(4.1.21).
I can recompile without mysql support to see if that might be part of
it? Or PDO?
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
tony2001@php.net Guest
-
madcoder at gmail dot com #15 #38819 [Fbk->Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect("ldap://xyzdc02.xyz.acs-inc.com") or
die("ldap connect failed");
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], 'ldsearch@xyz.acs-inc.com', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$result) . "
entries\n";
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo "Done fetching\n";
print_r($info);
==============
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==============
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==============
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2>/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==============
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==============
/etc/openldap/ldap.conf:
BASE dc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==============
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$ ldapsearch -H ldap://xyz.acs-inc.com -D [email]ldsearch@xyz.acs-inc.com[/email] -w
some.Pass "(samaccountname=jhansche)" telephonenumber
# LDAPv3
# base <> with scope subtree
# filter: (samaccountname=jhansche)
# requesting: telephonenumber
# Joe Hansche, Administrators, elp.acs-inc.com
dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
telephoneNumber: 5492
==============
Unfortunately, I don't have another non-MS ldap server to try. It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct. It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries(). I hope that is more informative. If not, please
let me know what additional information I can give you that might help
track this problem down. If you'd like I can try adding some debugging
messages into the ldap portion of the php source to see where it might
be failing, and why?
Thanks, by the way. I appreciate your efforts.
Previous Comments:
------------------------------------------------------------------------
[2006-09-26 07:07:20] [email]tony2001@php.net[/email]
I intentionally said "how to reproduce it", not "what is the reproduce
code". It's clear to me that you're still using the same code, but this
code doesn't make much sense to me since I don't have your data, your
variables etc.
Hence the question - how to reproduce it?
------------------------------------------------------------------------
[2006-09-25 23:20:32] madcoder at gmail dot com
It's pretty much the same as before...
(gdb) bt
#0 0x00002aae16a8de44 in ldap_count_values (vals=0x559cadc0)
at getvalues.c:153
#1 0x00005555555db423 in zif_ldap_get_entries (ht=1436331456,
return_value=0x5555559ca5c0, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1435796224)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068
#2 0x00005555556e4d20 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff942851d0) at zend_vm_execute.h:200
#3 0x00005555556ed112 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7fff942851d0) at zend_vm_execute.h:1640
#4 0x00005555556e43f9 in execute (op_array=0x5555559c7ae0)
at zend_vm_execute.h:92
#5 0x00005555556bf1d8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109
#6 0x0000555555670784 in php_execute_script
(primary_file=0x7fff94287790)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737
#7 0x00005555557756f4 in main (argc=3, argv=0x7fff942879c8)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093
The ldap code to reproduce the problem is the same as at the beginning
of this report... The difference between the code I posted originally
and the code that gave me the above output (showing "Count: 1"), is
this:
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$r) . "
entries\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
(that is, I added the Count line *after* the original post; everything
else is the same)
------------------------------------------------------------------------
[2006-09-25 21:56:59] [email]tony2001@php.net[/email]
What is the backtrace and how to reproduce it?
------------------------------------------------------------------------
[2006-09-25 21:42:38] madcoder at gmail dot com
I've recompiled PHP with:
# emerge -pv php
[ebuild R ] dev-lang/php-5.1.6-r4 USE="debug ldap -apache -apache2
-bcmath -berkdb -bzip2 -calendar -cdb -cgi -cjk -cli -concurrentmodphp
-crypt -ctype -curl -curlwrappers -db2 -dbase -discard-path -doc -exif
-flatfile -force-cgi-redirect -ftp -gd -gd-external -gdbm -gmp
-hardenedphp -hash -hyperwave-api -iconv -imap -inifile -interbase
-iodbc -ipv6 -java-external -kerberos -libedit -mcve -memlimit -mhash
-ming -msql -mssql -mysql -mysqli -ncurses -nls -oci8 -odbc -pcntl
-pcre -pdo -pdo-external -pic -posix -postgres -qdbm -readline -recode
-reflection -sapdb -sasl -session -sharedext -sharedmem -simplexml
-snmp -soap -sockets -spell -spl -sqlite -ssl -sysvipc -threads -tidy
-tokenizer -truetype -unicode -vm-goto -vm-switch -wddx -xml -xmlreader
-xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zlib"
(enabling only ldap and debug)
It results in the following configure line, as reported by phpinfo():
Configure Command => './configure' '--prefix=/usr/lib64/php5'
'--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man'
'--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc'
'--cache-file=./config.cache' '--with-libdir=lib64' '--enable-cli'
'--disable-cgi' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--without-bz2'
'--disable-calendar' '--disable-ctype' '--without-curl'
'--without-curlwrappers' '--disable-dbase' '--disable-dom'
'--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--disable-ftp' '--without-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-libxml' '--disable-mbstring' '--without-mcrypt'
'--disable-memory-limit' '--without-mhash' '--without-ming'
'--without-msql' '--without-mssql' '--without-ncurses'
'--without-openssl' '--without-openssl-dir' '--disable-pcntl'
'--without-pcre-regex' '--disable-pdo' '--without-pgsql'
'--disable-posix' '--without-pspell' '--without-recode'
'--disable-reflection' '--disable-simplexml' '--disable-shmop'
'--without-snmp' '--disable-soap' '--disable-sockets' '--disable-spl'
'--without-sybase' '--without-sybase-ct' '--disable-sysvmsg'
'--disable-sysvsem' '--disable-sysvshm' '--without-tidy'
'--disable-tokenizer' '--disable-wddx' '--disable-xml'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--without-xsl' '--without-zlib' '--enable-debug' '--without-cdb'
'--without-db4' '--without-flatfile' '--without-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--without-jpeg-dir' '--without-png-dir' '--without-xpm-dir'
'--without-gd' '--with-ldap' '--without-ldap-sasl' '--without-mysqli'
'--without-readline' '--without-libedit' '--disable-session'
'--without-sqlite'
And it still segfaults:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
------------------------------------------------------------------------
[2006-09-25 07:13:50] [email]tony2001@php.net[/email]
Yes, please recompile it with just ./configure --enable-debug
--with-ldap --disable-all and try again.
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
-
madcoder at gmail dot com #16 #38819 [Opn]: segfault in ldap_get_entries()
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:
Sorry for the extra post... I just tested with different values in
ldap_connect. For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with "ldap://" caused a segmentation fault
at line 2:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)
All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().
Previous Comments:
------------------------------------------------------------------------
[2006-09-26 09:29:47] madcoder at gmail dot com
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect("ldap://xyzdc02.xyz.acs-inc.com") or
die("ldap connect failed");
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], 'ldsearch@xyz.acs-inc.com', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$result) . "
entries\n";
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo "Done fetching\n";
print_r($info);
==============
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==============
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==============
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2>/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==============
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==============
/etc/openldap/ldap.conf:
BASE dc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==============
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$ ldapsearch -H ldap://xyz.acs-inc.com -D [email]ldsearch@xyz.acs-inc.com[/email] -w
some.Pass "(samaccountname=jhansche)" telephonenumber
# LDAPv3
# base <> with scope subtree
# filter: (samaccountname=jhansche)
# requesting: telephonenumber
# Joe Hansche, Administrators, elp.acs-inc.com
dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
telephoneNumber: 5492
==============
Unfortunately, I don't have another non-MS ldap server to try. It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct. It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries(). I hope that is more informative. If not, please
let me know what additional information I can give you that might help
track this problem down. If you'd like I can try adding some debugging
messages into the ldap portion of the php source to see where it might
be failing, and why?
Thanks, by the way. I appreciate your efforts.
------------------------------------------------------------------------
[2006-09-26 07:07:20] [email]tony2001@php.net[/email]
I intentionally said "how to reproduce it", not "what is the reproduce
code". It's clear to me that you're still using the same code, but this
code doesn't make much sense to me since I don't have your data, your
variables etc.
Hence the question - how to reproduce it?
------------------------------------------------------------------------
[2006-09-25 23:20:32] madcoder at gmail dot com
It's pretty much the same as before...
(gdb) bt
#0 0x00002aae16a8de44 in ldap_count_values (vals=0x559cadc0)
at getvalues.c:153
#1 0x00005555555db423 in zif_ldap_get_entries (ht=1436331456,
return_value=0x5555559ca5c0, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1435796224)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068
#2 0x00005555556e4d20 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff942851d0) at zend_vm_execute.h:200
#3 0x00005555556ed112 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7fff942851d0) at zend_vm_execute.h:1640
#4 0x00005555556e43f9 in execute (op_array=0x5555559c7ae0)
at zend_vm_execute.h:92
#5 0x00005555556bf1d8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109
#6 0x0000555555670784 in php_execute_script
(primary_file=0x7fff94287790)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737
#7 0x00005555557756f4 in main (argc=3, argv=0x7fff942879c8)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093
The ldap code to reproduce the problem is the same as at the beginning
of this report... The difference between the code I posted originally
and the code that gave me the above output (showing "Count: 1"), is
this:
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$r) . "
entries\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
(that is, I added the Count line *after* the original post; everything
else is the same)
------------------------------------------------------------------------
[2006-09-25 21:56:59] [email]tony2001@php.net[/email]
What is the backtrace and how to reproduce it?
------------------------------------------------------------------------
[2006-09-25 21:42:38] madcoder at gmail dot com
I've recompiled PHP with:
# emerge -pv php
[ebuild R ] dev-lang/php-5.1.6-r4 USE="debug ldap -apache -apache2
-bcmath -berkdb -bzip2 -calendar -cdb -cgi -cjk -cli -concurrentmodphp
-crypt -ctype -curl -curlwrappers -db2 -dbase -discard-path -doc -exif
-flatfile -force-cgi-redirect -ftp -gd -gd-external -gdbm -gmp
-hardenedphp -hash -hyperwave-api -iconv -imap -inifile -interbase
-iodbc -ipv6 -java-external -kerberos -libedit -mcve -memlimit -mhash
-ming -msql -mssql -mysql -mysqli -ncurses -nls -oci8 -odbc -pcntl
-pcre -pdo -pdo-external -pic -posix -postgres -qdbm -readline -recode
-reflection -sapdb -sasl -session -sharedext -sharedmem -simplexml
-snmp -soap -sockets -spell -spl -sqlite -ssl -sysvipc -threads -tidy
-tokenizer -truetype -unicode -vm-goto -vm-switch -wddx -xml -xmlreader
-xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zlib"
(enabling only ldap and debug)
It results in the following configure line, as reported by phpinfo():
Configure Command => './configure' '--prefix=/usr/lib64/php5'
'--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man'
'--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc'
'--cache-file=./config.cache' '--with-libdir=lib64' '--enable-cli'
'--disable-cgi' '--with-config-file-path=/etc/php/-php5'
'--with-config-file-scan-dir=/etc/php/-php5/ext-active'
'--without-pear' '--disable-bcmath' '--without-bz2'
'--disable-calendar' '--disable-ctype' '--without-curl'
'--without-curlwrappers' '--disable-dbase' '--disable-dom'
'--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--disable-ftp' '--without-gettext' '--without-gmp'
'--disable-hash' '--without-hwapi' '--without-iconv'
'--without-informix' '--disable-ipv6' '--without-kerberos'
'--disable-libxml' '--disable-mbstring' '--without-mcrypt'
'--disable-memory-limit' '--without-mhash' '--without-ming'
'--without-msql' '--without-mssql' '--without-ncurses'
'--without-openssl' '--without-openssl-dir' '--disable-pcntl'
'--without-pcre-regex' '--disable-pdo' '--without-pgsql'
'--disable-posix' '--without-pspell' '--without-recode'
'--disable-reflection' '--disable-simplexml' '--disable-shmop'
'--without-snmp' '--disable-soap' '--disable-sockets' '--disable-spl'
'--without-sybase' '--without-sybase-ct' '--disable-sysvmsg'
'--disable-sysvsem' '--disable-sysvshm' '--without-tidy'
'--disable-tokenizer' '--disable-wddx' '--disable-xml'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--without-xsl' '--without-zlib' '--enable-debug' '--without-cdb'
'--without-db4' '--without-flatfile' '--without-gdbm'
'--without-inifile' '--without-qdbm' '--without-freetype-dir'
'--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf'
'--without-jpeg-dir' '--without-png-dir' '--without-xpm-dir'
'--without-gd' '--with-ldap' '--without-ldap-sasl' '--without-mysqli'
'--without-readline' '--without-libedit' '--disable-session'
'--without-sqlite'
And it still segfaults:
# php -e test.php
done searching
Count: 1 entries
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
-
tony2001@php.net #17 #38819 [Opn->Fbk]: segfault in ldap_get_entries()
ID: 38819
Updated by: [email]tony2001@php.net[/email]
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:
Is it possible to get an account @ this server?
Previous Comments:
------------------------------------------------------------------------
[2006-09-26 09:36:37] madcoder at gmail dot com
Sorry for the extra post... I just tested with different values in
ldap_connect. For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with "ldap://" caused a segmentation fault
at line 2:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)
All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().
------------------------------------------------------------------------
[2006-09-26 09:29:47] madcoder at gmail dot com
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect("ldap://xyzdc02.xyz.acs-inc.com") or
die("ldap connect failed");
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], 'ldsearch@xyz.acs-inc.com', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$result) . "
entries\n";
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo "Done fetching\n";
print_r($info);
==============
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==============
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==============
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2>/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==============
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==============
/etc/openldap/ldap.conf:
BASE dc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==============
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$ ldapsearch -H ldap://xyz.acs-inc.com -D [email]ldsearch@xyz.acs-inc.com[/email] -w
some.Pass "(samaccountname=jhansche)" telephonenumber
# LDAPv3
# base <> with scope subtree
# filter: (samaccountname=jhansche)
# requesting: telephonenumber
# Joe Hansche, Administrators, elp.acs-inc.com
dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
telephoneNumber: 5492
==============
Unfortunately, I don't have another non-MS ldap server to try. It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct. It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries(). I hope that is more informative. If not, please
let me know what additional information I can give you that might help
track this problem down. If you'd like I can try adding some debugging
messages into the ldap portion of the php source to see where it might
be failing, and why?
Thanks, by the way. I appreciate your efforts.
------------------------------------------------------------------------
[2006-09-26 07:07:20] [email]tony2001@php.net[/email]
I intentionally said "how to reproduce it", not "what is the reproduce
code". It's clear to me that you're still using the same code, but this
code doesn't make much sense to me since I don't have your data, your
variables etc.
Hence the question - how to reproduce it?
------------------------------------------------------------------------
[2006-09-25 23:20:32] madcoder at gmail dot com
It's pretty much the same as before...
(gdb) bt
#0 0x00002aae16a8de44 in ldap_count_values (vals=0x559cadc0)
at getvalues.c:153
#1 0x00005555555db423 in zif_ldap_get_entries (ht=1436331456,
return_value=0x5555559ca5c0, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1435796224)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068
#2 0x00005555556e4d20 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff942851d0) at zend_vm_execute.h:200
#3 0x00005555556ed112 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7fff942851d0) at zend_vm_execute.h:1640
#4 0x00005555556e43f9 in execute (op_array=0x5555559c7ae0)
at zend_vm_execute.h:92
#5 0x00005555556bf1d8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109
#6 0x0000555555670784 in php_execute_script
(primary_file=0x7fff94287790)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737
#7 0x00005555557756f4 in main (argc=3, argv=0x7fff942879c8)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093
The ldap code to reproduce the problem is the same as at the beginning
of this report... The difference between the code I posted originally
and the code that gave me the above output (showing "Count: 1"), is
this:
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$r) . "
entries\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
(that is, I added the Count line *after* the original post; everything
else is the same)
------------------------------------------------------------------------
[2006-09-25 21:56:59] [email]tony2001@php.net[/email]
What is the backtrace and how to reproduce it?
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
tony2001@php.net Guest
-
madcoder at gmail dot com #18 #38819 [Fbk->Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
No, I'm sorry, it's on a private LAN. A VPN account would be required
to gain access to the LAN, and corporate policy won't allow me to grant
you that. If you would like to contact me off-bugzilla, I might be able
to arrange a different way of accessing the server.
Previous Comments:
------------------------------------------------------------------------
[2006-09-26 09:38:39] [email]tony2001@php.net[/email]
Is it possible to get an account @ this server?
------------------------------------------------------------------------
[2006-09-26 09:36:37] madcoder at gmail dot com
Sorry for the extra post... I just tested with different values in
ldap_connect. For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with "ldap://" caused a segmentation fault
at line 2:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)
All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().
------------------------------------------------------------------------
[2006-09-26 09:29:47] madcoder at gmail dot com
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect("ldap://xyzdc02.xyz.acs-inc.com") or
die("ldap connect failed");
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], 'ldsearch@xyz.acs-inc.com', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$result) . "
entries\n";
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo "Done fetching\n";
print_r($info);
==============
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==============
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==============
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2>/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==============
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==============
/etc/openldap/ldap.conf:
BASE dc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==============
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$ ldapsearch -H ldap://xyz.acs-inc.com -D [email]ldsearch@xyz.acs-inc.com[/email] -w
some.Pass "(samaccountname=jhansche)" telephonenumber
# LDAPv3
# base <> with scope subtree
# filter: (samaccountname=jhansche)
# requesting: telephonenumber
# Joe Hansche, Administrators, elp.acs-inc.com
dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
telephoneNumber: 5492
==============
Unfortunately, I don't have another non-MS ldap server to try. It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct. It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries(). I hope that is more informative. If not, please
let me know what additional information I can give you that might help
track this problem down. If you'd like I can try adding some debugging
messages into the ldap portion of the php source to see where it might
be failing, and why?
Thanks, by the way. I appreciate your efforts.
------------------------------------------------------------------------
[2006-09-26 07:07:20] [email]tony2001@php.net[/email]
I intentionally said "how to reproduce it", not "what is the reproduce
code". It's clear to me that you're still using the same code, but this
code doesn't make much sense to me since I don't have your data, your
variables etc.
Hence the question - how to reproduce it?
------------------------------------------------------------------------
[2006-09-25 23:20:32] madcoder at gmail dot com
It's pretty much the same as before...
(gdb) bt
#0 0x00002aae16a8de44 in ldap_count_values (vals=0x559cadc0)
at getvalues.c:153
#1 0x00005555555db423 in zif_ldap_get_entries (ht=1436331456,
return_value=0x5555559ca5c0, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1435796224)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068
#2 0x00005555556e4d20 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff942851d0) at zend_vm_execute.h:200
#3 0x00005555556ed112 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7fff942851d0) at zend_vm_execute.h:1640
#4 0x00005555556e43f9 in execute (op_array=0x5555559c7ae0)
at zend_vm_execute.h:92
#5 0x00005555556bf1d8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109
#6 0x0000555555670784 in php_execute_script
(primary_file=0x7fff94287790)
at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737
#7 0x00005555557756f4 in main (argc=3, argv=0x7fff942879c8)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093
The ldap code to reproduce the problem is the same as at the beginning
of this report... The difference between the code I posted originally
and the code that gave me the above output (showing "Count: 1"), is
this:
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$r) . "
entries\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
(that is, I added the Count line *after* the original post; everything
else is the same)
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
-
tony2001@php.net #19 #38819 [Opn->Fbk]: segfault in ldap_get_entries()
ID: 38819
Updated by: [email]tony2001@php.net[/email]
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:
Ok, then please do the following:
1) get OpenLDAP sources from openldap.org (2.3.27 is the current stable
version)
2) get PHP 5.1.6 sources from php.net
3) build openldap from the sources with --enable-debug and
--prefix=/tmp/openldap
4) build PHP with ./configure --enable-debug --disable-all
--with-ldap=/tmp/openldap (no need to run make install, just use CLI
binary - ./sapi/cli/php).
5) try to reproduce it again and when/if it segfaults again type the
following commands in gdb console:
(gdb) f 0
(gdb) p vals
(gdb) p i
I'd also appreciate if you run it through valgrind and see if there are
any errors reported.
Previous Comments:
------------------------------------------------------------------------
[2006-09-26 09:48:51] madcoder at gmail dot com
No, I'm sorry, it's on a private LAN. A VPN account would be required
to gain access to the LAN, and corporate policy won't allow me to grant
you that. If you would like to contact me off-bugzilla, I might be able
to arrange a different way of accessing the server.
------------------------------------------------------------------------
[2006-09-26 09:38:39] [email]tony2001@php.net[/email]
Is it possible to get an account @ this server?
------------------------------------------------------------------------
[2006-09-26 09:36:37] madcoder at gmail dot com
Sorry for the extra post... I just tested with different values in
ldap_connect. For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with "ldap://" caused a segmentation fault
at line 2:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)
All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().
------------------------------------------------------------------------
[2006-09-26 09:29:47] madcoder at gmail dot com
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect("ldap://xyzdc02.xyz.acs-inc.com") or
die("ldap connect failed");
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], 'ldsearch@xyz.acs-inc.com', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$result) . "
entries\n";
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo "Done fetching\n";
print_r($info);
==============
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==============
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==============
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2>/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==============
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==============
/etc/openldap/ldap.conf:
BASE dc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==============
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$ ldapsearch -H ldap://xyz.acs-inc.com -D [email]ldsearch@xyz.acs-inc.com[/email] -w
some.Pass "(samaccountname=jhansche)" telephonenumber
# LDAPv3
# base <> with scope subtree
# filter: (samaccountname=jhansche)
# requesting: telephonenumber
# Joe Hansche, Administrators, elp.acs-inc.com
dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
telephoneNumber: 5492
==============
Unfortunately, I don't have another non-MS ldap server to try. It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct. It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries(). I hope that is more informative. If not, please
let me know what additional information I can give you that might help
track this problem down. If you'd like I can try adding some debugging
messages into the ldap portion of the php source to see where it might
be failing, and why?
Thanks, by the way. I appreciate your efforts.
------------------------------------------------------------------------
[2006-09-26 07:07:20] [email]tony2001@php.net[/email]
I intentionally said "how to reproduce it", not "what is the reproduce
code". It's clear to me that you're still using the same code, but this
code doesn't make much sense to me since I don't have your data, your
variables etc.
Hence the question - how to reproduce it?
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
tony2001@php.net Guest
-
madcoder at gmail dot com #20 #38819 [Fbk->Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
I do still get the segfault. This is the output from gdb:
(gdb) set args -e test.php
(gdb) run
Starting program: /root/php-5.1.6/sapi/cli/php -e test.php
done searching
Count: 1 entries
Program received signal SIGSEGV, Segmentation fault.
0x00002b92baa9a0ab in ldap_count_values (vals=0x55a07f90) at
getvalues.c:153
153 for ( i = 0; vals[i] != NULL; i++ )
(gdb) f 0
#0 0x00002b92baa9a0ab in ldap_count_values (vals=0x55a07f90) at
getvalues.c:153
153 for ( i = 0; vals[i] != NULL; i++ )
(gdb) p vals
$1 = (char **) 0x55a07f90
(gdb) p i
$2 = 0
If I'm understanding that correctly, it means the segfault is occuring
on the first iteration of the ldap_count_values() for loop. The first
thing I notice is that 'vals' is a 32-bit pointer. Would that have any
effect on the problem, considering this is a 64-bit system? Should I
have 32-bit emulation libraries installed for this? The only reason I
haven't installed the libraries so far is because none of the other
packages I've installed have specifically said that they are necessary.
Previous Comments:
------------------------------------------------------------------------
[2006-09-26 10:08:02] [email]tony2001@php.net[/email]
Ok, then please do the following:
1) get OpenLDAP sources from openldap.org (2.3.27 is the current stable
version)
2) get PHP 5.1.6 sources from php.net
3) build openldap from the sources with --enable-debug and
--prefix=/tmp/openldap
4) build PHP with ./configure --enable-debug --disable-all
--with-ldap=/tmp/openldap (no need to run make install, just use CLI
binary - ./sapi/cli/php).
5) try to reproduce it again and when/if it segfaults again type the
following commands in gdb console:
(gdb) f 0
(gdb) p vals
(gdb) p i
I'd also appreciate if you run it through valgrind and see if there are
any errors reported.
------------------------------------------------------------------------
[2006-09-26 09:48:51] madcoder at gmail dot com
No, I'm sorry, it's on a private LAN. A VPN account would be required
to gain access to the LAN, and corporate policy won't allow me to grant
you that. If you would like to contact me off-bugzilla, I might be able
to arrange a different way of accessing the server.
------------------------------------------------------------------------
[2006-09-26 09:38:39] [email]tony2001@php.net[/email]
Is it possible to get an account @ this server?
------------------------------------------------------------------------
[2006-09-26 09:36:37] madcoder at gmail dot com
Sorry for the extra post... I just tested with different values in
ldap_connect. For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with "ldap://" caused a segmentation fault
at line 2:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)
All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().
------------------------------------------------------------------------
[2006-09-26 09:29:47] madcoder at gmail dot com
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect("ldap://xyzdc02.xyz.acs-inc.com") or
die("ldap connect failed");
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], 'ldsearch@xyz.acs-inc.com', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$result) . "
entries\n";
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo "Done fetching\n";
print_r($info);
==============
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==============
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==============
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2>/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==============
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==============
/etc/openldap/ldap.conf:
BASE dc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==============
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$ ldapsearch -H ldap://xyz.acs-inc.com -D [email]ldsearch@xyz.acs-inc.com[/email] -w
some.Pass "(samaccountname=jhansche)" telephonenumber
# LDAPv3
# base <> with scope subtree
# filter: (samaccountname=jhansche)
# requesting: telephonenumber
# Joe Hansche, Administrators, elp.acs-inc.com
dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
telephoneNumber: 5492
==============
Unfortunately, I don't have another non-MS ldap server to try. It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct. It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries(). I hope that is more informative. If not, please
let me know what additional information I can give you that might help
track this problem down. If you'd like I can try adding some debugging
messages into the ldap portion of the php source to see where it might
be failing, and why?
Thanks, by the way. I appreciate your efforts.
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38819[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38819&edit=1[/url]
madcoder at gmail dot com Guest
Reply With QuoteSimilar Questions and Discussions
Posting Permissions
- You may not post new threads
- You may post replies
- You may not post attachments
- You may not edit your posts
