[Date Prev][Date Next] [Chronological] [Thread] [Top]

Glibc regex concurrency issues (Was: (ITS#3932) regex/librewrite concurrency issue

Whil einvestigating some odd issue I recently had with librewrite while running test039 on multiple CPU machines, I found that I was getting odd coredumps when 2 threads accessed the same regex_t inside librewrite. The problem occurred inside the internals of regexec(), and my glibc (2.3.4) does not have symbols in, so I couldn't trace the exact place. However, before going to compiling my own glibc, I searched glibc's CVS and I found that there might be an issue, although I couldn't find a precise bug notification. Looking at <http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/posix/regexec.c.diff?r1=1.78&r2=1.79&cvsroot=glibc&f=h> it appears that in HEAD some concurrency issue was recently solved. This fix has been merged into released code between 2.3.4 and 2.3.5, so I suspect that my glibc, and many before 2.3.5, may suffer from the same problem.

Now the point is: since wrapping regex calls 'round mutextes seemed to cure my problem, and since regex is used in librewrite, ACLs, authz-regexp, and limits, should we provide a compile switch to protect regex if one fears its implementation may not be thread safe? I've prepared a patch for this (I note that the patch I submitted with ITS#3932 is incomplete: the file <libraries/lblutil/regex.c> is missing, so I'm posting it now). This problem is not OpenLDAP specific, but given the impact of regex on OpenLDAP software, and the impact of rebuilding glibc (other implementations of regex may suffer from the same problem) on production systems which cannot undergo an upgrade shortly, I'd prefer to provide a workaround for those that require it.



   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497