41

I want to debug a multi-threaded program by controlling which threads execute when. I am using C++ and gdb. I have two threads besides the main thread (for the example program) and I want to debug one thread while keeping the other stopped.

Here is the example program I wrote: 

#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);

}

I run gdb and set the breakpoint at line with sleep(1). Then I run the program. I get three threads (thread 2 and 3 are pthreads) and the program is at thread 2 (waiting at sleep(1)). Now, I want to keep thread 3 wherever it is, and keep stepping through thread 2 (by executing c in gdb).

What I have tried is set scheduler-locking on, but it does not seem to work as I expected. I am in thread 2, I set scheduler-locking on, continue a couple times (so far so good, I am still in thread 2), switch to thread 3, set scheduler-locking on, continue, and for some reason, I am back in thread 2... when I should not be (according to my understanding). Is there something I am missing?

Prashant Kumar
  • 20,069
  • 14
  • 47
  • 63
Yogeshwer Sharma
  • 3,647
  • 5
  • 25
  • 27

2 Answers2

29

As TazMainiac said, scheduler-locking is useful for single stepping, but the "mode" must be set to "step".

set scheduler-locking step

You can refer the link provided by TazMainiac which mentions the same:

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

The step mode optimizes for single-stepping. It stops other threads from "seizing the prompt" by preempting the current thread while you are stepping.

Rahul Sreeram
  • 441
  • 4
  • 8
  • 1
    In my environment looks like set scheduler-locking on works, but set scheduler-locking step doesn't work. I'm using GNU gdb (GDB) SUSE (7.1-3.12) – Bai Bing Oct 09 '19 at 09:37
15

It looks like scheduler-locking is only useful when you single-step or next. Once you continue your current thread, they all run, and the next thread to hit a break point will grab the prompts. At least, that's my interpretation of the manual:

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

So, once you are in thread 3, the other threads are stopped, and as long as you step/next, they will not run. But once you continue, they all run, and the next thread (2 in your example) that hits the break point in the sleep(1) will grab the prompt.

Maybe let all the threads hit the sleep, but then only continue one of them at a time.

TazMainiac
  • 364
  • 2
  • 5
  • Thanks for the link... it turns out that even when I `next` after `set scheduler-locking on` in thread 3, it still transfer control back to thread 2. (It does not if I `step`, but it very painful to step through every instruction in library code.) Is there any command other than `set scheduler-locking on` that does the trick? – Yogeshwer Sharma Jul 17 '11 at 05:53
  • There does not seem to be a better way, and you clarified the issue. So, accepting this answer. – Yogeshwer Sharma Jul 24 '11 at 04:45
  • 2
    Using `set scheduler-locking on` is said to be OS dependent. Seems to work fine on my system though (Linux 4.4.0 kernel, gdb 7.11.1, Ubuntu 16.04) – Jan Wielemaker May 17 '17 at 11:42