Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 36478
Alias:
Product:
Component:
Status: RESOLVED
Resolution: TEST-REQUEST
Assigned To: Sparc Porters <sparc@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Alexey Bazhin <baz@irc.msk.ru>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
perl-io-sparc.patch Fixes IO problem commonly seen with perl-ldap module patch Jason Wever (RETIRED) 2004-05-25 06:21 0000 382 bytes Details | Diff
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 36478 depends on: Show dependency tree
Bug 36478 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2003-12-25 05:56 0000
#!/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"

------- Comment #1 From Jason Wever (RETIRED) 2003-12-25 16:47:50 0000 -------
Perl guys, any suggestions?

------- Comment #2 From Jason Wever (RETIRED) 2004-01-04 13:15:24 0000 -------
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.

------- Comment #3 From Jason Wever (RETIRED) 2004-02-21 18:32:03 0000 -------
Are you still having a problem with this?

------- Comment #4 From Alexey Bazhin 2004-02-22 00:56:16 0000 -------
yes, and upgrading perl to 5.8.2 didn't help.
can it be SMP related?

------- Comment #5 From Michael Cummings (RETIRED) 2004-02-28 05:49:48 0000 -------
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.

------- Comment #6 From Alexey Bazhin 2004-02-28 05:58:52 0000 -------
of course i tryed it...

moreover as i mentioned, according to slapd log, it doesn't even try to search

------- Comment #7 From Michael Cummings (RETIRED) 2004-02-28 18:58:59 0000 -------
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).

------- Comment #8 From Michael Cummings (RETIRED) 2004-02-29 02:01:07 0000 -------
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

------- Comment #9 From Jason Wever (RETIRED) 2004-03-02 18:15:21 0000 -------
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.

------- Comment #10 From Alexey Bazhin 2004-03-03 00:46:59 0000 -------
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_

------- Comment #11 From Jason Wever (RETIRED) 2004-03-03 03:40:59 0000 -------
I'm guessing you're using openldap here as your ldap server?  If so what
version?

------- Comment #12 From Alexey Bazhin 2004-03-03 03:47:44 0000 -------
i'm using openldap-2.1.26, and it surely works fine.

if it helps, i can give you shell on this box.

------- Comment #13 From Jason Wever (RETIRED) 2004-03-03 04:40:17 0000 -------
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

------- Comment #14 From Alexey Bazhin 2004-04-21 08:52:42 0000 -------
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.

------- Comment #15 From Alexey Bazhin 2004-04-24 00:50:56 0000 -------
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.

------- Comment #16 From Jason Wever (RETIRED) 2004-05-01 09:33:51 0000 -------
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

------- Comment #17 From Alexey Bazhin 2004-05-01 10:09:16 0000 -------
oops... yes it defined.
anyway seems there is a problem and my workaround solves it.

can anybody else confirm problem with script from #14 ?

------- Comment #18 From Jason Wever (RETIRED) 2004-05-22 17:44:20 0000 -------
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?

------- Comment #19 From Jason Wever (RETIRED) 2004-05-23 16:53:23 0000 -------
Patch works for me on 5.8.4 as well.

Perl dudes, do you have any upstream contacts we could confer with?

------- Comment #20 From Jason Wever (RETIRED) 2004-05-25 06:21:57 0000 -------
Created an attachment (id=32003) [details]
Fixes IO problem commonly seen with perl-ldap module

------- Comment #21 From Michael Cummings (RETIRED) 2004-06-20 08:07:29 0000 -------
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.

------- Comment #22 From Jason Wever (RETIRED) 2004-07-04 10:00:02 0000 -------
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?

------- Comment #23 From Michael Cummings (RETIRED) 2004-08-05 18:40:27 0000 -------
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.

------- Comment #24 From Jason Wever (RETIRED) 2004-08-06 15:48:19 0000 -------
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 :)

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug