[exim-dev] [Bug 1403] exim crashes while lookup result for l…

Top Page
Delete this message
Reply to this message
Author: Todd Lyons
Date:  
To: exim-dev
Subject: [exim-dev] [Bug 1403] exim crashes while lookup result for lsearch in file with to long lines
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1403




--- Comment #8 from Todd Lyons <tlyons@???> 2013-10-25 18:16:31 ---
On Thu, Oct 24, 2013 at 5:54 PM, Phil Pennock <pdp@???> wrote:
> --- Comment #5 from Phil Pennock <pdp@???> 2013-10-25 01:54:53 ---
> Be careful here: studying a regexp can be quite slow, which is why it's not
> done by default. In Perl, for instance, you have to be invoking a regexp a
> potentially large number of times before the costs are paid for by improved
> performance.
>
> So studying all regular expressions always may result in performance
> regressions.
>
> It might be worth adding a match_study expansion condition; or pushing this
> change after 4.82 goes out, so that people have more time to explore the impact
> on them.


Agree on both cases. It's not going to go into 4.82. Possibly an
additional documentation entry that "If you are using a regex against
a string/list of data and you get a segfault, your options are to
either increase your stack size with ulimit in the script which starts
your exim mail server, or adjust your code which generates that
string/list to make multiple shorter lists."

I would like to add a test entry which exercises this particular
error, but since it's dependent upon the stack size setting, it would
have to be designed to be ridiculously over any sane limits, which
seems difficult to do.

> Other than the potential for performance regressions, the patch looks good to
> me.


Thanks. I also want to generate a patch which explicitly sets the
match limit when calling pcre_exec().

Then I want to compare the operation of the two patches.

...Todd


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email