Question

I am working on a piece of code which uses regular expressions in c.

All of the regex stuff is using the standard regex c library.

On line 246 of regexec.c, the line is

__libc_lock_lock(dfa->lock);

My program is segfaulting here and I cannot figure out why. I was trying to find where __libc_lock_lock was defined and it turns out it is a macro in bits/libc-lock.h. However, the macro isnt actually defined to be anything, just defined.

Two questions:

1) Where is the code that is run when __libc_lock_lock is called (I know it must be
replaced with something but I dont know where that would be.

2) if dfa is a re_dfa_t object which is casted from a c string which is the buffer member of the regex_t object type, it will not have any member lock. Is this what is supposed to happen.

It really seams like there is some kind of magic going on here with this __libc_lock_lock

Answer 1

If the segfault is in libc then you can be 99.9% sure of the following:

1. You are doing something wrong with the API
2. You have at some previous point clobbered or corrupted memory used by libc, and this is a delayed effect. (Thanks Tyler!)
3. You are doing something that is pushing the API’s capability
4. You are a developer testing the current trunk with new changes in the API implementation

I suspect that the first is the cause. Posting your API usage and your library version might help. The Regexp API in libc is pretty stable.

Look up debugging with gdb to find a stack trace of the execution path leading to the segfault, and install the glibc-devel packages for the symbols. If the segfault is in (or out) of libc … then you have done something bad (not initialized an opaque pointer for example)

[aiden@devbox ~]$ gdb ./myProgram
(gdb) r
... Loads of stuff, segfault info ..
(gdb) bt

Will print the stack and function-names that led to the segault. Compile your source with the ‘-g’ debug flag to keep important debugging information.

Get an authoritative source for API usage/examples!

Good Luck