This server is frozen, and ldapsearch crashes:
[root@etoile main]# ldapsearch -x ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)' failed. Abandon
This is openldap 2.4.15 client, with this specific configuration: TLS_CACERTDIR /etc/pki/tls/rootcerts TLS_REQCERT demand NETWORK_TIMEOUT 2 TIMEOUT 2 TIMELIMIT 2
On my own host, with 2.4.17 and no configuration, the client just hangs indefinitly.
I'm joining the network capture.
Guillaume Rousse wrote:
This server is frozen, and ldapsearch crashes:
[root@etoile main]# ldapsearch -x ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)' failed. Abandon
This is openldap 2.4.15 client, with this specific configuration: TLS_CACERTDIR /etc/pki/tls/rootcerts TLS_REQCERT demand NETWORK_TIMEOUT 2 TIMEOUT 2 TIMELIMIT 2
On my own host, with 2.4.17 and no configuration, the client just hangs indefinitly.
I'm joining the network capture.
Not sure what's the point of your email. Whatever 2.4.15 did is uninteresting since it no longer occurs in 2.4.17. Your packet trace shows a few TCP retries, so the remote server's network stack is not responding, and you already said "this server is frozen." Naturally the client hangs waiting for a reply, if you didn't specify any timeouts of your own.
Howard Chu a écrit :
Guillaume Rousse wrote:
This server is frozen, and ldapsearch crashes:
[root@etoile main]# ldapsearch -x ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)' failed. Abandon
This is openldap 2.4.15 client, with this specific configuration: TLS_CACERTDIR /etc/pki/tls/rootcerts TLS_REQCERT demand NETWORK_TIMEOUT 2 TIMEOUT 2 TIMELIMIT 2
On my own host, with 2.4.17 and no configuration, the client just hangs indefinitly.
I'm joining the network capture.
Not sure what's the point of your email. Whatever 2.4.15 did is uninteresting since it no longer occurs in 2.4.17.
I forgot to test with the same configuration, unfortunatly. Apparently, ldapsearch options only allows to set timelimit with -l switch, not the two other ones.
Your packet trace shows a few TCP retries, so the remote server's network stack is not responding, and you already said "this server is frozen." Naturally the client hangs waiting for a reply, if you didn't specify any timeouts of your own.
Well, my point was: - the client should die gracefully, instead of throwing an assertion failure - it prevents switching to the second server listed in its configuration
As 2.4.17 and 2.4.16 changelog doesn't show anything related, I guess the pb is still there.
Michael Ströder a écrit :
Guillaume Rousse wrote:
As 2.4.17 and 2.4.16 changelog doesn't show anything related, I guess the pb is still there.
Please do not guess. You should test.
Unfortunatly, I have no way to reproduce the problem, and I couldn't afford to let the ldap server in a bad mood. Isn't there any way to replay answer parsing from the network capture ?
On Sat, 22 Aug 2009, Guillaume Rousse wrote:
to let the ldap server in a bad mood. Isn't there any way to replay answer parsing from the network capture ?
Sometimes it's not that easy. A lot of things are timing-dependent, or need a particular memory access (such that the prior contents and/or layout of memory would be meaningful for a reproduction), or load-dependent, or any one of a number of possibilities that mean that the second time around may not produce the same results. And this all sets aside the fact that true microtime-precision network replay isn't exactly trivial.
Not to say you shouldn't try to work backwards...really, IMO, there's nothing better than being able to show an issue using just the test suite...but sometimes a clean reproduction just isn't plausible.
Howard Chu a écrit :
Not sure what's the point of your email. Whatever 2.4.15 did is uninteresting since it no longer occurs in 2.4.17. Your packet trace shows a few TCP retries, so the remote server's network stack is not responding, and you already said "this server is frozen." Naturally the client hangs waiting for a reply, if you didn't specify any timeouts of your own.
The problem just surfaced again. This time, I tested with 2.4.17 and the same client configuration (the various limits settings), and reproduced the problem. That's ITS #6282.
openldap-software@openldap.org
-
Aaron Richton -
Guillaume Rousse -
Howard Chu -
Michael Ströder