__libc_lock_lock是segfaulting

Question

我正在编写一段在c。

中使用正则表达式的代码

所有正则表达式的东西都使用标准的正则表达式c库。

在regexec.c的第246行，该行是

__libc_lock_lock(dfa->lock);

我的程序在这里是segfaulting，我无法弄清楚原因。我试图找到定义__libc_lock_lock的位置，结果发现它是bits / libc-lock.h中的一个宏。但是，宏实际上并没有被定义为任何东西，只是定义了。

两个问题：

1）调用__libc_lock_lock时运行的代码在哪里（我知道它必须是       取而代之的是我不知道那会是什么。

2）如果dfa是一个re_dfa_t对象，它是从一个c字符串转换而来的，该字符串是regex_t对象类型的缓冲区成员，它将没有任何成员锁。这是应该发生的事情。

这真是接缝，就像这里有一种神奇的__libc_lock_lock

Answer 1

如果 segfault在libc中，那么您可以99.9％确定以下内容：

1. 你做错了API
2. 你在之前的某些时候已经被libc使用了破坏或损坏的内存，这是一种延迟效果。 （谢谢泰勒！）
3. 你正在做一些推动API能力的事情
4. 您是使用API​​实施中的新变化测试当前主干的开发人员

我怀疑第一个是原因。发布API使用情况和库版本可能会有所帮助。 libc中的Regexp API非常稳定。

使用 gdb 查找调试，找到导致segfault的执行路径的堆栈跟踪，并为符号安装glibc-devel软件包。如果segfault在libc中（或者是out）...那么你做了一些不好的事情（例如没有初始化不透明的指针）

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

将打印导致segault的堆栈和函数名称。使用'-g'调试标志编译源代码以保留重要的调试信息。

获取API使用/示例的权威来源！

祝你好运

Answer 2

回答你的第一个问题：

宏在libc-lock.h中定义;它的相对路径为sysdeps/mach/bits 我使用的glibc版本（2.2.5）。该文件中的第67/68行是

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

Answer 3

在gdb中运行代码，直到进入segfault。然后进行回溯以找出它的位置。

以下是您要键入的命令集：

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

键入backtrace将打印调用堆栈，并显示代码所采用的路径，以达到segfaulting的位置。

您可以分别在“向上”或“向下”键入堆栈中的代码。然后，您可以检查该范围内的变量。

例如，如果你的backtrace命令打印出来：

linux_black_magic
more_linux
libc
libc
yourcode.c

键入'up'几次，以便堆栈帧位于代码而不是linux中。然后，您可以检查程序正在运行的变量和内存。这样做：

print VariableName
x/10 &Variable

这将打印变量的值，然后从变量开始打印内存的十六进制转储。

这些是与gdb和调试一起使用的一些常规技术，发布更多详细信息以获得更详细的答案。