I am debugging a multi threaded application using ddd.
At the same time each second I can see on DDD console out that a new thread is created
[NewThread 0x455fc940 (LWP 27373)]
and destroyed immediately after it.
[Thread 0x455fc940 (LWP 27373) exited]
After few minutes I have this text out
[NewThread 0x455fc940 (LWP 27363)]
[Thread 0x455fc940 (LWP 27363) exited]
[NewThread 0x455fc940 (LWP 27367)]
[Thread 0x455fc940 (LWP 27367) exited]
[NewThread 0x455fc940 (LWP 27373)]
[Thread 0x455fc940 (LWP 27373) exited]
...and so on..
with this LWP increasing.
The threas comes and go too fast to be displayed using the window I got clicking on Status->Thread. Can you address me a bit about how to get information about that thread?
Do you know why this LWP is increasing all the time?
More important how to get the function that is lunched into that thread?
Thank you all
AFG
LWP is an acronym and stands for Light Weight Process. It is in effect the thread ID of each newly spawned thread.
On what to do about those spawning and dying threads: you could try set a break point at clone, which is he system call (? am I correct?) which starts a new thread at a given function.
Note: When breaking at clone you know from where the thread will be started, but don't actually have a thread, you can then however set break points at the functions given as argument to clone...
That is, start your program from gdb or ddd with the start command, which sets a temporary break point at the program entry point (i.e. main), than set a break point at clone, continue and see what happens ;).
Update: setting a break point at clone works for me... at least in my test. I should add that this is linux specific - and is actually what pthread_create uses.
Set a breakpoint at pthread_create.
(gdb) break pthread_create
Breakpoint 1 at 0x20c49ba5cabf44
Now when you run it, it will stop execution when the next call to create a thread happens, and you can type where to see who the caller was.
Related
I'm debugging a multi-threaded C++ application in Eclipse Oxygen with gdb 7.4
The default behaviour is that when a breakpoint is reached all threads are halted, however, I'd like only the thread that reached the breakpoint to halt and all others would continue to run.
How is possible?
How is possible?
(gdb) set non-stop on
By default non-stop mode is off. You want it to be on, see gdb builtin help:
(gdb) help set non-stop
Set whether gdb controls the inferior in non-stop mode.
When debugging a multi-threaded program and this setting is
off (the default, also called all-stop mode), when one thread stops
(for a breakpoint, watchpoint, exception, or similar events), GDB stops
all other threads in the program while you interact with the thread of
interest. When you continue or step a thread, you can allow the other
threads to run, or have them remain stopped, but while you inspect any
thread's state, all threads stop.
In non-stop mode, when one thread stops, other threads can continue
to run freely. You'll be able to step each thread independently,
leave it stopped or free to run as needed.
(gdb)
I have a nodejs application that gets data from one server and pushes into another. For testing I sent 1000 requests to my node server and saw what happens on the system monitor. There I could see that all 4 processors were 100% occupied.
Now, from what I have read on nodejs, it seems that it by default uses only 1 thread(which means 1 processor?). But how come all my computer's processors were occupied? Is this load balancing happening at OS level(I am on ubuntu 14)
And in case the balancing was done by OS then what is the difference between this automatic OS level load balancing and explicitly using clusters to divide the load? What are the advantages/disadvantages of each?
Any help would be deeply appreciated :)
Though the application is driven by a single thread, there are helper threads inside node to facilitate the execution within the runtime environment. Examples are JIT compiler thread and GC helper threads. Though they wont consume CPU in proportion to the application load, they will be driven by the characteristics internal to the virtual machine.
Hooking onto a live debugger shows how many threads are there any what they are doing:
gdb) info threads
6 Thread 0x7ffff61d8700 (LWP 23181) 0x00000034d080d930 in sem_wait () from /lib64/libpthread.so.0
5 Thread 0x7ffff6bd9700 (LWP 23180) 0x00000034d080d930 in sem_wait () from /lib64/libpthread.so.0
4 Thread 0x7ffff75da700 (LWP 23179) 0x00000034d080d930 in sem_wait () from /lib64/libpthread.so.0
3 Thread 0x7ffff7fdb700 (LWP 23178) 0x00000034d080d930 in sem_wait () from /lib64/libpthread.so.0
2 Thread 0x7ffff7ffc700 (LWP 23177) 0x00000034d080d930 in sem_wait () from /lib64/libpthread.so.0
* 1 Thread 0x7ffff7fdd720 (LWP 23168) 0x00000034d04e5239 in syscall () from /lib64/libc.so.6
(gdb)
I created a thread from main and detach it from main thread.
I want to kill this thread when it is in progress state.
I tried std::terminate() But it kill whole process . This thing i didn't want.
I want to kill that progress thread and start another thread in C++.
Please help me to solve this for std::thread.
This is part of my core file:
[New Thread 30385]
[New Thread 30383]
[New Thread 30381]
[New Thread 30379]
[New Thread 30378]
[New Thread 30270]
[New Thread 30268]
Core was generated by `test'.
Program terminated with signal 11, Segmentation fault.
#0 0x001cd1a6 in ?? ()
Does it mean my program crashes at 0x001cd1a6 or the program crashes while trying to read/write to that address?
There is no executable code at that address.
Another thing is it gives a different address every time it crashes.
Does it mean my program crashes at 0x001cd1a6
Yes.
There is no executable code at that address.
Well, that would certainly cause a crash (due to illegal instruction).
Another thing is it gives a different address every time it crashes.
Your program has threads, so its allocation pattern is likely different every time it runs, as threads are scheduled differently.
Also, Linux uses address randomization, so if you run even non-threaded program multiple times, you'll end up with different addresses. On the other hand, GDB disables that randomization, so if you run non-threaded program under GDB, it should crash in the same place every time.
You are likely calling a virtual function on an object that has been invalidated (e.g. deleted). Use where GDB command to find out how you end up on invalid address.
Also, don't ever call your executable test on UNIX: this conflicts with /usr/bin/test, which many shell scripts will use.
I have a program which uses two threads. I have put the break point in both the threads. While running the program under gdb I want to switch between the threads and make them run.
(thread t1 is active and running and thread t2; when paused on the breakpoint. I want to stop T1 running and run the T2).
Is there any way that I can schedule the threads in gdb?
By default, GDB stops all threads when any breakpoint is hit, and resumes all threads when you issue any command (such as continue, next, step, finish, etc.) which requires that the inferior process (the one you are debugging) start to execute.
However, you can tell GDB not to do that:
(gdb) help set scheduler-locking
Set mode for locking scheduler during execution.
off == no locking (threads may preempt at any time)
on == full locking (no thread except the current thread may run)
step == scheduler locked during every single-step operation.
In this mode, no other thread may run during a step command.
Other threads may run while stepping over a function call ('next').
So you'll want to set breakpoints, then set scheduler-locking on, then continue or finish in thread 1 (thread 2 is still stopped), then Ctrl-C to regain control of GDB, switch to thread 2, continue (thread 1 is still stopped), etc.
Beware: by setting scheduler-locking on it is very easy to cause the inferior process to self-deadlock.
If you're using GDB 7 or later, try "non-stop mode".
http://sourceware.org/gdb/current/onlinedocs/gdb/Non_002dStop-Mode.html
The "scheduler-locking on" command previously mentioned allows you step one thread with the others stopped. Non-stop mode allows you to step one thread with the others active.
use break conditions
(gdb) break frik.c:13 thread 28 if bartab > lim
see Debugging with GDB
Edit:
(gdb) break <thread_function_entry_point> thread 2
(gdb) break <thread_function_entry_point> thread 1
(gdb) thread 1
(gdb) continue
(gdb) ... thread 1 finishes
(gdb) thread 2
(gdb) continue
You can put these commands inside a .gdbrc file.