Quoting Kevin Sindhu <kevin.sindhu@???>:
> I suck at instructions as times when I write mail at 2 in the
> mornings:
It seems I'm no better as it seems the mail I sent in the middle of the
night was not clear enough.
> If you have compiled exim with gcc then you can use gdb to debug it. [...] > Paste and send the output from gdb. Also if you have a very specific
> config file, please attach that as well.
Maybe I should have left out the fact that exim do segfault as that's not
the problem but a side effect of the problem. If you really do want a gdb
output, I can send you one, but you'll only see a couple of times the same
4 or 5 lines which will only show the same thing I tried to say yesterday:
Exim enters in a Verifying loop and while verifying for an address, it
checks for the errors_to address which brings it back to the same place
and it starts a new verify for the same errors_to over and over (never
terminating any of them) and after something like 2500 verifications
(which would be about 10000 functions deep in the stack) it's too much and
it segfaults.
The following simplified config file will trigger this:
=== config file ===
begin routers
my_router:
driver = accept
errors_to = postmaster
transport = my_transport
begin transports
my_transport:
driver = smtp
=== end of config file ===
Yes, that's the entire config file you need, nothing more.
It can also be triggered by other drivers as the following config will
also trigger it (again. that's the entire file):
=== config file ===
begin routers
my_router:
driver = redirect
data = some_data
errors_to = postmaster
=== end of config file ===
A verification won't start a new verification when it is already
verifying, when doing a real delivery, if an error exist, it will freeze
when trying to error the error message which is what is expected. There is
just no loop protection for when it's in testing mode.
btw, Philip, is there a reason for direct.c to still be distributed?
Sorry if I'm still not clear enough (it's late again)..
