Desktop API crashes

[JimBecker17]

Dion,

I normally run Release build, but do use Debug build as well. Have offloaded onto two Xeon system as well.

Today only one crash for me, with address being 0x00 in the log.

These problems are a bugger to find, for sure.

Glad you understand the marshalling issues with COM, that's where I'm spending all the time fetching T&S data.

One thing to note is I haven't had a crash fetching T&S data that can recall. However I do this off hours. When do this normally pulling records on one symbol at a time, with forty total collecting in the background.

During the day have a lot of parallel requests going, but only process them one at a time. No T&S as well.

Don't know where the 0x014 reference comes from, but perhaps a VERIFY() right there (if it's not there now), will catch it prior to when it eventually crashes. Unfortunately the debugger doesn't always trap null pointer dereferences in my experience. Getting a bit closer to the source if that's the case might help.

Best of fortune! These are the tough ones for sure.


-Jim

[DionLoy]

Hi Jim,

I think your problems are different than Dierk's. Your app is definitely exposing some sort of problem in eSignal's code.

Dierk,

I've stripped everything out of the eSignal Hooks implementation. So basically it is an empty COM interface implementation w/o any processing/CPU power on eSignal's side.

When your app fails on its call to QueryInterface, it never reaches the eSignal side at all. The COM query is failing in your stress test app because COM simply does not have enough CPU cycles to request an interface from eSignal. Unfortunately, I have to come to the conclusion that in your case, the cause of your application errors is the amount of CPU time your application is taking in your stress test.

Out of process COM must be treated in the same way as a network call. You will have latency, delays, etc.. if the CPU usage is too high. Since there was no real crash on either eSignal or your side, this error can be handled. Basically catch the exception as you are doing, and at that time back off the CPU usage until COM has a chance to catch its breath.

[Dierk Droth]

Dion,

Let me try to understand: You are saying that any (!) eSignal desktop API call may fail due to this design issue (dependent on the current CPU load)?

If the above is true: Is there any way to safely program a "serious" application - being aware that any (!) API call may fail? Please note: the CPU load may not come from the app but any other component running on the PC.

Regards

[DionLoy]

That's correct. It's the same problem you would run into if you automated Word or Excel or Outlook through COM out-of-process and the CPU usage on your machine was high. Any out of process COM communication is affected by CPU usage. When coding against an out of process COM call, the safe and recommended way (ever since MSFT debuted COM) is to wrap all COM calls in try/catch exception handlers, and handle failures gracefully.

[Dierk Droth]

Dion,

Well, then the next questions are:
- What is graceful handling of the eSignal desktop API ?
- Is it always safe - from eSignal's view - to re-issue any failed requests ?
- How often should a request be re-issued until it finally fails ?

Regards

[DionLoy]

From eSignal's point of view, you can reissue requests as often as you want, just be sure to unsubscribe yourself after they are done.

The graceful handling would have to be on a case by case basis. In your sample stress test case, since the COM failure happened on the event callback, I would simply mark the quote as 'dirty' and perhaps check on it in a few more seconds.

Not sure how often a request should be reissued before it finally fails.. This is entirely dependent on how COM feels.