eSignal 7.7 Build 679 crashes

[Dierk Droth]

Hi,

I have a reproducable crash scenario. My product - TradeMagic - includes test suits. One of this regression tests crashes eSignal.

I tried on 2 different installation and was able to reproduce the problem.

Here is how to reproduce:
- download TM3B1 from here http://www.trademagic.net/web/download.php
- note: you have to be registered at TradeMagic forum to run the SW: http://www.trademagic.net/phpBB2/. Registration is free
- start <TM-Install>\bin\TradeMagic.Test.exe
- select options: "Data", "Single", "eSignal", "Demo"
- press "Ok"
- an additional window pops up: you may set trace options, e.g. "Test"

The test may take a while to complete. Usually I get the crash on the first or second test run.

eSignal crashes when market data is subcribed / unsubscribed (RequestSymbol/ReleaseSymbol).

The crash reporter tool fails too. These messages are spit out:
Received: 3980 3812 1241668 1241696
Generating crash report ...
Crash report generated, sending ...
Retrieving status ...
Error uploading: 'Permission not granted to access this files area'


What's going wrong ?

[GenSpoo]

Can you provide us with even the smallest bit of source code that reproduces the crash? Extract that piece into a separate project and work on debuging just that piece.

Cheers... George

[Dierk Droth]

George,

Well, I gave you a scenario to reproduce.

Did you try ? What are your results ? Have you tried tracing (or something equivalent) on ESignal so see what's going wrong ?

ESignal crashes on the debug version of the test suite too. What do you want to know ?

Regards

[GenSpoo]

Hi Dierk,

You did give a sequence of steps to reproduce the error via your executable, but you didn't give me anyway to help determine the cause. I don't work at eSignal so I can't watch what happens on the eSignal side of the connection. The only way I have to help is to load up code in Visual Studio and play with it.

Maybe someone else can help with the information you have provided.

Cheers... George

[Dierk Droth]

George,

I see. So probably the eSignal staff should take a look.

You know, it would not make sense to me to waste time on creating a different scenario without retrieving any potential information from the already existing one.

Regards

[Guest]

In order to debug the issue, can you attach a code snippet that creates this problem?

The scenario only shows how to create the problem, but I need to know how the functions are called, the parameters used, etc. If I step through the code, I can pinpoint what is causing the it.

[Dierk Droth]

Robi,

Thanks for your reply.

Good news: I resolved the issue by delegating all eSignal requests to a seperate thread. Obviously there is some threading related issue (eSignal itself or .NET/COM interop) where eSignal is sensitive about.

Don't you have traces on the eSignal's API to figure out what functions are called having which parameters ?

Anyway: You can contact me via PM, it you want to research this issue. I then will provide you information on calling sequence and parameters.

Thanks

[Dierk Droth]

I forgot: Why did the crash reporter not work (see below) ? What's going wrong there ?

Regards

[kanstey]

Hi Dierk,

I am having some problems with the desktop API not so much under 'heavy load' conditions but I have an application that requests quote data for 15-20 symbols. After it runs for a long time (approx 500,000+ ) ticks, I seem to stop receiving data from eSignal, although my application is still alive.

You had mentioned 'delegating eSignal requests to a separate thread'. I have found through watching in the Visual Studio debugger that when the eSignal OnQuoteChanged event fires, it is delivered on another thread already (seemingly via the .NET thread pool).
I originally had my application talking to eSignal on a secondary thread, but once I observed this behaviour I stopped doing that.

I'm sorry to bother you, but can you provide a bit of detail, if you don't mind on how you delgated the requests to a separate thread.

This is really difficult to diagnose since it may take 4-5 hours before this situation occurs in my application.

I also don't see any indicated of my app 'bleeding' resources (i.e. memory or handles)

Any insight (from anyone) would be appreciated.

Thanks in advance.


-Kevin

[Dierk Droth]

Kevin,

I just delegated the initial (!) requests - not those which I have in the callbacks - to a seperate thread. This made it far more stable - although I don't understand why. Obviously the ActiveX API has a threading issue.

As for your crash: place a try catch block around your OnQuoteChanged code and check if the callback itself is really not called. I experienced, that the callback got triggered, but the subsequent GetBasicQuote call (not delegated to a seperate thread) crashed. Read more here: http://forum.esignalcentral.com/show...threadid=10935

Regards

[kanstey]

Dierk,

Thanks for the help.

I placed a try...catch around my OnQuoteChanged code but I am not experiencing the error you suggest.

I have an application which accepts quotes from eSignal (< 50 symbols).

My application counts the number of quotes it receives.
I have processed in excess of 600,000+ quotes before experiencing the "stoppage" I previously referred to.

Upon further research, it appears that at an arbitrary point, eSignal stops firing the OnQuoteChanged event.

My application is still very much alive (i.e. it will repaint its form when occluded, etc.)
eSignal, however, does not appear to be as healthy.
It seems that, if I attempt to access the esignal main window several times by moving it, etc. it eventually "wakes up" again and processing continues as before.

I cannot account for this behaviour and was wondering if you had ever experienced anything like what I am describing.
No exceptions, just a "stall" of sorts.


Thanks,

-Kevin

[Guest]

Wierd error. It seems that 7.8 Beta did correct a known problem that may fix your issue. If you e-mail "[email protected]", I can send you a link to the beta installer to see if that corrects your problem.