Re: [exim] stuck exim processes

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Andrew C Aitchison
Dátum:  
Címzett: Patrik Peng
CC: exim-users
Tárgy: Re: [exim] stuck exim processes
On Fri, 18 Mar 2022, Patrik Peng via Exim-users wrote:

> On 17.03.22 21:20, Jeremy Harris via Exim-users wrote:
>> Being certain would be better.
> Indeed. To be sure we created a new build based on the portstree + the
> following changes:
>
> -
> https://git.exim.org/exim.git/commitdiff/2ead369f8435918f3f15408b9394e580bcaf0910
> -
> https://github.com/Exim/exim/commit/c57309a50444d858c0a2dc1581846a850d78a9ad
>
> The changes for https://bugs.exim.org/show_bug.cgi?id=2831 regarding some
> SIGSEGVs are already included in the portstree.
>
>> Can you get a corefile?
> I managed to create one but without any debug symbols. As it contains some
> confidential data, I can't share it directly.
> But here is a backtrace that hopefully is of any use:
>
> #0  0x0000000800671695 in punycode_encode () from /usr/local/lib/libidn.so.12
> #1  0x0000000000321242 in string_localpart_utf8_to_alabel ()
> #2  0x000000000032154d in string_address_utf8_to_alabel ()
> #3  0x00000000003359c7 in smtp_write_mail_and_rcpt_cmds ()
> #4  0x000000000033834c in ?? ()
> #5  0x0000000000337024 in smtp_transport_entry ()
> #6  0x0000000000289f32 in ?? ()
> #7  0x00000000002857e1 in deliver_message ()
> #8  0x0000000000295a53 in main ()


Is that a locally built copy of libidn ?

The punycode_encode man page on Ubuntu 21.10 isword-for-word the same as
https://www.freebsd.org/cgi/man.cgi?query=punycode_encode&manpath=FreeBSD+13.0-RELEASE+and+Ports
Does your libidn have any different features ?



> If desired, I can try to get one with debug symbols next week.
>
> All affected messages' spool file contain some umlauts or other non-ascii
> chars in the recipients localpart:
>
> ---8<---
> -tls_resumption A
> -smtputf8
> XX
> 1
> ßßßßßß@somehost.net
>
> 176P Received: from mailnull by ...
> ---8<---
>
> Manually removing the "-smtputf8" line in the spool file causes the segfault
> to disappear on the next delivery attempt.
>
>
>


-- 
Andrew C. Aitchison                    Kendal, UK
             andrew@???