Re: [exim-dev] [Bug 1671] segfault after delivery

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Daryl Richards
Ημερομηνία:  
Προς: exim-dev
Αντικείμενο: Re: [exim-dev] [Bug 1671] segfault after delivery
On 22/08/2015 12:30 PM, Heiko Schlittermann wrote:
> Hi Daryl,
>
> Daryl Richards <daryl@???> (Do 20 Aug 2015 18:00:05 CEST):
>>>> 1ZSOZc-0002m2-U8 1ZSOZd-0002mG-02 1ZSOZd-0002lz-0d 1ZSOZl-0002oF-IJ
>>>> 1ZSOZl-0002oI-FN 1ZSOZl-0002oX-Hw 1ZSOaY-0002rn-Dz 1ZSOaY-0002rq-DP
>>>> 1ZSOaY-0002rz-D3
>>>>
>>>> The dumpdb line shows the destination host, and various message ids, but not
>>>> the one that is frozen.. ??
>>> Yes, the message ids shown are normally IDs of messages waiting for that
>>> host. Do you run lots of queue runners in parallel?
>>>
>>>
>> Well, all those message ids where no longer in the queue itself. mailq only
>> showed the one message, as delivered but frozen. That list was also
>> generated about 45 minutes after the message was actually sent through. I do
>> not run queue runners in parallel.
> If you're familiar with git, you may cherry-pick the commits
>
>      dadff1d47e54962b0fdf98e8ce5cef42b6cb7fb5
>      6b51df8340eacc95e3def9a4376506610e91996c

>
> to exim-4_86.
> Or, you may try the patch I appended here.
>
> It makes me worry that you don't use split_spool_directory.
> Can you reproduce the crash?
>
> (I did about what Wolfgang Breyha did too: blocked the outgoing
> connections for a short while to get the wait-<transport> db filled.
> Then cp wait-<transport> away and re-enable the connections again.)
>
> During flushing the waiting message Exim crashed. And, additionally I
> could reproduce the behaviour if I copied back the saved
> wait-<transport> file, because now it clearly contained an "expired"
> message ID.
>
> So, can you - with a plain exim-4_86 reproduce the crash?
> Does it still crash with the above commits applied?
> If it crashes, can you compile Exim with -ggdb and let it core dump?
>

Hello Heiko,

I'm not that up on git, etc, but I can and do build from FreeBSD ports.
It was easy enough to add your patch into that tree and build a
version... And, it's been running 24 hours now and the problem *seems*
to be gone. The offending emails are generated many times a day, so I
didn't have to try to inject them manually.

I will keep watching it and will let you know if any more end up frozen.