In a ColdBox application I have this code in my main handler's onException function:
getModel('JVMUtils#cbcommons')
In the past month I've seen this throw the error that it can't find it 17 times. During the same time, the application has (sadly) had hundreds if not thousands of unhandled exceptions that hit the onException handler and this particular line of code and didn't die from not finding the component.
What could cause it to find it nearly every time, but not on these rare occasions?
Related
I have a VB.NET WinForms application which calls a video display subsystem written in Native C++. (DirectShow)
After a number of sessions rendering several video files, the application simply exits, without any indicators as to why.
There is no exception, unhandled or otherwise.
As best I can determine from log file records, the application exits when it should be at an idle state, waiting for the next window action (button click) on the form.
There is a Forms_Closing event handler, but it never seems to be called.
The problem is intermittent, and rare. I suspect some kind of memory corruption in the C++ Native code might be the cause.
How can I hook the method which is calling the "Application.Exit" processing?
Is there some other way to determine where the call originates which shuts down the application?
I have a problem and I have done several day's worth of research but found no answer.
I have a c++ application that controls Excel programmatically. Specifically I use VS2017 and MS Office 2019.
To cut a long story short, I don't seem to have away to get feedback from Excel on its status and its readiness to receive a command from my application. As a result if Excel is busy and my application sends a command, there is a memory leak in the application leading it to crash.
In particular I am using Microsoft's Autowrap function to send commands to the com interface.
The relevant block of code is this:
{
VARIANT hresult;
VariantInit(&hresult);
try{
AutoWrap(DISPATCH_PROPERTYGET, &hresult, xlApp, L"ActiveCell", 0);
}
catch (...)
{
std::wcout << "crashed!" << '\n';
}
xlActiveCell[book - 1] = hresult.pdispVal;
}
There is actually nothing wrong with that code. It works fine in 99% of the cases. The problem is that if I click repeatedly on an excel cell with high frequency (double click for example), Excel is busy processing the first click when my App sends the next query 500ms later to get the active cell, and at that point Autowrap throws a message window saying:
IDispatch GetIDsOfNames("ActiveCell") failed w/err 0x80010001
I researched into this and this error means RPC_E_CALL_REJECTED.
it seems obvious that if the above condition occurs, it should be handled and the method calling Autowrap should return empty handed but not crash the application.
Somehow I cannot find a way to do this. try/catch block doesn't seem to do anything, and I cannot modify Autowrap to not open a message window but instead just return with an error to be handled later. It seems that Autowrap is made to stop execution of everything if it hits this error.
Why? Is there no way around this? Am I missing something?
Hello I am looking for a signal for gtkmm. Basically I am doing some simulations and what I want is something like this :
I assume I do 5 simulations :
progressBar.set_fraction(0);
1 simulation
progressBar.set_fraction(progressBar.get_fraction()+1/5)
2 simulation
progressBar.set_fraction(progressBar.get_fraction()+1/5)
3 simulation
progressBar.set_fraction(progressBar.get_fraction()+1/5)
4 simulation
progressBar.set_fraction(progressBar.get_fraction()+1/5)
5 simulation
progressBar.set_fraction(progressBar.get_fraction()+1/5)
But I don't know which signal I have to use and how to translate to this.
Thank you a lot for your help !!!
The pseudo code which you presented in your question should actually work - no signal is necessary. However, you could introduce a signal into your simulation for update of the progress bar. IMHO this will not solve your problem and I will try to explain why and what to do to solve it:
You provided a little bit too less context, so, that I will introduce some more assumptions: You have a main window with a button or toolbar item or menu item (or even all of them) which start the simulation.
Let's imagine you set a breakpoint at Gtk::ProgressBar::set_fraction().
Once the debugger stopped at this break point you will find the following calls on the stack trace (probably with many other calls in between):
Gtk::Main::run()
the signal handler of the widget or action which started the simulation
the function which runs the five simulations
and last the call of Gtk::ProgressBar::set_fraction().
If you could inspect the internals of Gtk::ProgressBar you would notice that everything in Gtk::ProgressBar::set_fraction() is done properly. So what's wrong?
When you call Gtk::ProgressBar::set_fraction() it probably generates an expose event (i.e. adds an event to the event queue inside of Gtk::Main with a request for its own refresh). The problem is that you probably do not process the request until all five runs of the simulation are done. (Remember that Gtk::Main::run() which is responsible for this is the uppermost/outmost call of my imaginery stack trace.) Thus, the refresh does not happen until the simulation is over - that's too late. (Btw. the authors of Gtk+ stated somewhere in the manual about their cleverness to optimize events. I.e. there might be finally only one expose event for the Gtk::ProgressBar in the event queue but this does not make your situation better.)
Thus, after you called Gtk::ProgressBar::set_fraction() you must somehow flush the event queue before doing further progress with your simulation.
This sounds like leaving the simulation, leaving the calling widget signal handler, returning to Gtk::Main::run() for further event processing and finally coming back for next simulation step - terrible idea. But we did it much simpler. For this, we use essentially the following code (in gtkmm 2.4):
while (Gtk::Main::events_pending()) Gtk::Main::iteration(false);
(This should hopefully be the same in the gtkmm version you use but if in doubt consult the manual.)
It should be done immediately after updating the progress bar fraction and before simulation is continued.
This recursively enters (parts of) the main loop and processes all pending events in the event queue of Gtk::Main and thus, the progress bar is exposed before the simulation continues. You may be concerned to "recursively enter the main loop" but I read somewhere in the GTK+ manual that it is allowed (and reasonable to solve problems like this) and what to care about (i.e. to limit the number of recursions and to grant a proper "roll-back").
What in your case is the simulation we call in general long running functions. Because such long running functions are algorithms (in libraries for anything) which shall not be polluted with any GUI stuff, we built some administrational infra structure around this basic concept including
a progress "proxy" object with an update(double) method and a signal slot
a customized progress dialog which can connect a signal handler to such a progress object (i.e. its signal slot).
The long running function gets a progress object (as argument) and is responsible to call the Progress::update() method in appropriate intervals with an appropriate progress factor. (We simply use values in the range [0, 1].)
One issue is the interval of calling the progress update. If it is called to often the GUI will slow down your long running function significantly. The opposite case (calling it not often enough) results in less responsiveness of GUI. Thus, we decided for more often progress update. To lower the time consuming of GUI, we remember the time of last update in our progress dialog and skip the next refreshs until a certain duration since last refresh is measured. Thus, the long running function has still some extra effort for progress update but it is not recognizable anymore. (A good refresh interval is IMHO 0.1 s - the perception threshold of humans but you may choose 0.05 s if in doubt.)
Flushing all pending events results in processing of mouse events (and other GTK+ signals) also. This allows another useful feature: aborting the long running function.
When the "Cancel" button of our progress dialog is pressed it sets an internal flag. If the progress is updated next time it checks the flag. If the flag became true it throws a special exception. The throw aborts the caller of the progress update (the long running function) immediately. This exception must be catched in the signal handler of the button (or whatever called the long running function). Otherwise, it would "fall through" to the event dispatcher in Gtk::Main where it is catched definitely which would abort your application. (I saw it often enough whenever I forgot to catch.) On the other hand: catching the special exception tells clearly that the long running function has been aborted (in opposition to ended by regulary return). This may or may not be something which can be stated on GUI also.
Finally, the above solution can cause another issue: It enables to start the simulation (via GUI) while a simulation is already running. This is possible because button presses for simulation start could be processed while in progress update. To prevent this, there is actually a simple solution: set a flag at start of simulation in the GUI until it has finished and prevent further starts while the flag is set. Another option can be to make the widget/action insensitive when simulation is started. This topic becomes more complicated if you have multiple distinct long running functions in your application which may or may not exclude each other - leads to something like an exclusion matrix. Well, we solved it pragmatically... (but without the matrix).
And last but not least I want to mention that we use a similar concept for output of log views (e.g. visual logging of infos, warnings, and errors while anything long running is in progress). IMHO it is always good to provide some visual action for end users. Otherwise, they might get bored and use the telephone to complain about the (too) slow software which actually steals you the time to make it faster (a vicious cycle you have to break...)
I am having a problem with gRPC C++ client making calls against google cloud Bigtable. These calls occasionally hang and it is only if the call deadline is set the call returns. There is an issue filed with gRPC team: https://github.com/grpc/grpc/issues/6278 with stack trace and a piece of gRPC tracing log provided.
The call that hangs most often is ReadRows stream read call. I have seen MutateRow call hanging a few times as well but that is rather rare.
gRPC tracing shows that there is some response coming back from the server, however that response seems to be insufficient for gRPC client to go on.
I did spend a fair amount of time debugging the code, no obvious problems found so far on the client side, no memory corruptions seen. This is a single-threaded application, making one call at a time, client side concurrency is not a suspect. Client runs on google compute engine box, so the network likely is not an issue as well. gRPC client is kept up to date with the github repository main line.
Any suggestions would be appreciated. If anyone have debugging ideas that would be great as well. Using valgrind, gdb, reducing the application to a subset with reproducible results did not help so far, I have not been able to find out what the problem is. The problem is random and shows up occasionally.
Additional note on May 17, 2016
There was a suggestion that re-tries may help to deal with the issue.
Unfortunately re-tries do not work very well for us because we would have to carry that over into the application logic. We can easily re-try updates, which is MutateRow calls, and we do that, these are not streaming calls and easy to re-try. However once the iteration of the DB query results has begun by the application, if it fails, the re-trying means that the application needs to re-issue the query and start iteration of the results again. Which is problematic. It is always possible to consider a change that would make our applications to read the whole result set at once and then at the application level iterations can be done in memory. Then re-tries can be handled. But that is problematic for all kinds of reasons, like memory footprint and application latencies. We want to process DB query results as soon as they arrive, not when all of them are in memory. There is also timeout added to the call latency when the call hangs. So, re-tries of the query result iterations are really costly to such a degree that they are not practical.
We've experienced hanging issues with gRPC in various languages. The gRPC team is investigating.
I have run a Java Flight Recorder recording for 2 minutes on a JBoss EAP 6.1 app server under load. I enabled exception counting (Java Application => Java Exception => Enabled=true) and I'm surprised by the number of reported exceptions.
When I look in the Events => Histogram view with event type "Java Application/ Java Exception" and Group by "Event Thread", 10 threads have over 2000 exceptions each. 3 of them have over 3000 exceptions.
This is the total number of reported creations of Throwable or Error:
Stack Trace Sample Count
java.lang.Throwable.<init>() 128 059
java.lang.Throwable.<init>(String) 116 107
java.lang.Throwable.<init>(Throwable) 39 207
java.lang.Error.<init>() 7
java.lang.Throwable.<init>(String, Throwable) 2
So I'm wondering if all these exceptions occurred during the 2 minute period I recorded or are they counted since the start of the JVM?
"Sample Count" column in the Histogram tab aggregates the number of events with respect to a field value, in your case I believe the top frame of the stack trace. So the number 128 059 means there were that many events emitted with a top frame of "java.lang.Throwable.<init>()" during your recording.
This may not be the information you are looking for.
I recommend using the recording template to enable Exceptions / Errors, and looking at the Exceptions tab, instead of editing settings for individual events and using the Histogram tab.
TL;DR: Java Exception events only count what happens during the recording. The Exception Statistics event count exceptions during the JVM lifetime (or some other 'JVM global' time).
There are two different data points, the Java Exception and Java Error events, and the Statistics/Throwables event.
If you only look at Java Exception/Error, the events you have in the recording are those that occcured during that time. The Statistics/Throwables event is taken with regular intervals, and might be from the start of the JVM, or possibly from the start of the JFR engine, or from the start of the first JFR recording occuring in the running JVM. It's mostly interesting to compare this values relative to each other. This event is displayed in the top of the Code/Exceptions tab, in the two text fields.
Also note that the Exception/Error events occur in the constructor, not when it's actually thrown
If your program creates a lot of Java Error events, there is some trouble with double bookkeeping of these, so the numbers might be incorrect (this is something we have compensated for in the next JMC version, but not in JMC 5.5)
Other Throwable subclasses will show up as Exception events.