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
