[Date Prev][Date Next]
Re: (ITS#3932) regex/librewrite concurrency issue
>> 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
>> I randomly experienced this with test039 on a 4 CPU machine; never
>> 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).
> 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
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
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().
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497