ID: 38819 Updated by: [EMAIL PROTECTED] Reported By: madcoder at gmail dot com -Status: Closed +Status: Feedback Bug Type: LDAP related Operating System: 2.6.17-gentoo linux amd64 PHP Version: 5.1.6 New Comment:
>works *without* any segfaults. Ok, great. Please don't close the report until the issue is resolved in PHP. Could you please also ask OpenLDAP developers if this flag would affect anything else? I.e. if it didn't segfault before, could this flag add any problems? If no, I'll add it to the config.m4, so it'll be defined in all builds. >But wouldn't it be beneficial to take the OpenLDAP >developers' advice, and rewrite this so-called >"deprecated" use of OpenLDAP? Sure it would be. And we would gladly accept their help. But the current situation is that ext/ldap maintainer is not active for a long time and nobody really interested in ldap. If you can help us with that - you're welcome. Also, it would be good if OpenLDAP developers keep the backward compatibility, since we cannot rely on users using the most latest-and-greatest OpenLDAP version and rewrite ext/ldap each time they change the API. Previous Comments: ------------------------------------------------------------------------ [2006-10-02 11:32:34] madcoder at gmail dot com Sorry, it appears I added that in the wrong place. I added it to the Makefile for ext/ldap, and it compiled, and works *without* any segfaults. I don't want to sound rude, so please don't take this the wrong way, ... But wouldn't it be beneficial to take the OpenLDAP developers' advice, and rewrite this so-called "deprecated" use of OpenLDAP? It appears to only occur on certain machines, perhaps even only on certain amd64 machines, but it is still rather annoying if no one is sure what causes it, and it takes 2 weeks (or longer, in my case, since I've been having this problem long before I posted to any trackers) to get an answer from someone. Thanks again for your help, and patience while working through this problem. ------------------------------------------------------------------------ [2006-10-02 11:20:50] madcoder at gmail dot com In ext/ldap/config.m4, I changed the following to add the flag you mentioned: > CPPFLAGS="$CPPFLAGS -I$LDAP_INCDIR -DLDAP_DEPRECATED=1" Then reconfigured and rebuilt php. I'm not sure if I did that properly, but from what information I found about the flag, that is appropriate. And I *do* still get the segfault. Should I try a distclean as well? Or should I recompile OpenLDAP first (with or without that flag)? ------------------------------------------------------------------------ [2006-10-02 09:20:13] [EMAIL PROTECTED] So does it work for you if you add that magical -DLDAP_DEPRECATED=1 ? ------------------------------------------------------------------------ [2006-10-01 08:16:08] madcoder at gmail dot com 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 ------------------------------------------------------------------------ [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? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/38819 -- Edit this bug report at http://bugs.php.net/?id=38819&edit=1
