Re: [Exim] Exim 3.34 assertion failure--LDAP related

Top Page
Delete this message
Reply to this message
Author: John W Baxter
Date:  
To: exim-users
Subject: Re: [Exim] Exim 3.34 assertion failure--LDAP related
At 8:49 +0000 3/12/2002, Philip Hazel wrote:
>On Mon, 11 Mar 2002, John W Baxter wrote:
>
>> Got:
>> exim: error.c:221: ldap_parse_result: Assertion `r != ((void *)0)' failed.
>
>There is no file called error.c in the Exim distribution. My guess is
>that it is part of LDAP. But Exim doesn't call ldap_parse_result, so
>that must be some internal call from some other part of LDAP.
>
>> [root@xxx /root]# exiwhat
>> sh: kill: (13306) - No such pid
>> sh: kill: (13320) - No such pid
>> exim: error.c:221: ldap_parse_result: Assertion `r != ((void *)0)' failed.
>>    869 daemon: -q15m, listening on port 25
>>  13170 running queue: waiting for children of 13258
>>  13321 delivering 16kU4N-0003AD-00 (queue run pid 13170)

>
>Most mysterious. I can't see why it would be going near LDAP while
>processing exiwhat.
>
>> Urgency: NOT (here) for Exim 3.
>
>That's good, because I'm afraid I have no clue as to how to do anything
>about this. Can you repeat it? Does it happen whenever you run exiwhat?


Thank you, Philip. I think given what you say it was most likely that the
assertion failure output happened to interleave with the exiwhat output.

This--as presented here--was very much a one-time thing, so far. But we
have been having crash problems with the (openLDAP) LDAP servers (located
"close by" on the Ethernet). On the 5-minute scale, the monitors reported
another crash at the same time this was going on...but on the execution
time scale it's impossible to know whether the assertion failure happened
at crash time.

It's possible I can trigger the assertion again, but doubtful that it will
happen to interleave with exiwhat output.

The queue was being run, as seen in the full report, due to
    exim -qq &
with the exiwhat issued right after that.


Let's assume that
Some exim process (perhaps 13321, perhaps not) made the LDAP query which
caused the LDAP library to emit the assertion. That leaves Exim merely as
the trigger mechanism, and not the problem. (It's possible this exchange
being in the list archives will help someone sometime.)

--john

--
John Baxter   jwblist@???      Port Ludlow, WA, USA