#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 +Operating System: 2.6.17-gentoo linux amd64 PHP Version: 5.1.6 New Comment: For reference, I'm cross-posting a bug report I've opened with OpenLDAP (ITS# 4690) in case they can provide any further information: http://www.openldap.org/its/index.cgi/Incoming?id=4690;expression=ldap_get_values;statetype=-1 Previous Comments: [2006-09-30 03:37:13] madcoder at gmail dot com Any other ideas? This problem is kind of a blocker for me right now... I still don't understand why it works fine inside valgrind, but it segfaults on its own and inside gdb. I know it's segfaulting because of the message Cannot access memory at address 0x55a0bfe0, so the for loop checking vals[i] obviously fails. But what steps can I take to debug this further? It could be a problem in openldap, since the line in php's ldap.c just before it calls the openldap function 'ldap_count_values' is ldap_get_values(), which is what is returning the memory address of 0x55a0bfe0. But if it were in fact a problem with openldap, would the cli ldapsearch fail as well? [2006-09-26 11:08:50] madcoder at gmail dot com I've tried, but the program doesn't segfault, so it exits normally. I'm not very experienced with gdb, so I'm not sure how to give it a breakpoint of ldap_count_values (I tried 'break ldap_count_values' and 'break ldap_count_values()', and it doesn't break). It does still return the information as expected. [2006-09-26 10:57:53] [EMAIL PROTECTED] Is it possible to perform the same actions using ldapsearch utility in console? [2006-09-26 10:43:23] madcoder at gmail dot com Program received signal SIGSEGV, Segmentation fault. 0x2af2b2e5f0ab 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 0 $2 = 0 (gdb) p vals[0] Cannot access memory at address 0x55a07f90 The memory address is the same. Can't access memory? It seems like its a problem in php's ldap_get_entries still (or further up the stack) because ldap_count_entries(), which calls the same function, works fine and returns '1'. [2006-09-26 10:38:38] [EMAIL PROTECTED] And what is in vals[0] ? (gdb) p vals[0] The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/38819 -- Edit this bug report at http://bugs.php.net/?id=38819edit=1
#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: Any other ideas? This problem is kind of a blocker for me right now... I still don't understand why it works fine inside valgrind, but it segfaults on its own and inside gdb. I know it's segfaulting because of the message Cannot access memory at address 0x55a0bfe0, so the for loop checking vals[i] obviously fails. But what steps can I take to debug this further? It could be a problem in openldap, since the line in php's ldap.c just before it calls the openldap function 'ldap_count_values' is ldap_get_values(), which is what is returning the memory address of 0x55a0bfe0. But if it were in fact a problem with openldap, would the cli ldapsearch fail as well? Previous Comments: [2006-09-26 11:08:50] madcoder at gmail dot com I've tried, but the program doesn't segfault, so it exits normally. I'm not very experienced with gdb, so I'm not sure how to give it a breakpoint of ldap_count_values (I tried 'break ldap_count_values' and 'break ldap_count_values()', and it doesn't break). It does still return the information as expected. [2006-09-26 10:57:53] [EMAIL PROTECTED] Is it possible to perform the same actions using ldapsearch utility in console? [2006-09-26 10:43:23] madcoder at gmail dot com Program received signal SIGSEGV, Segmentation fault. 0x2af2b2e5f0ab 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 0 $2 = 0 (gdb) p vals[0] Cannot access memory at address 0x55a07f90 The memory address is the same. Can't access memory? It seems like its a problem in php's ldap_get_entries still (or further up the stack) because ldap_count_entries(), which calls the same function, works fine and returns '1'. [2006-09-26 10:38:38] [EMAIL PROTECTED] And what is in vals[0] ? (gdb) p vals[0] [2006-09-26 10:28:55] madcoder at gmail dot com 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. 0x2b92baa9a0ab in ldap_count_values (vals=0x55a07f90) at getvalues.c:153 153 for ( i = 0; vals[i] != NULL; i++ ) (gdb) f 0 #0 0x2b92baa9a0ab 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/38819 -- Edit this bug report at http://bugs.php.net/?id=38819edit=1
#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'], '[EMAIL PROTECTED]', '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:
BASEdc=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 PROTECTED] -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 PROTECTED]
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
#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: http://pastebin.com/790150 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 PROTECTED] Doesn't look like PHP problem to me. Could you plz also see if `valgrind /usr/bin/php test.php` show you something interesting? Please put valgrind's log somewhere and paste the URL here. [2006-09-18 23:38:16] madcoder at gmail dot com Sorry for the delay (I had to fix an error with gdb not generating backtraces on AMD64...) Here's the backtrace: - (gdb) run Starting program: /usr/bin/php -e test.php [Thread debugging using libthread_db enabled] [New Thread 47773184727840 (LWP 28424)] done searching Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47773184727840 (LWP 28424)] 0x2b730d78de44 in ldap_count_values (vals=0x55e99220) at getvalues.c:153 153 getvalues.c: No such file or directory. in getvalues.c - (gdb) bt #0 0x2b730d78de44 in ldap_count_values (vals=0x55e99220) at getvalues.c:153 #1 0x556a25c0 in zif_ldap_get_entries (ht=1441370656, return_value=0x55e987a8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1438266616, tsrm_ls=0x55e9cc60) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068 #2 0x55890d35 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9f13efb0, tsrm_ls=0x55ba4450) at zend_vm_execute.h:200 #3 0x55899c6a in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fff9f13efb0, tsrm_ls=0x55ba4450) at zend_vm_execute.h:1640 #4 0x5589039b in execute (op_array=0x55e96ad8, tsrm_ls=0x55ba4450) at zend_vm_execute.h:92 #5 0x55868a42 in zend_execute_scripts (type=8, tsrm_ls=0x55ba4450, retval=0x0, file_count=3) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109 #6 0x5580f825 in php_execute_script (primary_file=0x7fff9f1415d0, tsrm_ls=0x55ba4450) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737 #7 0x55939484 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 PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a
#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: http://www.framewerk.org/~madcoder/vgrind.log Previous Comments: [2006-09-19 19:49:48] madcoder at gmail dot com I ran it through valgrind with --leak-check=full -v --show-reachable=yes, and copied the output here: http://pastebin.com/790150 [2006-09-19 19:39:47] madcoder at gmail dot com Now that's interesting... It runs fine with valgrind. Here are the ERROR SUMMARY and LEAK SUMMARY sections: ==7964== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 93 from 1) ==7964== malloc/free: in use at exit: 71,780 bytes in 1,268 blocks. ==7964== malloc/free: 38,082 allocs, 36,814 frees, 3,611,397 bytes allocated. ==7964== For counts of detected errors, rerun with: -v ==7964== searching for pointers to 1,268 not-freed blocks. ==7964== checked 2,962,048 bytes. ==7964== LEAK SUMMARY: ==7964==definitely lost: 32,841 bytes in 4 blocks. ==7964== possibly lost: 0 bytes in 0 blocks. ==7964==still reachable: 38,939 bytes in 1,264 blocks. ==7964== suppressed: 0 bytes in 0 blocks. ==7964== Use --leak-check=full to see details of leaked memory. Running with --leak-check=full, I get the following: ==7968== 73 (32 direct, 41 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 8 ==7968==at 0x4A1AB8E: malloc (vg_replace_malloc.c:149) ==7968==by 0x64825AB: tds_alloc_context (in /usr/lib64/libsybdb.so.4.0) ==7968==by 0x6472C3F: dbinit (in /usr/lib64/libsybdb.so.4.0) ==7968==by 0x1595DC: zm_startup_mssql (php_mssql.c:301) ==7968==by 0x31B325: zend_startup_module_ex (zend_API.c:1397) ==7968==by 0x3224A3: zend_hash_apply (zend_hash.c:666) ==7968==by 0x31B4EE: zend_startup_modules (zend_API.c:1444) ==7968==by 0x2BB230: php_module_startup (main.c:1557) ==7968==by 0x3E460A: main (php_cli.c:681) ==7968== ==7968== 32,768 bytes in 1 blocks are definitely lost in loss record 8 of 8 ==7968==at 0x4A1C10D: calloc (vg_replace_malloc.c:279) ==7968==by 0x6472C16: dbinit (in /usr/lib64/libsybdb.so.4.0) ==7968==by 0x1595DC: zm_startup_mssql (php_mssql.c:301) ==7968==by 0x31B325: zend_startup_module_ex (zend_API.c:1397) ==7968==by 0x3224A3: zend_hash_apply (zend_hash.c:666) ==7968==by 0x31B4EE: zend_startup_modules (zend_API.c:1444) ==7968==by 0x2BB230: php_module_startup (main.c:1557) ==7968==by 0x3E460A: main (php_cli.c:681) [2006-09-19 06:24:54] [EMAIL PROTECTED] Doesn't look like PHP problem to me. Could you plz also see if `valgrind /usr/bin/php test.php` show you something interesting? Please put valgrind's log somewhere and paste the URL here. [2006-09-18 23:38:16] madcoder at gmail dot com Sorry for the delay (I had to fix an error with gdb not generating backtraces on AMD64...) Here's the backtrace: - (gdb) run Starting program: /usr/bin/php -e test.php [Thread debugging using libthread_db enabled] [New Thread 47773184727840 (LWP 28424)] done searching Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47773184727840 (LWP 28424)] 0x2b730d78de44 in ldap_count_values (vals=0x55e99220) at getvalues.c:153 153 getvalues.c: No such file or directory. in getvalues.c - (gdb) bt #0 0x2b730d78de44 in ldap_count_values (vals=0x55e99220) at getvalues.c:153 #1 0x556a25c0 in zif_ldap_get_entries (ht=1441370656, return_value=0x55e987a8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1438266616, tsrm_ls=0x55e9cc60) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068 #2 0x55890d35 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9f13efb0, tsrm_ls=0x55ba4450) at zend_vm_execute.h:200 #3 0x55899c6a in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fff9f13efb0, tsrm_ls=0x55ba4450) at zend_vm_execute.h:1640 #4 0x5589039b in execute (op_array=0x55e96ad8, tsrm_ls=0x55ba4450) at zend_vm_execute.h:92 #5 0x55868a42 in zend_execute_scripts (type=8, tsrm_ls=0x55ba4450, retval=0x0, file_count=3) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109 #6 0x5580f825 in php_execute_script (primary_file=0x7fff9f1415d0, tsrm_ls=0x55ba4450) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737 #7 0x55939484 in main (argc=3, argv=0x7fff9f141888) at
