1

In a C++ application I have 2 threads (thread1 and thread2) from the same class. They are running a loop very fast and nothing should made any blocking calls inside the loop:

while (!end) {
  //dostuff, no blocking!
}
cout << "ended" << endl;

There is some bug in the application, because when I run only one thread at a time, and I set its end property, it can quit from the loop successfully.

However, if I run both threads, sometimes one of the threads is not able to break out from the loop (in spite of having its end property set).

The loop itself is quite big (few hundred lines), I can put a (conditional)breakpoint into it, but when I'm stepping, I lose the functionality (as the thread should run fast), so even if I found which line blocks, it might be the wrong way.

So, my question: is there any option in gdb for having a breakpoint which behaves like a watchdog? I.e: it should break the thread if withing a certain time it won't be hit, so I can check which line causes the trouble.

Daniel
  • 2,318
  • 2
  • 22
  • 53
  • What is the declaration for `end`? Is it `atomic`? – 1201ProgramAlarm Apr 18 '20 at 20:30
  • 2
    If your thread is getting blocked then perhaps simply breaking in is going to lead directly to the point of blocking, isn't it? From this vague problem description it seems that there is some sort of race condition rather than blocking call. So you should probably check whether variables are properly synchronized, that `end` condition is not some `volatile` and so on. – user7860670 Apr 18 '20 at 20:30
  • As user7860670 suggests, why don't you just break in gdb, when you recognize that a thread blocks? You can do a multiple break/continue cycle to check whether it always blocks at the same spot. – geza Apr 18 '20 at 20:39
  • end is atomic, yes, and not `volatile` – Daniel Apr 19 '20 at 05:25
  • attaching gdb is not necessary because I'm running it via gdb from start. – Daniel Apr 19 '20 at 05:26
  • is it possible to break only one specific thread? – Daniel Apr 19 '20 at 05:28

1 Answers1

0

I.e: it should break the thread if withing a certain time it won't be hit, so I can check which line causes the trouble.

You don't need this functionality to check which line causes trouble (and the functionality doesn't exist).

Wait for the "not exiting" condition to happen, and hit Control-C. GDB will stop all threads of the process, and give you the (gdb) prompt. At that point, issue thread apply all where command, and you will see where the "not exiting" thread is stuck.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • yes, but the thing is that gdb is not able to suspend this blocking thread. When I try it it times out, then the thread suddenly goes away. Is this valid? – Daniel Apr 19 '20 at 06:42
  • You could try interrupting the process being debugged manually from a terminal using `kill -INT ` . You might also want to read [this post](https://stackoverflow.com/questions/5857300/gdb-ctrlc-doesnt-interrupt-process-as-it-usually-does-but-rather-terminates-t). – G.M. Apr 19 '20 at 08:42