More information. Running the scenario under DProf, I get: Total Elapsed Time = -40.7223 Seconds User+System Time = 0 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 0.00 14.29 14.290 973341 0.0000 0.0000 Net::SSLeay::write_partial 0.00 8.807 0.000 3 2.9356 0.0000 Net::SSLeay::ssl_write_all 0.00 7.780 10.132 973341 0.0000 0.0000 Net::SSLeay::print_errs 0.00 2.865 2.865 1 2.8650 2.8650 Net::SSLeay::connect 0.00 2.352 2.352 973341 0.0000 0.0000 Net::SSLeay::ERR_get_error 0.00 0.585 0.630 267 0.0022 0.0024 Convert::ASN1::asn_dump 0.00 0.330 0.330 640 0.0005 0.0005 IO::Socket::INET::_sock_info 0.00 0.263 3.847 320 0.0008 0.0120 IO::Socket::INET::configure 0.00 0.226 0.360 3168 0.0001 0.0001 Convert::ASN1::_decode
This looks like the failure is in the SSLeay module. Anybody else have experience with this issue on this list? Thanks -- -- Rick > -----Original Message----- > From: Rick Cobb [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 26, 2004 10:02 PM > To: [EMAIL PROTECTED] > Subject: Hard loop soon after a connection failure in .31? > > > I'm running into a situation that I'm finding hard to track down. > > I've got a daemon-like (long-lived, but not detached) process > that does a lot of LDAP queries & updates on request from > another system. I've carefully coded it to catch > LDAP_SERVER_DOWN, connection fail, and a couple of other > error codes, at which time it unbinds and disconnects, and > then later retries the connection. > > Most of our testing of this daemon is done from Windows XP > laptops, over wireless links. > > When we have a connection, and then lose physically lose a > link and then restore it (e.g., pull out a wired ethernet > cable, lose our wireless connectivity), we can execute one or > two LDAP commands (add/update/modify/search), and then we hit > a wall: we issue a command (I see the sent information from > turning debug on), and then the daemon sits in a hard loop > chewing up all CPU. This seems to happen right after Windows > has decided that DHCP conversations are complete.g > > All of our LDAP calls are synchronous; this is the 'quick & > dirty' version before going through and coding with callbacks. > > We build our own Perl from sources, but haven't compiled for > debugging, so I can't see exactly which Perl routine is going > haywire. However, it's pretty clear from tracing it through > in the Windows debugger that the loop is doing a > malloc/memcpy sequence over and over again as part of what's going on. > > Any insight? Known bugs? Should I keep looking deeper at > this problem, or re-code to use callbacks and believe it'll > just go away? > > Thanks -- > -- Rick Cobb >
