<div dir="ltr">Only problem is that it's a build option. <br><br>Increasing the stack space will only work as long as the regex doesn't recurse more than the stack space allows.<br><br>Not sure what's the best solution here but we should avoid crashing.<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 2, 2014 at 6:12 PM, Nils Goroll <span dir="ltr"><<a href="mailto:slink@schokola.de" target="_blank">slink@schokola.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
on the weekend I have actually stumbled over the same cause that bug #1576 has<br>
(but unfortunately have not immediately realized the connection) and have<br>
changed our dcs_classifier vmod (which needs some reasonably large scratch<br>
memory in the order of ~64k) to use the client workspace rather than stack.<br>
<br>
Using the workspace seemed more reasonable as varnish core structures have been<br>
moved away from the stack and I thought it would be more advantagous to increase<br>
a workspace size than increase the stack size (which has a nice tiny default of<br>
48k now).<br>
<br>
But then Ferdericos comment in #1576 made me re-think this:<br>
<br>
> Comment (by fgsch):<br>
><br>
>  This is actually related to the thread_pool_stack size.<br>
>  Bumping the value to 49k make the test work. Lowering pcre_match_limit<br>
>  makes the match fail without crashing.<br>
><br>
>  Should we reduce the pcre_match_limit to something more sensible? 10000<br>
>  seems like a rather large value.<br>
<br>
If we were to need a larger default stack for pcre anyway, it wouldn't make<br>
sense to move scratch space to a WS.<br>
<br>
On the other hand, we might as well consider to give pcre space from workspaces:<br>
<br>
PCRESTACK(3):<br>
<br>
   Compiling PCRE to use heap instead of stack for pcre[16]_exec()<br>
<br>
       In environments where stack memory is constrained, you might want to<br>
compile PCRE to use heap memory instead of stack for remember‐<br>
       ing  back-up  points  when pcre[16]_exec() is running. This makes it run<br>
a lot more slowly, however.  Details of how to do this are<br>
       given in the pcrebuild documentation. When built in this way, instead of<br>
using the stack, PCRE obtains and frees memory by  calling<br>
       the  functions  that are pointed to by the pcre[16]_stack_malloc and<br>
pcre[16]_stack_free variables. By default, these point to mal‐<br>
       loc() and free(), but you can replace the pointers to cause PCRE to use<br>
your own functions. Since the block sizes  are  always  the<br>
       same,  and  are  always  freed in reverse order, it may be possible to<br>
implement customized memory handlers that are more efficient<br>
       than the standard functions.<br>
<br>
So we could simply hand the free space of some ws to pcre via some<br>
pcre_stack_(malloc|free).<br>
<br>
<br>
Whatever we do, we should either try to minimize ws usage or stack usage, but do<br>
it consequently for all components.<br>
<br>
Nils<br>
<br>
_______________________________________________<br>
varnish-dev mailing list<br>
<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a></blockquote></div><br></div>