__libc_lock_lock正在分段故障

Question

我正在编写一段使用c ++正则表达式的代码。

所有的regex代码都使用标准的regex c库。

在regexec.c的第246行，行是

__libc_lock_lock(dfa->lock);

我的程序在这里出现了分段错误，我找不到原因。我试图查找__libc_lock_lock的定义位置，结果发现它是位/libc-lock.h中的一个宏。然而，宏实际上并没有被定义为任何东西，只是被定义了。

两个问题：

1)哪里是在调用__libc_lock_lock时运行的代码(我知道它必须被替换，但我不知道它会在哪里。

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

看起来这个__libc_lock_lock真的有某种魔力

Answer 1

如果段错误位于libc中，那么您可以99.9%地确定以下几点：

1. 你的
2. 接口出了点问题，你的libc使用的内存被破坏了，这是一个延迟效应。(谢谢implementation

！)

• 您正在做的事情正在推动API的功能

• 您是一名开发人员，正在使用API API中的新更改测试当前的主干

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

使用gdb查看调试，找到通向段错误的执行路径的堆栈跟踪，并安装符号的glibc-devel包。如果段错误在libc内(或外) ...那么你做了一些不好的事情(例如，没有初始化一个不透明的指针)

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

将打印指向segault的堆栈和函数名。使用'-g‘调试标志编译你的源代码，以保存重要的调试信息。

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

好运

Answer 2

在回答你的第一个问题时：

宏是在libc-lock.h中定义的；在我使用的glibc发行版(2.2.5)上，它的相对路径是sysdeps/mach/bits。该文件中的67/68行是

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

Answer 3

在gdb中运行您的代码，直到您到达段错误。然后进行回溯，找出它在哪里。

以下是执行此操作所需键入的一组命令：

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

键入backtrace将打印调用堆栈，并向您显示代码采用了哪条路径才能到达分段错误的位置。

通过分别键入“up”或“down”，您可以在堆栈中上下移动到您的代码。然后，您可以检查该作用域中的变量。

因此，例如，如果您的回溯命令打印以下内容：

linux_black_magic
more_linux
libc
libc
yourcode.c

输入“up”几次，这样堆栈框架就会出现在你的代码中，而不是linux的代码中，然后你就可以检查你的程序正在操作的变量和内存了。执行以下操作：

print VariableName
x/10 &Variable

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

这些是一些用于gdb和调试的通用技术，请发布更多详细信息以获得更详细的答案。