I need to run my client application (written in c++ with gRPC) in an operating system (which only support single thread).
However, I noticed that grpc::InsecureChannelCredentials(); is trying to create multiple threads. Here is the output from debugger after calling that gRPC function in my host machine:
[New Thread 0x7ffff524a700 (LWP 3709)]
[New Thread 0x7ffff524a700 (LWP 3710)]
[New Thread 0x7ffff524a700 (LWP 3711)]
This will cause the program crash inside the single thread OS.
My question is: is there a way to configure gPRC using only single thread, or make cpp executable run only with single thread? Thanks in advance.
btw, here is the link to the os mentioned above and the issue explains why it only support single thread.
https://github.com/lsds/sgx-lkl/issues/1
EDIT:
It's actually not allowing multi-process instead of multi-thread applicaiton. gRPC seems like doing fork inside its core lib. I'm wondering if there is a way to configure gRPC to disable process forking.
Related
Just want to ask is there any method to check if a 3rd API will create a new thread for c/c++ program in linux? As following, assume do_something_API is a 3rd API and we don't know the implementation, then how to know if the funciton will create a new thread? Use gdb or other tools?
int main() {
...
//call 3rd party API
do_something_API();
...
}
how to know if the funciton will create a new thread?
Just stop at do_something_API() line in main function in gdb and use next command once to execute do_something_API() function. If that function creates any new threads, you will see messages from gdb like:
[New Thread 0x41e02940 (LWP 25582)]
See in documentation:
Whenever GDB detects a new thread in your program, it displays the
target system’s identification for the thread with a message in the
form ‘[New systag]’, where systag is a thread identifier whose form
varies depending on the particular system. For example, on GNU/Linux,
you might see
[New Thread 0x41e02940 (LWP 25582)]
how to know if the funciton will create a new thread?
You may have an XY problem. What are you actually trying to achieve?
Read the documentation or ask 3rd party developer. If they promise to never create threads, then that's the answer. Otherwise, assume that they may (if not in the current version, then in the next one).
You can run nm libsomething.{a,so} | grep pthread_create and strings libsomething.{a,so} | grep pthread_create. If both commands produce no output, you can be pretty sure that the current version of the library will not create new threads.
If you run the test program under GDB, and next over the do_something_API() call, GDB will report new thread creation with messages similar to [New thread ...]. If you don't see such messages, no new thread was created.
You could also set a breakpoint on pthread_create, or use info thread before and after the call.
Note: if no new threads are created, this is a very weak indicator: do_something_API() may decide whether or not to create new threads depending on runtime environment (e.g. an environment variable, or current directory, or time of day), and so the next time you run the test the answer may change.
you can try running your code in gdb and use "info threads" to see the all running threads within your program.
or you can also check using /proc/
got some big real time project to deal with (multiple processes (IPCs), multi Everything in short).
My working on process is started as service on Linux. I have the root access.
Here is the problem:
I'm trying to attach to a running proc, tried starting it through/with gdb but the result is the same: it stops the executable once I "touched" it with gdb or sometimes it throws:
Program received signal SIGUSR1, User defined signal 1. [Switching to Thread 0x7f9fe869f700 (LWP 2638)]
of course from there nothing can be done.
Tried:
handle all nostop
attach to launched as service (daemon) or launched as regular proc
started from gdb
thought maybe forking/multi-threaded problem - implemented in the very beginning sleep for 10 seconds - attached to it with "continue"
Guys, all I want it is to debug, hit the breakpoints, etc.
Please help! Share ideas.
Editing actual commands:
1) gdb attach myProcId. Then after reading symbols, I hit "c" which results:
Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x7f9fe869f700 (LWP 2638)]
0x00007f9fec09bf73 in select () from /lib64/libc.so.6
2) If I make the first line 10 seconds sleep in the code, attaching to the process, hit "c", result: it runs, shows info threads, backtrace of main, but never hits the breakpoint (for sure the code runs there - I get logs and different behaviour if I change code there), meaning the process is stuck.
3) All other combinations like gdb path/to/my/proc args list, then start. Where arg list played with different related options gdb gives us.
Maybe worth to mention: process network packets related, timers driven also.
But for me the important thing is a current snapshot on break, i don't care what will happen to the system after timers expired.
Since you mentioned that you are debugging a multiprocessing program, I think the underlying program you have is to set the breakpoint in the correct subprocess.
Try break fork and set follow-fork-mode child/parent. What you want to achieve is have gdb attached to the process that is running the code you want to debug.
Refer to this link.
Another thought is to generate a crash, since you can compile the programe. For example add a int i = *(int*)NULL and that will generate a core dump. You can then debug the core dump with gdb <program> <core dump>. You can refer to this page for how to configure core dump.
I am trying to debug my ros code in gdb, how ever, when I start the node in gdb, it always gives me:
Starting program: /home/uav/catkin_ws/devel/lib/my_package/my_node
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-
gnu/libthread_db.so.1".
[New Thread 0x7ffff13b9700 (LWP 28089)]
[New Thread 0x7ffff0bb8700 (LWP 28090)]
[New Thread 0x7fffebfff700 (LWP 28091)]
[New Thread 0x7fffeb7fe700 (LWP 28096)]
[New Thread 0x7fffeaffd700 (LWP 28098)]
[New Thread 0x7fffea7fc700 (LWP 28121)]
and hangs forever. I don't see this issue before and have no clue why it always start in multi-threads mode. My main function looks like this:
int main(int argc, char** argv)
{
ros::init(argc, argv, "my_node");
ros::NodeHandle nodeHandle("~");
ros::Rate rate(10);
while (ros::ok()) {
// Do Something
ros::spinOnce();
rate.sleep();
}
return 0;
}
How can I fix this problem? I am thinking I should make my node to a single thread version and debug it, how am I supposed to do that?
There are two ways to talk about multithreading in ROS.
The whole node
The callbackQueue.
In the first case, when you use:
ros::NodeHandle nodeHandle("~");
ros::ok()
...
It does some requests to the ROS Master. And with roscpp the network communication is handled with multithreading. There is no way to change that. If single threading is very important for you, you should try rospy, rosnodejs or others.
"roscpp does not try to specify a threading model for your application. This means that while roscpp may use threads behind the scenes to do network management, scheduling etc., it will never expose its threads to your application."
In the second case, we talk about handling topics, services and actions with multithreading. By default, a topic is handled with one thread. But if you send more data that your node can handle it, you can use multithreading.
"roscpp does, however, allow your callbacks to be called from any number of threads if that's what you want."
For mode details, see:
http://wiki.ros.org/roscpp/Overview/Callbacks%20and%20Spinning
Is there a way to schedule a task to be executed in the Windows main loop. I don't want to create a Windows and send an event to it.
With libdispatch I can do it with:
dispatch_async_f(dispatch_get_main_queue(), ...)
Or is there a thread in the Windows Thread Pool associated with the program's main loop?
Background:
Currently I am in the process of developing a CSP (Communicating Sequential Processing) library and most of the time tasks can be executed by the Thread Pool. But sometimes there is the need that a task is executed in the main loop. I have already a solution, if the application under Windows is a Qt application. But for non Qt applications under Windows I would like to have a solution as well.
On Windows each message loop is associated with a single thread. You can have more than one message loop per application if this is what you ask.
If I have some multithreaded process and want to trace it with gdb using attach command, to which thread it will connect (e.g. current running or main)? I know that I can discover it with info threads but I want to know which thread it will choose by default.
For Linux, all of the threads are stopped by the ptrace command when gdb attaches.
It has been my experience that gdb defaults to the main thread for C/C++ applications. If you attach to a process and do a 'bt' it will list the stack for 'main'.
Information is available for all threads however. gdb can look at the thread(s) information in the /proc filesystem. The proc contains information about each thread in the tasks area. Details about the stack address is located in the stat file as well as the maps file. Details are also available regarding the register values for each thread.
Along the lines of your question, I've often wondered why stepping through a multithreaded application will cause gdb to jump from thread to thread. I think that gdb is still at the mercy of the kernel scheduler so that a step on a thread may lead to a different thread getting the CPU resource and a breakpoint being triggered.
On Linux, where thread ids exist in the same space as process ids, it appears you can run gdb -p tid to attach to the thread with given tid and its owning process, without knowing the pid. Because the main thread of a process has tid == pid, it makes sense that running gdb -p pid connects to the main thread.
Example code that connects gdb to the currently executing thread, e.g. for generating a pretty stack trace: https://github.com/facebook/rocksdb/pull/11150