__libc_lock_lock - это segfaulting - PullRequest
Новая
       12

__libc_lock_lock - это segfaulting

0 голосов
/ 26 июня 2009

Я работаю над фрагментом кода, который использует регулярные выражения в c.

Все регулярные выражения используют стандартную библиотеку regex c.

В строке 246 regexec.c строка: 

__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

происходит какая-то магия

Ответы [ 3 ]

2 голосов
/ 26 июня 2009

Если , то segfault находится в libc , тогда вы можете быть на 99,9% уверены в следующем:

  1. Вы делаете что-то не так с API
  2. В какой-то момент у вас была засоренная или поврежденная память, используемая libc, и это задержанный эффект. (Спасибо, Тайлер!)
  3. Вы делаете что-то, что расширяет возможности API
  4. Вы разработчик, тестирующий текущую магистраль с новыми изменениями в реализации API

Я подозреваю, что первая причина. Регистрация вашего использования API и вашей версии библиотеки может помочь. API Regexp в libc довольно стабильный.

Просмотрите отладку с помощью gdb , чтобы найти трассировку стека пути выполнения, ведущего к segfault, и установите пакеты glibc-devel для символов. Если segfault находится (или нет) в libc ... тогда вы сделали что-то плохое (например, не инициализировали непрозрачный указатель) 

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

Распечатает имена стеков и функций, которые привели к segault. Скомпилируйте исходный код с флагом отладки '-g', чтобы сохранить важную информацию об отладке.

Получите официальный источник для использования API / примеры!

Удачи

1 голос
/ 28 января 2010

В ответ на ваш первый вопрос:

Макрос определен в 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))
0 голосов
/ 26 июня 2009

Запускайте свой код в gdb, пока не доберетесь до ошибки. Затем сделайте обратный след, чтобы узнать, где это было.

Вот набор команд, которые вы будете вводить для этого: 

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

Печать backtrace напечатает стек вызовов и покажет вам, по какому пути следовал код, чтобы добраться до точки, где происходит ошибка.

Вы можете идти вверх и вниз по стеку к своему коду, набрав соответственно «вверх» или «вниз». Затем вы можете изучить переменные в этой области.

Так, например, если ваша команда backtrace напечатает это: 

linux_black_magic
more_linux
libc
libc
yourcode.c

Несколько раз введите 'up', чтобы в вашем коде был фрейм стека, а не linux. Затем вы можете проверить переменные и память, на которой работает ваша программа. Сделайте это: 

print VariableName
x/10 &Variable

Это напечатает значение переменной, а затем напечатает шестнадцатеричный дамп памяти, начиная с переменной.

Это некоторые общие приемы, которые можно использовать с GDB и отладкой, опубликуйте подробности для более подробных ответов.

...