gdb non ha colpito alcun punti di interruzione quando l'eseguo da dentro container Docker

Question

Il problema

io sono in grado di impostare e raggiungere un punto di interruzione se compilo e corro dall'host, ma se lo faccio da dentro il contenitore gDB della finestra mobile non ha raggiunto i punti di interruzione impostati.

Passaggi per riprodurre (tutti i frammenti sono copia-incolla pronti)

Creare un file di finestra mobile:

cat <<EOF> Dockerfile 
FROM ubuntu 
RUN apt-get update 
RUN apt-get install -y build-essential gdb 
EOF 

costruire un'immagine ed eseguire una sessione interattiva in esso:

docker build -t gdb_problem_testing . && docker run --rm -it gdb_problem_testing bash 

Dall'interno del contenitore creare piccoli main.cpp, compilare ed eseguire gdb:

cat <<EOF > main.cpp && g++ -g main.cpp && gdb -ex 'break 5' -ex 'run' ./a.out 
#include <iostream> 

int main(int argc, const char *argv[]) 
{ 
    std::cout << "hi\n"; 
    return 0; 
} 
EOF 

Osservare l'output gdb:

GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 
[Skipped gdb greeting] 
Reading symbols from ./a.out...done. 
Breakpoint 1 at 0x40078c: file main.cpp, line 5. 
1 #include <iostream> 
2 
3 int main(int argc, const char *argv[]) 
4 { 
5  std::cout << "hi\n"; 
6  return 0; 
7 } 
Starting program: /a.out 
hi 
During startup program exited normally. 
(gdb) 

Dall'output si può vedere che il punto di interruzione non è stato colpito, anche se il programma è stato eseguito (stampato 'ciao') ed è uscito con successo. Credo che la cosa più importante qui è che il programma è stato eseguito e che il messaggio Durante programma di avvio uscito normalmente è un comportamento anomalo (secondo GDB ignores my breakpoints)

Domanda

Cosa impedisce gdb dall'impostazione il punto di interruzione e come risolvere questo problema?

Quello che ho provato finora

1. Come suggerito here, ho provato a cambiare una linea in /etc/apparmor.d/docker (l'ho fatto nel host): sostituto profile docker-default flags=(attach_disconnected,mediate_deleted) { da profile docker-default flags=(attach_disconnected,mediate_deleted,complain) {. Quindi esegui il contenitore docker, compile e gdb. Il risultato è stato lo stesso: During startup program exited normally.

2. Come suggerito in another answer, dall'interno del contenitore, ho cercato di fare strace -f -o syscall.txt gdb ./a.out, ma ottengo il seguente errore:

   strace: test_ptrace_setoptions_followfork: PTRACE_TRACEME doesn't work: Permission denied 
   strace: test_ptrace_setoptions_followfork: unexpected exit status 1 
   

   ma non capisco come funziona in questo giro. Ho provato ad avviare il contenitore come root: sudo docker run --rm -it gdb_problem_testing bash e poi ho provato lo strace - questo mi ha dato lo stesso errore. Devo ammettere che non capisco come i privilegi dell'utente siano gestiti dalla finestra mobile, cioè quali sono i diritti utente della radice all'interno del contenitore e da chi ereditano i diritti (dal demone docker?). Dato che sono in grado di raggiungere il punto di interruzione, quando eseguo gdb nell'host, sospetto che il mio problema si riduca ai diritti dell'utente, ma non so come affrontarlo.

3. Nell'host ho tentato di eseguire echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope come suggerito in ancora another answer.

Answer 1

tldr; utilizzare

docker run --privileged 

più lunga: ho avuto un po 'di problems with gdb in docker --- si stava tentando (e non) per disabilitare address space layout randomization --- ma solo su docker-machine, non sul mio ospite Linux native.

Quando gdb non è riuscito a disabilitare ASLR, tutti i miei punti di interruzione sarebbero stati ignorati. L'utilizzo del flag --privileged ha risolto il problema. Il tuo chilometraggio può variare.

Answer 2

grazie alla risposta di @rubicks.

e se non è possibile utilizzare l'opzione --privileged (ad esempio, si utilizza un contenitore dalla nuvola), è possibile stampare stacktrace dal programma:

How to automatically generate a stacktrace when my gcc C++ program crashes