#!/usr/bin/perl -w use Net::LDAP; $ldap = Net::LDAP->new('localhost') or die "cannot connect to ldap server\n"; $ldap->bind( 'cn=anon,dc=xxx,dc=ru', password => '12345' ); $answer = $ldap->search(base => 'ou=mail,dc=xxx,dc=ru',filter => 'mail=xxx@xxx.ru'); print $answer->count; $ldap->unbind; when i run this script on my gentoo/sparc i get error: Can't call method "count" without a package or object reference at ./ld.pl line 9, <DATA> line 283. in slapd log i find that it binds successfully but doesn't try to search. on gentoo/x86 this script works fine... perl-5.8.0-r12, perl-ldap-0.29 Reproducible: Always Steps to Reproduce: 1. emerge perl-ldap 2. try to run my script(of course with your dn, filter, etc...) 3. Actual Results: getting error Expected Results: number of entries on ldap server emerge info Portage 2.0.49-r15 (default-sparc64-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.4.22-sparc) ================================================================= System uname: 2.4.22-sparc sparc64 sun4u Gentoo Base System version 1.4.3.10 ACCEPT_KEYWORDS="sparc" AUTOCLEAN="yes" CFLAGS="-mcpu=ultrasparc -O2 -pipe" CHOST="sparc-unknown-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-mcpu=ultrasparc -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="userpriv usersandbox -ccache -sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="sparc apache2 berkdb gd imap ldap maildir mysql ncurses nls pam perl png python readline sasl ssl xml xml2 zlib"
Perl guys, any suggestions?
Ok, I've sort of replicated this on stable. I setup an openldap server with some info, and revised your script below to poll information from it in a similar fashion. Now the first time I run the script, I get the error you mentioned. However after that it works fine. It almost seems like perl is taking to long to load the module before it continues. I could not replicate this using ~sparc, but that also uses perl-5.8.2 as well.
Are you still having a problem with this?
yes, and upgrading perl to 5.8.2 didn't help. can it be SMP related?
I have to get my sparc back up, and will test this on x86 as well, but in taking a look at the source of the module, I see mentions of $object->count in the pod areas, but nowhere that the author actually provides a method to return said count. Have you tried this the old fashioned way to confirm that you are getting results back (return as an array and work on the size of the array instead)? That and looking at CPAN, we are pretty much out of date on this module anyway. Will post a .30 (~arched) ebuild shortly for it.
of course i tryed it... moreover as i mentioned, according to slapd log, it doesn't even try to search
On my sparc (64) with perl 5.8.0, this module worked fine. Will let you know if this status changes after I upgrade to 5.8.2 (box has been out of circulation for a few weeks).
I *still* can't duplicate this bug. On my sparc, everything runs fine even after upgrading to perl 5.8.2. cpu : TI UltraSparc IIi (Sabre) fpu : UltraSparc IIi integrated FPU promlib : Version 3 Revision 25 prom : 3.25.1 type : sun4u ncpus probed : 1 ncpus active : 1 Cpu0Bogo : 719.25 Cpu0ClkTck : 0000000015752a00 MMU Type : Spitfire State: CPU0: online
I tried replicating again today with an SMP sparcstation 20, sparcstation 4 and a blade 100 ultrasparc but was unable to. I can try SMP ultrasparc this weekend if no one beats me to it. I was using 0.31 during this testing.
trying 0.31... something changed, it doesn't return error, but still doesn't work. i tryed to run this script many times and about one time per 10 it works... in slapd log i see it connects, binds successfully, but trys to search only this one time per 10. if i add $answer->code && die $answer->error; after searching, script returns this: iron work # ./ld.pl Can't contact LDAP server at ./ld.pl line 9, <DATA> line 283. iron work # ./ld.pl Can't contact LDAP server at ./ld.pl line 9, <DATA> line 283. iron work # ./ld.pl Can't contact LDAP server at ./ld.pl line 9, <DATA> line 283. iron work # ./ld.pl Can't contact LDAP server at ./ld.pl line 9, <DATA> line 283. iron work # ./ld.pl I/O Error Resource temporarily unavailable at ./ld.pl line 9, <DATA> line 283. iron work # ./ld.pl Can't contact LDAP server at ./ld.pl line 9, <DATA> line 283. iron work # ./ld.pl Can't contact LDAP server at ./ld.pl line 9, <DATA> line 283. in slapd log: Mar 3 11:30:10 [slapd] conn=33821 fd=35 ACCEPT from IP=127.0.0.1:47751 (IP=127.0.0.1:389)_ Mar 3 11:30:10 [slapd] conn=33821 op=0 BIND dn="cn=anon,ou=mail,dc=xxx,dc=ru" method=128_ Mar 3 11:30:10 [slapd] conn=33821 op=0 BIND dn="cn=anon,ou=mail,dc=xxx,dc=ru" mech=SIMPLE ssf=0_ Mar 3 11:30:10 [slapd] conn=33821 op=0 RESULT tag=97 err=0 text=_ Mar 3 11:30:10 [slapd] conn=33821 fd=35 closed_ Mar 3 11:30:11 [slapd] conn=33822 fd=35 ACCEPT from IP=127.0.0.1:47752 (IP=127.0.0.1:389)_ Mar 3 11:30:11 [slapd] conn=33822 op=0 BIND dn="cn=anon,ou=mail,dc=xxx,dc=ru" method=128_ Mar 3 11:30:11 [slapd] conn=33822 op=0 BIND dn="cn=anon,ou=mail,dc=xxx,dc=ru" mech=SIMPLE ssf=0_ Mar 3 11:30:11 [slapd] conn=33822 op=0 RESULT tag=97 err=0 text=_ Mar 3 11:30:11 [slapd] conn=33822 fd=35 closed_ Mar 3 11:30:13 [slapd] conn=33823 fd=35 ACCEPT from IP=127.0.0.1:47753 (IP=127.0.0.1:389)_ Mar 3 11:30:13 [slapd] conn=33823 op=0 BIND dn="cn=anon,ou=mail,dc=xxx,dc=ru" method=128_ Mar 3 11:30:13 [slapd] conn=33823 op=0 BIND dn="cn=anon,ou=mail,dc=xxx,dc=ru" mech=SIMPLE ssf=0_ Mar 3 11:30:13 [slapd] conn=33823 op=0 RESULT tag=97 err=0 text=_ Mar 3 11:30:13 [slapd] conn=33823 op=1 SRCH base="ou=mail,dc=xxx,dc=ru" scope=2 filter="(mail=xxx@xxx.ru)"_ Mar 3 11:30:13 [slapd] conn=33823 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=_ Mar 3 11:30:13 [slapd] conn=33823 fd=35 closed_ Mar 3 11:30:16 [slapd] conn=33824 fd=35 ACCEPT from IP=127.0.0.1:47754 (IP=127.0.0.1:389)_ Mar 3 11:30:16 [slapd] conn=33824 op=0 BIND dn="cn=anon,ou=mail,dc=xxx,dc=ru" method=128_ Mar 3 11:30:16 [slapd] conn=33824 op=0 BIND dn="cn=anon,ou=mail,dc=xxx,dc=ru" mech=SIMPLE ssf=0_ Mar 3 11:30:16 [slapd] conn=33824 op=0 RESULT tag=97 err=0 text=_ Mar 3 11:30:16 [slapd] conn=33824 fd=35 closed_
I'm guessing you're using openldap here as your ldap server? If so what version?
i'm using openldap-2.1.26, and it surely works fine. if it helps, i can give you shell on this box.
Hrm, might resort to that if we have to. Roughly how many entries are in the DN we're searching through? Additionally, if I add your change from comment #10 into my script, I now get the following error; I/O Error Resource temporarily unavailable at ./bug36478.pl line 9, <DATA> line 283
i had tryed to compare output of 'strace ./ld.pl' on sparc and x86 boxes and found that bug not in perl-ldap, but in perl's IO::Socket::INET. differences in strace(- on sparc, + on x86): socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 -ioctl(3, TCSETAF or SNDCTL_TMR_SELECT, 0xeffff2c8) = -1 EINVAL (Invalid argument) -_llseek(3, 0, 0xeffff310, SEEK_CUR) = -1 ESPIPE (Illegal seek) -ioctl(3, TCSETAF or SNDCTL_TMR_SELECT, 0xeffff2c8) = -1 EINVAL (Invalid argument) -_llseek(3, 0, 0xeffff310, SEEK_CUR) = -1 ESPIPE (Illegal seek) -nfssvc(0x3) = 0 -nfssvc(0x3) = 2 -nfssvc(0x3) = 0 +ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffff1a8) = -1 EINVAL (Invalid argument) +_llseek(3, 0, 0xbffff1e0, SEEK_CUR) = -1 ESPIPE (Illegal seek) +ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffff1a8) = -1 EINVAL (Invalid argument) +_llseek(3, 0, 0xbffff1e0, SEEK_CUR) = -1 ESPIPE (Illegal seek) +fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 +fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) +fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("xxx.xxx.xxx.xxx")}, 16) = -1 EINPROGRESS (Operation now in progress) and write(3, "06\2\1\1`1\2\1\3\4!cn=anon,ou=mail,dc=m"..., 56) = 56 -read(3, 0x3e7e70, 2) = -1 EAGAIN (Resource temporarily unavailable) -close(3) = 0 +read(3, "0\f", 2) = 2 +read(3, "\2\1\1a\7\n\1\0\4\0\4\0", 12) = 12 i wrote this simple script, it works when no timeout passed(blocking? io) and does'n work with timeout (non-blocking? io). #!/usr/bin/perl -w use IO::Socket::INET; $sock = IO::Socket::INET->new(PeerAddr => 'www.ya.ru', #PeerPort => '80', Proto => 'tcp', Timeout => 120) or return undef; PeerPort => '80', Proto => 'tcp') or return undef; $sock->write("GET / HTTP/1.0\r\n\r\n"); $sock->read($data,1024); print "$data\n"; P.S. i recently installed ~sparc gentoo on sun blade 100 and it has same bug.
Seems i totally understand problem. In file perl-5.8.3/ext/IO/IO.xs behaviour of function io_blocking() depends on existence and value of O_NDELAY constant which defined in /usr/include/asm-sparc/fcntl.h and in /usr/include/bits/fcntl.h and undefined in /usr/include/asm-sparc64/fcntl.h. And /usr/include/fcntl.h includes /usr/include/bits/fcntl.h. I have patched perl's IO.xs (undefine O_NDELAY) and now it works fine. So there is confusion with header files or bug in perl's IO.xs.
Which version of linux-headers do you have installed? In looking on a sparc and ~sparc system here, both of them have a definition for O_NDELAY in /usr/include/asm-sparc64/fcntl.h
oops... yes it defined. anyway seems there is a problem and my workaround solves it. can anybody else confirm problem with script from #14 ?
OK, I can now replicate the problem consistantly. I've tested your fix against perl-5.8.2-r1 and it works fine. I'm going to try 5.8.4 today or tomorrow. It looks like the problem here might be that on x86, O_NDELAY and O_NONBLOCK are the same value, where on SPARCs they are not, and that's where your fix comes in. Perl guys, do you have any contacts upstream that you recommend we talk to about making sure this is the right fix and getting it incorporated?
Patch works for me on 5.8.4 as well. Perl dudes, do you have any upstream contacts we could confer with?
Created attachment 32003 [details, diff] Fixes IO problem commonly seen with perl-ldap module
The only "contact" that I have is rt.perl.org - basically perl's bugzilla engine. I can submit this if you'd like, or you can, either way let me know.
The upstream bug for this is http://rt.perl.org/rt3/Ticket/Display.html?id=29082 Perl dudes, any issues with applying the attached patch for SPARC and resolving upstream?
sorry weeve, i think i'm one of the few that sorts through the perl bugs as time permits (mostly for volume) - no problem so long as you sparc? ( patch ) it.
I talked with rac about this at LWE and he commited a patch for it, so I think we're all set. Thanks for keeping up with us on it :)
