"Matt Ross" <[EMAIL PROTECTED]> writes: > > I had a look at bugzilla but couldn't make head or tail of it.
It's not that bad; really. Give it another shot! :-) > I suspect this is a problem to do with the way I am using the SDK as I am > starting to see this blocking problem in most of the LDAP functions. At > first I thought it was related to a timeout issue with the server as > primarily this freezing only occurred after I left the GUI running idle > overnight (still bound as a user to the server). Now I'm seeing that it > (randomly) happens even a few seconds after binding to the server, so it > cannot be a timeout issue. Sometimes when I first run my GUI it freezes > immediately after I enter my username and password (which it uses to bind). > When using ldap_search_ext_s it tends to freeze after the GUI has been > running for a few hours. When using ldap_compare_ext_s it freezes more than > 50% of the time! Well, it's worth keeping in mind that the _s versions of the various functions are all synchronous, meaning that they will not return until the operation in question has completed (or timed out), and if there are network problems (eg LDAP or DNS server reachability or responsiveness problems), this could be a very long time. Switching away from the _s functions is a step in the right direction. For true asynchronicity, though, you would also need to use LDAP_OPT_ASYNC_CONNECT, and that code is not quite ready for prime time just yet. It still has some problems which are in the process of being worked out (see bugs 79509 and 140182 in particular). > My sloppy coding meant that I was not using the respective LDAP memory > freeing functions until recently for some of the variables. I have since > gone through my code tidying up the memory allocation in the hope it might > be affecting the program. As many of my calls to the SDK functions are in > loops (i.e. I'm searching/modifying a list of user objects) I am now freeing > the respective variables before the next iteration in the loop. It has not > affected the freezing at all. This is more or less what I would expect. > The only other thing that might be odd about my setup is that I'm using > Borland C++ Builder under Windows. This means I had to use 'impdef' to > convert the MS Visual C++ compatible libraries to ones that the Borland > compiler can use. I can't guess what effect, if any, this would have. > Am I the only person getting these kinds of problem? I'm not sure. > BTW, this is 5.08 of the SDK, is this the latest? Well, the mozilla.org SDK doesn't really have a version number attached to it at the moment, other than "version 5", because it doesn't really have releases targeted directly at end users. 5.08 sounds like the Sun version of the SDK, and I _think_ that's their latest, but I'm not sure. One possible way to debug this is to check out the mozilla.org SDK sources from the trunk, and build them yourself with debugging turned on... Dan
