[module dev] PCRE compiled code lost at reload

MAGNIEN, Thierry thierry.magnien at sfr.com
Wed Jun 22 14:21:51 UTC 2016

Hi Maxim,

Thanks for your response. I already saw that, and that's why I use a dedicated pool in shared memory for regex compilation. All my ngx_regex_compile_t structs allocate from this unique pool. Could pool in shared memory be automatically freed when reloading ? And in that case, why would new workers get the correct value ? Is there a place where memory is duplicated between workers before dying/start of workers ?

Thanks a lot,
De : nginx-devel [nginx-devel-bounces at nginx.org] de la part de Maxim Dounin [mdounin at mdounin.ru]
Envoyé : mercredi 22 juin 2016 15:49
À : nginx-devel at nginx.org
Objet : Re: [module dev] PCRE compiled code lost at reload


On Wed, Jun 22, 2016 at 09:31:12AM +0000, MAGNIEN, Thierry wrote:

> I'm experiencing a strange behavior and I wonder if I'm missing
> something obvious...
> I've developed a module and I use shared memory and slab
> allocations to keep data unique across workers and have data
> survive a reload.
> Everything works fine except one single thing: PCRE compiled
> codes (ngx_regex_compile_t->regex->code).
> To be more precise, at reload, in my module init function, I
> recompile some of the PCRE if they have changed, still using
> shared memory. What I notice is that, just after init module
> function has returned, all dying workers lose PCRE compiled code
> (regex->code = 0), where all new created workers correctly get
> new compiled code.
> I tried to use my own pcre_malloc function in order to be sure
> memory is allocated in shared memory (and this *is* the case),
> but without success.
> So any help is welcome: does anyone have a clue about why only
> those data are "lost" by dying workers ?

Regex compilation via ngx_regex_compile() uses memory from a pool
provided via ngx_regex_compile_t (rc->pool).  This memory will be
freed when a pool will be destroyed.  See rc/core/ngx_regex.c for

Maxim Dounin

nginx-devel mailing list
nginx-devel at nginx.org

More information about the nginx-devel mailing list