CODEWITHSUNDEEP
clinuxdebuggingglibc
Matt
Matt

Reputation: 1901

__libc_lock_lock is segfaulting

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

Upvotes: 0

Views: 1320

Answers (3)

su47flying
su47flying

Reputation: 11

In answer to your first question:

The macro is defined in the libc-lock.h; its relative path is sysdeps/mach/bits on the glibc release I use (2.2.5). Lines 67/68 from that file are

/* Lock the named lock variable.  */
#define __libc_lock_lock(NAME) __mutex_lock (&(NAME))

Upvotes: 1

Aiden Bell
Aiden Bell

Reputation: 28384

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

Upvotes: 2

foobarfuzzbizz
foobarfuzzbizz

Reputation: 58715

Run your code in gdb until you get to the segfault. Then do a backtrace to find out where it was.

Here is the set of commands you will type to do this:

gdb myprogram
run
***Make it crash***
backtrace

Typing backtrace will print the call stack and will show you what path the code has taken to get to the point where it is segfaulting.

You can go up and down in the stack to your code by typing 'up' or 'down' respectively. Then you can examine variables in that scope.

So for instance, if your backtrace command prints this:

linux_black_magic
more_linux
libc
libc
yourcode.c

Type 'up' a few times so that the stack frame is in your code instead of linux's. You can then examine variables and memory that your program is operating on. Do this:

print VariableName
x/10 &Variable

That will print the value of the variable and then will print a hex dump of memory starting at the variable.

Those are some general techniques to use with gdb and debugging, post more details for more detailed answers.

Upvotes: 0

Related Questions