Cómo restringir la depuración gdb a un hilo a la vez

pthreads

Question

Quiero depurar un programa de subprocesos múltiples controlando qué subprocesos se ejecutan cuando. Estoy usando C ++ y gdb. Tengo dos subprocesos además del subproceso principal (para el programa de ejemplo) y quiero depurar un subproceso manteniendo el otro detenido.

Aquí está el programa de ejemplo que escribí:

#include <iostream>
#include <pthread.h>
#include <stdlib.h>

#define NUM_THREADS 2

using namespace std;

void * run (void *) {
  for (int i = 0; i < 3; ++i) {
    sleep(1);
    cout << i << " " << pthread_self() << endl;
  }
  pthread_exit(NULL);
}

int main (int argc, char** argv) {
  cout << "Start..." << endl;
  int rc;

  pthread_t threads[NUM_THREADS];
  for (int i = 0; i < NUM_THREADS; ++i) {
    rc = pthread_create(&threads[i], NULL, run, NULL);
    if (rc) {
      cout << "pthread_create returned error: " << rc << endl;
      exit(-1);
    }
  }
  pthread_exit(NULL);

}

Ejecuto gdb y establezco el punto de interrupción en línea con el modo de sleep(1) . Luego corro el programa. Obtengo tres hilos (los hilos 2 y 3 son pthreads) y el programa está en el hilo 2 (esperando en sleep(1) ). Ahora, quiero mantener el subproceso 3 donde sea que esté, y seguir avanzando a través del subproceso 2 (ejecutando c en gdb).

Lo que he intentado es set scheduler-locking on , pero no parece funcionar como esperaba. Estoy en el subproceso 2, set scheduler-locking on , continue un par de veces (hasta ahora bien, todavía estoy en el subproceso 2), cambio al subproceso 3, set scheduler-locking on , continue y, por algún motivo, estoy de vuelta en el hilo 2 ... cuando no debería (según mi entendimiento). ¿Hay algo que este olvidando?

Answer 1

Como dijo TazMainiac, el bloqueo del planificador es útil para un solo paso, pero el "modo" debe establecerse en "paso".

set scheduler-locking step

Puede consultar el enlace proporcionado por TazMainiac que menciona lo mismo:

http://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_39.html

El modo de paso se optimiza para un solo paso. Evita que otros subprocesos "aprovechen el aviso" al hacer un seguimiento del subproceso actual mientras estás avanzando.

Answer 2

Parece que el bloqueo del planificador solo es útil cuando se realiza un solo paso o el siguiente. Una vez que continúes tu hilo actual, todos se ejecutan, y el siguiente hilo para alcanzar un punto de ruptura capturará las indicaciones. Al menos, esa es mi interpretación del manual:

http://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_39.html

Por lo tanto, una vez que esté en el subproceso 3, los otros subprocesos se detendrán, y mientras siga el paso / siguiente, no se ejecutarán. Pero una vez que continúas, todos se ejecutan, y el siguiente hilo (2 en tu ejemplo) que llega al punto de interrupción en el modo de espera (1) capturará el indicador.

Tal vez deje que todos los hilos toquen el sueño, pero luego solo continúe uno de ellos a la vez.