I am building an application for Beaglebone Black using Netbeans running on a PC using remote compilation and debug. The debug has been straightforward up to this point, but I am now trying to sort out my serial comms. My serial code uses a signal to indicate data reception, and Netbeans halts my code to inform me of the signal. It offers 3 options: Discard and Continue, Discard and Pause, Forward and Continue. I want none of these! I want no notification of the signal at all, I want it to be handled by my code.
The options in Project Properties/Debug/Signals are to set them to Ignore (the program no longer responds to them) or Catch (pop up an annoying dialog that breaks my comms protocols). Is there is a way to get Netbeans to just carry on running as it ought to?
Related
I'm using a 3rd party library that sends an interrupt from a separate thread in the kernel (RHEL 7.9) to an interrupt handler that I am trying to debug. I'm not able to get gdb (in Eclipse 4.11.0, CDT 9.7) to stop in my interrupt handler. I'm not even able to use std::cout to print out anything inside my handler.
The vendor uses Visual Studios and is able to get the debugger to stop in his interrupt handlers but wasn't familiar enough with gdb or Linux to know if it's possible with gdb.
I've been able to get other interrupt handlers from this same library to work but am having trouble with a specific handler that I'd like to step through so that I can figure out why it's not working properly.
Is there some setting or some step that I'm missing so that I can properly walk through my interrupt handler? Maybe a different technique to try to follow along with what is actually going on inside my interrupt handler?
Edit: I've tried using std::cout to print values I'm interested and outputting to a text file but neither have worked.
Hello dear Communauts,
I'm am creating a terminal animated status report for a parallel software I'm developing. I'm using NCurses.
I'm having an issue related to the restoring of the standard behavior of the terminal.
After running my software the terminal keeps having just 24 lines, no matter if I call endwin() or I don't.
Here the simplified code:
int size=10;
initscr();
refresh();
while(KeepAlive){
int j=1;
mvprintw(j,0,/*Blah blah header*/));
for(int i=0;i<size;i++){
j++;
mvprintw(j,0,/*Some blah blah*/);
}
refresh();
usleep(1000000);
}
endwin();
KeepAlive is a control variable changed by another thread (so the while is not infinite loop, but controlled loop).
After running this software my terminal has only 24 lines, echo works, but there's plenty of blank space.
Thanks a lot for your help, have fun
EDIT:
I would like to share with you some information I found while attempting to solve my issue:
curses (ncurses) is perfectly working under openMP, then you can imagine some threads doing your math calculations and one thread (only one, be aware) giving out some runtime infos.
curse (ncurses) is NOT compatible with MPI. Well, the right stating would be is "not completely" compatible with MPI. MPI is really sophisticated about stdin/stdout/stderr, since all outputs from all MPI-processes could be redirected to a display (which could be specified). Using any advanced terminal output overriding library will take to a fault of the code, or unexpected behaviors.
That's supported by the MPI faq:
Maybe. But probably not.
Open MPI provides fairly sophisticated stdin / stdout / stderr forwarding. >However, it does not work well with curses, ncurses, readline, or other >sophisticated I/O packages that generally require direct control of the terminal.
Every application and I/O library is different -- you should try to see if yours >is supported. But chances are that it won't work.
Sorry. :-(
found here (MPI reference).
What I've discovered is that even if you appoint only one MPI-process to manage all the curses output (just that process calls initscr() at the beginning and endwin() at the end of his part of code) there is no way to force curses to use the full terminal (only default UNIX 24x80 will be available).
Once MPI has been finalized your whole terminal will keep working in 24x80 mode until reset is called.
Thanks to all communauts that helped me,
Have fun
gf
One possible solution is to completely decouple your text GUI from the rest of the MPI code and make both parts talk to each other via the client/server mechanism of MPI-2. That means:
Run the GUI as singleton MPI program, i.e. one that calls MPI_Init{_thread} but is not started via mpiexec. It then should open a listening port by calling MPI_Open_port. The call returns a string port name that has to be supplied to the compute part of the application. The GUI part should then start listening for connections by calling the blocking MPI_Comm_accept.
The compute part is started as usual via mpiexec. It should connect to the GUI by calling MPI_Comm_connect given the port name from (1).
The combination of MPI_Comm_accept in the GUI and MPI_Comm_connect in the compute part establishes an intercommunicator that can be used for sending messages between the two parts. The compute part could e.g. send periodic status messages to the GUI. If necessary, the intercommunicator could be further "flattened" to an intracommunicator.
Once the computation is finished, the communication part should disconnect by calling MPI_Comm_disconnect.
The GUI should call MPI_Close_port and finish its own execution.
In that scenario, the GUI part could be a text mode curses application started locally or remotely via SSH, an X11 GUI application, or whatever else there.
It should work. The comment about "parallel" suggests multithreading, which can mean that your output is not flushed as one might expect.
Likely this is the same issue (Ncurses limited output size) for which more information was given. Neither question provides enough detail to offer more than generic advice.
Background: I am writing a QA automation platform for an API which outputs formatted results to a specified directory. In addition, I have developed a GUI application for analyzing these results. A user may run the second application trying to analyze test results while our automated build system is running the first application modifying / generating new test data. To avoid thrashing, I have each application acquire file locks when making modifications, and releasing them when they are done. Upon normal program termination, if the running application has acquired a lock on the data directory it is released.
Problem: I need to be able to release the aforementioned file locks when either tool exists prematurely (user pressing CTRL-C, user stopping the application in debugger, or due to buggy API / application logic being tested). To handle this, I have implemented a signal handler using sigaction which handles intercepting fatal signals (tested and working), and have implemented a ctrl-c handler via the Win32 function SetConsoleCtrlHandler. However, I cannot seem to find a way to intercept the event of a user pressing the Stop Debugging button in Visual Studio. I assume this event generates something like SIGKILL / SIGSTOP (which cannot be handled through sigaction) but I would also hope there is some std library or Win32 functionality to intercept this event and perform some cleanup. Do you guys know of a way to handle this event or even what exactly this button does to kill a running application?
If you're using boost, you can use boost::interprocess::windows_shared_memory.
It is guaranteed to be released when the process ends.
Boost is just a neat wrapper around the windows API in this case. It wraps the Windows Named Shared Memory API.
I want to make some debug console for my application. It should output some data and take input commands. How can I do this? The best way is updating console like: drawing information and prompt for input after the data.
I'm developing under Linux. For example, gdb could take input from console.
If you're familiar with socket programming (or actually, any other kind of IPC mechanism), you might want to enable some listener within your application, and develop an external application that will do all the "console" stuff for you, while communicating with the main application.
Let's suppose you have an application that has a single button and a single text label, and every time you press that button - the text label goes up by 1, from 1 to 2 to 3 etc.
You can build a socket listener into that application. When the socket listener accepts a new incoming connection, you'd start a connection thread that can:
Receive a "shutdown" command
Receive a "reset counter" command
Send an update regarding the current count on every click
etc.
Then you build another, external application, which connects to the main application, and sends messages to it, based on console input it gets from the user. It would also listen to incoming updates and show them to the user.
Using an external application for debug-controlling your main application is extremely helpful, with the following reasons being some of the advantages:
No matter how the debug application is buggy, it cannot hurt the release version of your main application.
All the code that deals with the console management, which is redundant to your main application, can be kept outside of the main app.
Making two projects out of it can make it easier to collaborate your work with someone else, as long as you are both aware of the protocol between the two sides.
Implementing what I suggested means you can debug your application remotely, in case you don't have access to the main application (for example, if it's on a customer site).
I overloaded the 6 signals listed on this site http://www.cplusplus.com/reference/clibrary/csignal/signal.html
Then i ran my app (double click not ran through IDE) and tried 1) end task 2) X on topright and 3) kill process. I expected the first two to cause some kind of signal (i am on XP) but alas i got nothing. Am i not allowed to open files to write into when a signal occurs? i am guessing i am (SIGSEGV allowed me).
When firefox crashes or when i kill it, it remembers what pages i was. Does it log the address everytime i click a page or does it do that on a signal/crash?
my main question is what signal can i use to catch kill process
Win32 does not provide an option to intercept your program being killed with TerminateProcess (which is what will happen when you "End Task" from Task Manager or click on the [X]).
You can catch the SIGSEGV signal because the C runtime library provides an emulation of this signal when running on Windows. When your program causes a Windows access violation (exception 0xC0000005), the runtime library has the option to catch that and simulate a Unix style SIGSEGV for you. This is, however, not the best way to handle such an exception. If you are writing a Win32 program, you shouldn't generally try to use Unix style services.
You can catch runtime error like an access violation if you override the default exception handler calling SetUnhandledExceptionFilter (this is a win32 function and as such doesn't rely on C library emulation). This is the method can used to provide "minidumps" when a program crashes.
But this exception handler will not be called when you normally close your application, or when your application is closed from Task manager. In the last case windows is calling TerminateProcess, is not a clean shutdown but it is forcing your program to terminate.
I'm not aware of which is the implementation used by Firefox, but to save the current tabs open is likely to have a timer running, and each time it is run it save the history to a file and some kind of dirty mark.
Other more complex solutions to detect when a program is closed (implemented by antivirus and similar programs) is to have two unrelated programs running, each checking that the other is still running, and if one detect the other was closed the run it again.
Windows apps are either console apps or GUI apps. Console apps tend to get WM_CLOSE, console apps CTRL_CLOSE_EVENT. Neither are signals; neither would be sent if your app is ended via TerminateProcess().
If you want to store where you were, use a memory-mapped file and update that on every action. When your process exits, the dirty page in memory is written back to file by the OS, possibly at other moments too. This solution allows the OS to manage disk I/O for you, and it's in a better position to do so.