0

我正在研究一段在c中使用正则表达式的代码。

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

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

__libc_lock_lock(dfa->lock);

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

两个问题：

1）调用 __libc_lock_lock 时运行的代码在哪里（我知道它必须替换为某些东西，但我不知道那会在哪里。

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

这个 __libc_lock_lock 真的好像有某种魔法在这里发生

4

3 回答 3

2

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

  1. 你在 API 上做错了什么
  2. 您在之前的某个时间点损坏或损坏了 libc 使用的内存，这是一种延迟效应。（谢谢泰勒！）
  3. 您正在做一些推动 API 功能的事情
  4. 您是一名开发人员，使用 API 实现中的新更改测试当前主干

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

使用gdb查找调试以查找导致段错误的执行路径的堆栈跟踪，并为符号安装 glibc-devel 包。如果 segfault 在（或不在）libc ... 那么你做了一些坏事（例如，没有初始化一个不透明的指针）

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

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

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

祝你好运

于 2009-06-26T17:34:42.317 回答
1

回答你的第一个问题：

宏定义在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))
于 2010-01-28T08:37:50.380 回答
0

在 gdb 中运行代码，直到遇到段错误。然后进行回溯以找出它的位置。

以下是您将为此键入的一组命令：

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

键入 backtrace 将打印调用堆栈，并将向您显示代码已通过什么路径到达它出现段错误的位置。

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

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

linux_black_magic
more_linux
libc
libc
yourcode.c

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

print VariableName
x/10 &Variable

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

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

于 2009-06-26T17:36:21.300 回答