LINUX.ORG.RU
Форум — Development  

GDB не может. Как ему помочь?

 ,


0

3

Привет, чат!

С недавних пор GDB больше не может и вместо нормального дебага сыпет ошибками Cannot access memory at address 0x40686f на некоторых бинарниках. LLDB при этом без проблем работает. В какую сторону это вообще копать-то? Впервые с таким сталкиваюсь.

Лог сессии:

(gdb) b main
Breakpoint 1 at 0x406873
(gdb) run
Starting program: /home/user/Development/playground/test 
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x40686f

# Здесь должен быть выведен Hello world, но его нет
(gdb)


Последнее исправление: Guillaume_de_Nogare (всего исправлений: 2)
← Golang удобен для реализации desktop app?
Использовать ли голые указатели, new, delete и т.п. в новом проекте или сразу начинать с стандарта 11+? →
Ответ на: комментарий от mky 
$ file _playground/test
_playground/test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/lmn7lwydprqibdkghw7wgcn21yhllz13-glibc-2.40-66/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, with debug_info, not stripped

Это просто бинарник, без особой магии. Если запускать напрямую без GDB, всё корректно отрабатывает.

Guillaume_de_Nogare
() автор топика

А что за система, ядро, опции?

Если система с какими-то нестандартными защитами от хакеров, типа запрета записи в память с кодом процесса, то понятно, что работать не будет, потому что GDB меняет код вставляя инструкцию (точно не помню, кажется, какое-то прерывание), чтобы реализовать остановку в нужном месте.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

А что за система, ядро, опции?

NixOS. Ничего необычного.

Если система с какими-то нестандартными защитами от хакеров, типа запрета записи в память с кодом процесса, то понятно, что работать не будет, потому что GDB меняет код вставляя инструкцию (точно не помню, кажется, какое-то прерывание), чтобы реализовать остановку в нужном месте.

LLDB-то работает. Другие бинарники GDB пережёвывает с различным успехом, хотя ругань про «Cannot access memory at address» остаётся.

Guillaume_de_Nogare
() автор топика
Ответ на: комментарий от Guillaume_de_Nogare

В общем, оказывается, сейчас помимо software breakpoints (замена инструкции на int 0x3) есть hardware breakpoints через регистры процессора.

Попробуй в GDB вместо break hbreak. Если сработает - значит проблема точно в защите памяти процесса от записи.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

оказывается, сейчас помимо software breakpoints (замена инструкции на int 0x3) есть hardware breakpoints через регистры процессора.

Ты пишешь к нам из 1980-ого года? Когда услышишь про битки - закупайся!

Если сработает - значит проблема точно в защите памяти

Ровно наоборот.

LamerOk ★★★★★
()

меня глючит или playground/test и _playground/test вообще говоря разные файлы ?

не знаю какая там каша заварена в NiX`os, это могут быть их проблемы. С файловыми системами там нахреноверчено

MKuznetsov ★★★★★
()
Последнее исправление: MKuznetsov (всего исправлений: 1)
Ответ на: комментарий от MKuznetsov

меня глючит или playground/test и _playground/test вообще говоря разные файлы ?

Сорри, криво скопипастил. Это один и тот же файл.

не знаю какая там каша заварена в NiX`os, это могут быть их проблемы. С файловыми системами там нахреноверчено

Как это проверить?

Guillaume_de_Nogare
() автор топика
Ответ на: комментарий от Guillaume_de_Nogare

Как это проверить?

собирать нетленку в стейбл-Debian..для old-фагов в Слаке..

и там собственно билдить/отлаживать

Nix`os и прочая экзотика это уже порты, когда всё готово и точно работает.

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

собирать нетленку в стейбл-Debian..для old-фагов в Слаке..

Что? Это моя рабочая система, я пытаюсь отладить прогу, над которой работаю. Ты предлагаешь мне дистрибутив менять? Нет уж, спасибо.

Nix`os и прочая экзотика это уже порты, когда всё готово и точно работает.

Ну вот GDB похоже не очень работает и не готов для десктопа. Придётся переходить на LLDB, который смог.

Guillaume_de_Nogare
() автор топика
Ответ на: комментарий от Guillaume_de_Nogare

Я тоже уверен, что тут как-то причастен NixOS. Набросал сейчас простую программу на C, запустил под GDB, breakpoint отработал без проблем.

Я бы посоветовал искать ответ где-нибудь в NixOS community.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

Я тоже уверен, что тут как-то причастен NixOS

Возможно. Вопрос только в том, как именно он может быть причастен-то? Куда это вообще копать, кроме как в сторону «уже третий год слышу непонятный стук»?

Guillaume_de_Nogare
() автор топика
Ответ на: комментарий от vbcnthfkmnth123

LLDB работает. GDB тоже работает на некоторых бинарниках. А на некоторых не работает. А на некоторых работает, но с кучей ошибок. Вот пример с тупым сишным hello world:

(gdb) b main
Breakpoint 1 at 0x401135: file helloworld.c, line 5.
(gdb) run
Starting program: /home/void/Development/C/helloworld 
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
[New LWP 167390]
[LWP 167390 exited]
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
[New LWP 167391]
[New LWP 167392]
[New LWP 167393]
[LWP 167393 exited]
[LWP 167392 exited]
[LWP 167391 exited]
process 167387 is executing new program: /home/void/Development/C/helloworld
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/lmn7lwydprqibdkghw7wgcn21yhllz13-glibc-2.40-66/lib/libthread_db.so.1".

Thread 1 "helloworld" hit Breakpoint 1, main (argc=1, argv=0x7fffffff08d8)
    at helloworld.c:5
5           printf("Hello, %s\n", "LOR");
(gdb) c
Continuing.
Hello, LOR
[Inferior 1 (process 167387) exited normally]
Guillaume_de_Nogare
() автор топика
Ответ на: комментарий от MKuznetsov

С файловыми системами там нахреноверчено

А не может ли такого быть, что библиотеки из одной версии чего-нибудь, а gdb из другой? И gdb тупо не туда пытается прицепится из-за этого.

Я в nix не силён.

Aceler ★★★★★
()

и вот этот /home/user/Development/playground/test был собран вот только что на этой же машине и gdb не работает ?

у мне бывали ошибки типа «Cannot access memory» если бинарь «не родной», возможно у тебя другое, просто предположил

x905 ★★★★★
() 
(gdb) b main
Breakpoint 1 at 0x406873

Cannot access memory at address 0x40686f

Странно, правда, что адреса разные? А что скажет p main? А x /10i 0x406873 и x /10i 0x40686f? А аналогичные команды на том же бинарнике в LLDB?

Пожалуйста, покажите, как Вы собираете этот бинарник.

anonymous
()
Ответ на: комментарий от mky

Файл gdbinit большой? Если без него попробовать (опция -n)?

Пробовал с пустым. Ничего не меняется.

И меняется ли что-то, если вместо ″b main; run″ делать ″start″ или ″starti", а потом «run»?

start так же валится. starti успешно ставит breakpoint в самом начале в _start, но если сделать n, программа прорабатывает полностью и завершается корректно. Новые breakpoint ставить не выходит из-за той же ошибки.

Guillaume_de_Nogare
() автор топика
Ответ на: комментарий от anonymous

А что скажет p main? А x /10i 0x406873 и x /10i 0x40686f?

(gdb) p main
$1 = {<text variable, no debug info>} 0x40686f <main>
(gdb) x /10i 0x406873
   0x406873 <main+4>:   push   %rbx
   0x406874 <main+5>:   sub    $0x88,%rsp
   0x40687b <main+12>:  mov    %edi,-0x84(%rbp)
   0x406881 <main+18>:  mov    %rsi,-0x90(%rbp)
   0x406888 <main+25>:  mov    0x4389d1(%rip),%rax        # 0x83f260 <defaultRtsConfig>
   0x40688f <main+32>:  mov    0x4389d2(%rip),%rdx        # 0x83f268 <defaultRtsConfig+8>
   0x406896 <main+39>:  mov    %rax,-0x80(%rbp)
   0x40689a <main+43>:  mov    %rdx,-0x78(%rbp)
   0x40689e <main+47>:  mov    0x4389cb(%rip),%rax        # 0x83f270 <defaultRtsConfig+16>
   0x4068a5 <main+54>:  mov    0x4389cc(%rip),%rdx        # 0x83f278 <defaultRtsConfig+24>
(gdb) x /10i 0x40686f
   0x40686f <main>:     push   %rbp
   0x406870 <main+1>:   mov    %rsp,%rbp
   0x406873 <main+4>:   push   %rbx
   0x406874 <main+5>:   sub    $0x88,%rsp
   0x40687b <main+12>:  mov    %edi,-0x84(%rbp)
   0x406881 <main+18>:  mov    %rsi,-0x90(%rbp)
   0x406888 <main+25>:  mov    0x4389d1(%rip),%rax        # 0x83f260 <defaultRtsConfig>
   0x40688f <main+32>:  mov    0x4389d2(%rip),%rdx        # 0x83f268 <defaultRtsConfig+8>
   0x406896 <main+39>:  mov    %rax,-0x80(%rbp)
   0x40689a <main+43>:  mov    %rdx,-0x78(%rbp)

А аналогичные команды на том же бинарнике в LLDB?

(lldb) p (int(*)(int,char**)) main
(int (*)(int, char **)) 0x000000000040686f
(lldb) di -s 0x406873
test`main:
test[0x406873] <+4>:  pushq  %rbx
test[0x406874] <+5>:  subq   $0x88, %rsp
test[0x40687b] <+12>: movl   %edi, -0x84(%rbp)
test[0x406881] <+18>: movq   %rsi, -0x90(%rbp)
test[0x406888] <+25>: movq   0x4389d1(%rip), %rax ; defaultRtsConfig
(lldb) di -s 0x40686f
test`main:
test[0x40686f] <+0>:  pushq  %rbp
test[0x406870] <+1>:  movq   %rsp, %rbp
test[0x406873] <+4>:  pushq  %rbx
test[0x406874] <+5>:  subq   $0x88, %rsp
test[0x40687b] <+12>: movl   %edi, -0x84(%rbp)
test[0x406881] <+18>: movq   %rsi, -0x90(%rbp)
test[0x406888] <+25>: movq   0x4389d1(%rip), %rax ; defaultRtsConfig

Одно и то же показывают.

Пожалуйста, покажите, как Вы собираете этот бинарник.

Это выхлоп кастомной сборки GHC. Я работаю над добавлением пары фич в компилятор. Сам код не то чтобы важен, там вызываются только сишные puts и exit и код сборки мусора. Не очень понимаю, как что-то из этого может мешать работе GDB.

Guillaume_de_Nogare
() автор топика
Ответ на: комментарий от x905

и вот этот /home/user/Development/playground/test был собран вот только что на этой же машине и gdb не работает ?

Да.

у мне бывали ошибки типа «Cannot access memory» если бинарь «не родной», возможно у тебя другое, просто предположил

Нет, это родной бинарь для amd64. Выхлоп file выкладывал выше.

Guillaume_de_Nogare
() автор топика
← Golang удобен для реализации desktop app?
Development
Использовать ли голые указатели, new, delete и т.п. в новом проекте или сразу начинать с стандарта 11+? →