I've written a simple IRC-proxy for a single client with a built-in bot.
It spawns two threads, one reading from the client and feeding the server and the other doing the oppisite.
So far it works correctly. But if I put a breakpoint within the run()-methods of the thread-object, the IDE will never stop there. Breakpoints in the main-thread stop correctly.
What am I doing wrong here?
You have the change the suspend policy for breakpoints to thread as documented here.
You would do this like so:
The following shows usage of the thread suspend policy. Notice how the Console does not have anything printed on it and also that ALL the threads have stopped on the breakpoint:
The following shows the same breakpoint with the default Suspend All policy and how changing it to Thread on-the-fly results in stopping any threads that hit that breakpoint after that change:
Related
I have a C++ application on Mac OS X. The app runs an event processing with the glfw library on the main thread and reads input and execute commands on a background C++ std::thread.
I am observing a frustrating phenomenon that I cannot explain so far.
If I make a call to a long running function on the background thread, initially that thread is using 100% of a core. But, after it has used a few seconds of CPU (10 seems to be the magic threshold), it gets throttled down to 25%.
If I start a computation run on a thread in the background before starting the glfw event processing loop (the event processing is essentially stuck waiting for events, as I don't even open a window), then it can use 100% for as long as it wants.
My biggest problem is that I have no idea what could be causing this nor how to figure it out. I've tested retrieving the pthread sched_param and changing the sched_priority from what seems to be default 31 to various values between 20 and 60 and it does not help.
I have identified one more condition for the phenomenon to happen:
The background thread has to have read from the terminal. It happens when I run the following background thread and enter a line for the computation to take place:
std::thread cmd([argc, argv, &scriptingRunner] {
for (std::string line; std::getline(std::cin, line); ) {
longComputation();
}
Perhaps App Nap is throttling your application to save energy. To check, open the Activity Monitor program and right-click on the header of the processes table to bring up the context menu, and click on "App Nap" in the context menu to enable the App Nap column; then look at your process in the table and see if its value in the App Nap column switches to "Yes" when the fault occurs.
If you want to disable app nap for your app, see the code listed in the question here.
my problem is the following: In my Flask-Restx-Application I created a Runner-Thread which runs asynchronously to the main-thread of the Flask-Application.
Now when I do changes as usual the Debugger still shows * Detected change in 'XXXXX', reloading which is a useful feature. The problem is that now it got stuck and cannot reload because of the running Thread which must be stopped manually.
I would still like to use the automatic reload if possible in combination with the asynchronous Runner-Thread. Is there a possibility to "detect" those reloads by triggering an Event or something similar? Then I could manually shutdown the Runner-Thread and restart it with the application. Or is there at least a possibility to not block the reload in order to proceed reloading the flask-restx-related stuff?
Thanks in advance for any help.
PS: I find it hard to add code here because I do not know which parts of the flask-app are important. If you need any code to answer the question I will add it in an Edit.
You need to make your thread a daemon thread if you want the reloader to work. The reloader will try to kill and restart the program (by killing the main thread), but because your other thread is not a daemon, it will fail to kill the program and reload it. A daemon thread is one that only lives as long as the main thread lives, and therefore making your other thread a daemon will fix your issue. Here is an example:
from threading import Thread
...
t = Thread(...)
t.daemon = True # this makes your thread a daemon thread
t.start()
I am relatively new to IntelliJIdea. I am running version Ultimate 2019.2.
I am doing a multi-threaded debugging and it seems like IntelliJ suspends all threads once one of the breakpoints got hit. This means, at a given time I can work with one breakpoint only, I do not have the visibility into how my multi-threaded app is behaving.
In Eclipse I would see all suspended threads and I could've worked with any breakpoint I wished in any of suspended threads.
How can I configure smth like that in IntelliJ?
I have seen that I can select a breakpoint and then select a behavior for it: stop all threads or stop only a thread on which it was invoked. That's nice.
But I do have several dozens of breakpoints and I do not want to go back and change that behavior for each breakpoint separately. Can I configure this behavior globally??
Pls, advise. This is super annoying.
Alright, I have figured it out: when changing suspension behavior for a given breakpoint, there is a button Make Default that allows setting this behavior for all new breakpoints created after the change. Breakpoints created before the change will have their behavior unchanged.
One of my threads entered the debugger. I want to switch to it, expect that stacktrace, choose a restart, etc... How can I do that?
I am using bordeaux-threads.
If you use SLIME, it should work automatically. Otherwise it depends on your implementation. In SBCL, (SB-THREAD:RELEASE-FOREGROUND) should let the other thread use the terminal.
SBCL manual, 12.8 Sessions/Debugging
Within a single session, threads arbitrate between themselves for the user's attention. A thread may be in one of three notional states: foreground, background, or stopped. When a background process attempts to print a repl prompt or to enter the debugger, it will stop and print a message saying that it has stopped. The user at his leisure may switch to that thread to find out what it needs. If a background thread enters the debugger, selecting any restart will put it back into the background before it resumes. Arbitration for the input stream is managed by calls to sb-thread:get-foreground (which may block) and sb-thread:release-foreground.
I'm handling a program which controls a car.
The program has a pretty large scale and it was made by other people.
So I don't understand completely how it works.
But I have to apply it and make a car moving.
The problem I'm facing is that the program often stalls with no error, no segmentation.
If it crashes, I can trace the cause with gdb or something like that.
But it does not crash, it silently stops.
How can I find the cause?
From your description - program silently stops - I understand that your program simply and gracefully exited, but not from your expected flow. This can happen for many reasons - for example, maybe your program enters illegal flow and some sub-component, such as standard library or other library decide that program should exit, and thus calls c-runtime exit() or directly calls Kernel32!ExitProcess().The best way to debug this flow is to attach a debugger and set a breakpoint on these two methods and find out who is calling them.If you mean your program enters a deadlock and halts then also you will need to attach a debugger and find out who is stuck.