Hi,
I used the shm_regex functions from lib in one of my own modules and noticed that it is dead-locking (it hangs in FUTEX_WAIT). The code hangs in regexec() when trying to acquire the lock. This was a bit hard to find out as I couldn't reproduce it in a virtual machine with some test code I wrote. It turns out this only happens if the machine has more than one physical CPU core. Reproducable on x86_64 with two CPU cores, glibc 2.3.6 (from Debian Etch) and glibc 2.11.1 (from Ubuntu Jaunty). Attached is a patch which does its own locking and thus works around this problem.
Best regards, Stefan
On Sun, 13 Jun 2010 02:31:52 +0200 Stefan Keller stefan.keller@isaco.de wrote:
Hi,
I used the shm_regex functions from lib in one of my own modules and noticed that it is dead-locking (it hangs in FUTEX_WAIT). The code hangs in regexec() when trying to acquire the lock. This was a bit hard to find out as I couldn't reproduce it in a virtual machine with some test code I wrote. It turns out this only happens if the machine has more than one physical CPU core. Reproducable on x86_64 with two CPU cores, glibc 2.3.6 (from Debian Etch) and glibc 2.11.1 (from Ubuntu Jaunty).
Sorry, I meant to write Ubuntu Lucid (10.04).
Attached is a patch which does its own locking and thus works around this problem.
Best regards, Stefan
On Sunday 13 June 2010, Stefan Keller wrote:
I used the shm_regex functions from lib in one of my own modules and noticed that it is dead-locking (it hangs in FUTEX_WAIT). The code hangs in regexec() when trying to acquire the lock. This was a bit hard to find out as I couldn't reproduce it in a virtual machine with some test code I wrote. It turns out this only happens if the machine has more than one physical CPU core. Reproducable on x86_64 with two CPU cores, glibc 2.3.6 (from Debian Etch) and glibc 2.11.1 (from Ubuntu Jaunty). Attached is a patch which does its own locking and thus works around this problem.
Hi Stefan,
thank you for the patch, it looks fine to me on a first sight. The library in question is not used in any of the existing modules, so i think it should be pretty save. Miklos, its ok when i apply it, or do you maybe want to refine it a bit?
Regards,
Henning
Hello,
On 6/14/10 3:11 PM, Henning Westerholt wrote:
On Sunday 13 June 2010, Stefan Keller wrote:
I used the shm_regex functions from lib in one of my own modules and noticed that it is dead-locking (it hangs in FUTEX_WAIT). The code hangs in regexec() when trying to acquire the lock. This was a bit hard to find out as I couldn't reproduce it in a virtual machine with some test code I wrote. It turns out this only happens if the machine has more than one physical CPU core. Reproducable on x86_64 with two CPU cores, glibc 2.3.6 (from Debian Etch) and glibc 2.11.1 (from Ubuntu Jaunty). Attached is a patch which does its own locking and thus works around this problem.
Hi Stefan,
thank you for the patch, it looks fine to me on a first sight. The library in question is not used in any of the existing modules, so i think it should be pretty save. Miklos, its ok when i apply it, or do you maybe want to refine it a bit?
just in case it was not know by you, pcre library can be used to store compiled regexp in shared memory (like in dialplan module).
Cheers, Daniel
2010/6/14 Daniel-Constantin Mierla miconda@gmail.com:
just in case it was not know by you, pcre library can be used to store compiled regexp in shared memory (like in dialplan module).
Just to confirm what Daniel says, when I coded 'regex' module first I tryed to use regex library, but it just didn't work in shared memory (I don't remember the details but got also confirmation from other people). Using pcre library did the job.
Hi,
Stefan, thank you very much for the patch! In general, you should use this library only if you really need posix regular expressions in shared memory. If you are fine with the perl syntax then I would rather suggest pcre. Pcre can allocate the memory in a single block that can be moved to shm mem easily. I made some performance tests a year ago with simple expressions, the libc implementation and pcre performed almost at the same speed when back tracking was not in use. With back tracking, pcre was an order of magnitude faster than libc.
Henning, I can apply the patch, will do that asap. Thanks for the pointer!
Thanks, Miklos
On 06/14/2010 03:11 PM, Henning Westerholt wrote:
On Sunday 13 June 2010, Stefan Keller wrote:
I used the shm_regex functions from lib in one of my own modules and noticed that it is dead-locking (it hangs in FUTEX_WAIT). The code hangs in regexec() when trying to acquire the lock. This was a bit hard to find out as I couldn't reproduce it in a virtual machine with some test code I wrote. It turns out this only happens if the machine has more than one physical CPU core. Reproducable on x86_64 with two CPU cores, glibc 2.3.6 (from Debian Etch) and glibc 2.11.1 (from Ubuntu Jaunty). Attached is a patch which does its own locking and thus works around this problem.
Hi Stefan,
thank you for the patch, it looks fine to me on a first sight. The library in question is not used in any of the existing modules, so i think it should be pretty save. Miklos, its ok when i apply it, or do you maybe want to refine it a bit?
Regards,
Henning
-
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Miklos Tirpak -
Stefan Keller