Re: [exim-dev] [exim] Numerous segfaults with 64 bit exim

Góra strony
Delete this message
Reply to this message
Autor: Todd Lyons
Data:  
Dla: Patrick Boutilier
CC: exim-dev
Temat: Re: [exim-dev] [exim] Numerous segfaults with 64 bit exim
On Wed, Jun 8, 2011 at 9:49 AM, Patrick Boutilier <boutilpj@???> wrote:
> #0  0x00002b2d4065c470 in strchr () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x00002b2d3d98a92c in smtp_respond (code=0x2b2d3d9e8906 "550",
> codelen=<value optimized out>, final=1, msg=0x0) at smtp_in.c:2045
>        esclen = 0
>        esc = 0x2b2d3da0413e ""


I don't know much C so my tracing below may be not wrong, but
COMPLETELY wrong. :-/

In the backtrace above, I see that msg is NULL. It's a pointer passed to:

smtp_respond(uschar* code, int codelen, BOOL final, uschar *msg)

And line 2045 of smtp_in.c we have:
uschar *nl = Ustrchr(msg, '\n');

So the segfault presumably comes from attempting to append a char to
the contents of the msg pointer, but the pointer is NULL.

That is called by this:
        smtp_respond((fake_response == DEFER)? US"450" : US"550", 3, TRUE,
          fake_response_text);


fake_response_text is a pointer defined in globals.c, but it can be
overridden by you, the admin in your ACLs. In acl.c, we have:

        fake_response_text = expand_string(string_copyn(p+1, pp-p-1));


So now, we're back to your config file. Maybe somewhere you're doing
a control = fakereject/ but not putting any message after the slash?
We need to see your config file.

However, this could be a bug. A misconfiguration should not be able
to cause exim to segfault. It should either error on startup or be
silently bypassed.

...Todd
--
If Americans could eliminate sugary beverages, potatoes, white bread,
pasta, white rice and sugary snacks, we would wipe out almost all the
problems we have with weight and diabetes and other metabolic
diseases. -- Dr. Walter Willett, Harvard School of Public Health