Re: (ITS#3932) regex/librewrite concurrency issue

[Kurt@OpenLDAP.org]

At 10:36 AM 8/13/2005, Pierangelo Masarati wrote:

>>> There may be concurrent accesses to regex_t datum by librewrite; if
>>> regexec is
>>> not thread safe (which I suppose is not) this may result in concurrency
>>> issues.
>>> I randomly experienced this with test039 on a 4 CPU machine; never
>>> experienced
>>> it on single CPU machine.
>>
>> I'm not sure the one committed is the right fix: if the non-reentrancy
>> issue is in regexec(3), then also ACLs should suffer from it.  In this
>> case either we assume regex is not reentrant, or require it is, or provide
>> compile switches or function wrappers to handle the case it's not.  I note
>> there are a few past ITSes that point in this direction and that have
>> never been fixed (e.g. ITS#3634).

I think we should move this issue to -devel for broader
discussion....

Kurt

>>
>> On the machine I'm able to experience this issue the OS is CentOS release
>> 4.1 (Final) and regex is part of glibc 2.3.4
>
>OK, it could well be a glibc issue; see
><http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/posix/regexec.c.diff?r1=1.78&r2=1.79&cvsroot=glibc&f=h>
>which appears to be a reentrancy issue fix in glibc 2.3.5.  Assuming we
>cannot pretend people compile glibc, I think we should definitely provide
>a conditionally compiled set of wrappers.  If you give me a go I have it
>almost ready (for HEAD) which is very little intrusive: since regex always
>goes
>
>regcomp/regexec/regfree, I can wrap a mutex 'round regex_r and have
>pthread_mutex_init() called along with regcomp(), lock()/unlock() around
>regexec(), and pthread_mutex_destroy() with regfree().
>
>p.
>
>-- 
>Pierangelo Masarati
>mailto:pierangelo.masarati@sys-net.it
>
>
>    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497