[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: PHP+LDAP not really works (clarifications)
Some clarifications are in order here.
The actual crash, seen from gdb, when running our PHP script without setting
protocol version to v3 explicitly, occurs here: (based on openldap 2.0.27)
(backtrace shown)
#0 0x4002796d in ldap_free_request (ld=0x8193ed8, lr=0x819a0b0) at request.c:565
#1 0x40021a47 in ldap_ld_free (ld=0x8193ed8, close=1, sctrls=0x0, cctrls=0x0) at unbind.c:76
#2 0x400217b0 in ldap_unbind_ext (ld=0x8193ed8, sctrls=0x0, cctrls=0x0) at unbind.c:43
#3 0x40021a7b in ldap_unbind_s (ld=0x8193ed8) at unbind.c:163
#4 0x0806248f in _close_ldap_link (rsrc=0x7465726f) at /home/frode/temp/php-4.3.0/ext/ldap/ldap.c:175
#5 0x0810bf6d in list_entry_destructor (ptr=0x81954e4) at /home/frode/temp/php-4.3.0/Zend/zend_list.c:177
#6 0x0810ac77 in zend_hash_del_key_or_index (ht=0x8159c60, arKey=0x0, nKeyLength=0, h=9, flag=1952805487) at /home/frode/temp/php-4.3.0/Zend/zend_hash.c:514
#7 0x0810bd8d in _zend_list_delete (id=9) at /home/frode/temp/php-4.3.0/Zend/zend_list.c:56
#8 0x08062a44 in zif_ldap_unbind (ht=1, return_value=0x8197cf4, this_ptr=0x0, return_value_used=0) at /home/frode/temp/php-4.3.0/ext/ldap/ldap.c:482
#9 0x081123e6 in execute (op_array=0x818b914) at /home/frode/temp/php-4.3.0/Zend/zend_execute.c:1596
#10 0x081078b7 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/frode/temp/php-4.3.0/Zend/zend.c:864
#11 0x080e72fc in php_execute_script (primary_file=0xbffff600) at /home/frode/temp/php-4.3.0/main/main.c:1573
#12 0x08115e81 in main (argc=2, argv=0xbffff694) at /home/frode/temp/php-4.3.0/sapi/cli/php_cli.c:746
(gdb)
request.c line 565 is:
for ( ttmplr = &lr->lr_parent->lr_child; *ttmplr && *ttmplr != lr; ttmplr = &(*ttmplr)->lr_refnext );
^
^
this is causing the segfault.
Dereferencing ttmplr here segfaults because the ttmplr points to
'0x7465726f'.
Note that the 'bt' output above shows that '0x7465726f' is parameter to #4,
the php close_ldap_link. I believe this is gdb backtracing the stack wrongly
because setting breakpoints on _close_ldap_link shows that the parameter is
not 0x7465726f but a valid pointer/parameter to this function when the
function is called. Probably something happens on the stack so gdb becomes
confused. But it is interesting anyway that the same (invalid,
actually-ASCII) pointer shows up this far up the stack
Converted to ASCII, this yields the string 'tero'. I don't have the memory
dump available, but that memory region contained a long string which looked
like the base DN if I recall correctly.
As I understand this rather condensed C code, ttmplr comes from
'lr->lr_parent->lr_child', but the problem is that what lr->lr_parent points
to is this block of ASCII string, so lr_child is obviously not an
LDAPRequest*.
By setting memory watchers on the address of lr->lr_parent, I noticed that this pointer
is overwritten at
#0 0x40222155 in mallopt () from /lib/libc.so.6
#1 0x40221172 in free () from /lib/libc.so.6
#2 0x4003e635 in ber_memfree (p=0x402c58c8) at memory.c:156
#3 0x400278d6 in ldap_free_request_int (ld=0x0, lr=0x8199bc8) at request.c:551
#4 0x40027986 in ldap_free_request (ld=0x8193ed8, lr=0x8199bc8) at request.c:573
#5 0x400279ac in ldap_free_request (ld=0x8193ed8, lr=0x8198c58) at request.c:571
#6 0x4001ab87 in try_read1msg (ld=0x8193ed8, msgid=2, all=1, sb=0x81941c0, lc=0x8197c48, result=0xbfffb870) at result.c:629
#7 0x4001a361 in wait4msg (ld=0x8193ed8, msgid=2, all=1, timeout=0x8197c48, result=0xbfffb870) at result.c:306
#8 0x4001cccb in ldap_search_s (ld=0x8193ed8, base=0x81ade2c "dc=testserver,dc=intra,dc=coretrek,dc=com", scope=2, filter=0x81956a4 "(&(objectCategory=person)(objectClass=user)(!(objectClass=computer)))", attrs=0x8197b94, attrsonly=0, res=0xbfffb870) at search.c:951
#9 0x08062de7 in php_ldap_do_search (ht=1076648136, return_value=0x8198404, this_ptr=0x0, return_value_used=1, scope=2) at /home/frode/temp/php-4.3.0/ext/ldap/ldap.c:728
#10 0x0806376d in zif_ldap_search (ht=6, return_value=0x8198404, this_ptr=0x0, return_value_used=1) at /home/frode/temp/php-4.3.0/ext/ldap/ldap.c:780
#11 0x081123e6 in execute (op_array=0x818ec64) at /home/frode/temp/php-4.3.0/Zend/zend_execute.c:1596
#12 0x081121b6 in execute (op_array=0x819501c) at /home/frode/temp/php-4.3.0/Zend/zend_execute.c:1640
#13 0x081121b6 in execute (op_array=0x818b914) at /home/frode/temp/php-4.3.0/Zend/zend_execute.c:1640
#14 0x081078b7 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/frode/temp/php-4.3.0/Zend/zend.c:864
#15 0x080e72fc in php_execute_script (primary_file=0xbffff600) at /home/frode/temp/php-4.3.0/main/main.c:1573
#16 0x08115e81 in main (argc=2, argv=0xbffff694) at /home/frode/temp/php-4.3.0/sapi/cli/php_cli.c:746
I'm unable to reproduce this error now because the script and its libraries
have been changed to avoid the error, so I can't be 100% sure that
these backtraces are correct, I've copied and pasted them from my
working text file while debugging.
Also note that I have doctored the base DN string in the output here
and in my previous mail, where the 'dc=testserver' part is actually
something else (should perhaps be kept confidential, I might believe.
Sorry about that.)
Anyway I hope this might be of interest.
With regards,
Frode E. Moe
Systems developer,
CoreTrek AS -- http://www.coretrek.com