Desktop API crashes

[Guest]

Jim,

I don't get that problem with the switching pages. It seems that you and wscully are experiencing the same crash because you both report the identical memory reference. As I mentioned in his thread, if we could get a .exe that consistantly has this problem, we can run it in a debugger and maybe resolve it quickly.

It's interesting that it occurs more frequently on Mondays. I know I get the Monday blues, but didn't think applications did to.

[JimBecker17]

The switching problem is from doing an OpenNewWindow("OPEN.LAY",...) type call after connecting to eSignal programmatically. I don't normally lay hands on eSignal...

I'm not sure exactly what Dion fixed for the first instance of the crash, but the other crashes have gotten are the same. So he might have found one place which was getting it, but the fix didn't get to the root of the problem.

For example, if the problem was a message handler deleting the underlying object before returning and using it, there could be another instance or stack windup which causes the same thing.

Considering this problem shows up when the system is a bit loaded, it could be something like message handling recursion going on. Sometimes I put static flags into entry routines to make sure don't get into trouble entering the same routine when already in it from another call.

Or if an object needs to be destroyed, I might mark it as such and wait until the "coast is clear" before actually taking it out to the back alley..

Just guessing here.

I can't provide my environment, but if there's a debug build around of eSignal might be able to attach to it on a crash and send you the call stack and variables...

-Jim

[DionLoy]

Jim, I'm going to do the mark and delayed delete for an upcoming 7.9 beta. Hopefully that's just it, but I'm not quite so sure as there's a whole bunch of checks and double checks in there now.

Say you wouldn't happen to have a crashlog.txt in your esignal program files would you? If you do find one after your latest crash could you send it my way.

But the EXE to demo the crash would be the best/fastest way for me to look at it.

thanks!

[JimBecker17]

Dion,

M&D sounds good. Attached is current crash log. Noticed that showed up recently...

I will accumulate the crash logs programmatically for you, perhaps get the code in tonight or tomorrow. My thread that kills off the CoreReports needs more to do...

The EXE which causes the crash needs about 36GB of data and a lotta pixel space around to run correctly... So I don't think you want to go there...

-Jim




-- finished purging history db
-- (13:31:00) finished purging history client session db
PurgeTime(13/13:32:00)
-- finished purging history db
-- (13:32:00) finished purging history client session db
PurgeTime(13/13:33:00)
-- finished purging history db
-- (13:33:00) finished purging history client session db
PurgeTime(13/13:34:00)
-- finished purging history db
-- (13:34:00) finished purging history client session db
PurgeTime(13/13:35:00)
-- finished purging history db
-- (13:35:00) finished purging history client session db
Crash at 13:35:03 - 0x7C146460

[SWhitney]

Originally posted by JimBecker17
The switching problem is from doing an OpenNewWindow("OPEN.LAY",...) type call after connecting to eSignal programmatically. I don't normally lay hands on eSignal...

-Jim

Could you please eloborate on this quote?

Have you found a way to hack around opening the full esignal application?

Further, can someone explain why it is necessary to burn up 50MB of ram in the background to simply fetch data from remote servers and listen for events on a connection?

Look at this task manager image:

http://www.headsuptrading.com/images/a.gif

The esignal appliction is a pig. It gobbles up ram at a prodigious rate. My VS NET 2003 IDE with a dozen code windows and a dozen designer windows open only consumes 18 MB...

Where is the mythical DLL connection that is so obviously needed?

Scott

[garytay]

Originally posted by SWhitney
Could you please eloborate on this quote?

Have you found a way to hack around opening the full esignal application?

Further, can someone explain why it is necessary to burn up 50MB of ram in the background to simply fetch data from remote servers and listen for events on a connection?

Look at this task manager image:

http://www.headsuptrading.com/images/a.gif

The esignal appliction is a pig. It gobbles up ram at a prodigious rate. My VS NET 2003 IDE with a dozen code windows and a dozen designer windows open only consumes 18 MB...

Where is the mythical DLL connection that is so obviously needed?

Scott

Mine averages around 60MBs and peaked at 500MB once. . . .

[JimBecker17]

I use the full eSignal app, and my memory use varies as well. But hey memory is cheap. Remember when a fullsize 128MB board for a Solbourne computer all surface mounted that cost $20K! Or the max of a Sun 2/50 was around 4MB? Guess I'm dating myself....

By saying I don't "lay hands on eSignal" this means all my use is programmatic, from bringing it up to setting layout to setting current symbol and fetching data. In addition have support threads that watch for crashes and reset everything needed during and after the crash.

I've updated logic to capture the eSignalCrash.log files, so perhaps that will help the eSignal guys. If they want to make these as detailed as possible might be more helpful in tracking problems down.

Time fur market to open - see ya later.

-Jim

[Dierk Droth]

Robi,

I have been out of town for 2 weeks.

You wanted me to test 7.8. I just did and tried the sample program I posted on the beginning of this thread.

-> 7.8 still crashes after ~1 minute with the same error.

When will it be fixed?

Regards

[DionLoy]

Hi Dierk,

I've been running your sample app this morning for about 10 mins (the heavily traded ones have about 3000 events so far). I'll keep it on for the rest of the day, and I'll see if we can find anything out if it crashes.

Thanks.

[Dierk Droth]

Dion,

I tried it on two machines here (a laptop and a desktop) and it crashed on both.

Regards

[DionLoy]

Hm. there must be something else going on here. I'm up to 30,000 events on MSFT and RIMM w/o a problem so far (esignal running at about 7% CPU, with 36MB ram usage).

This is a 1.8ghz Centrino machine. It does have 2 GB of RAM though.

Is your eSignal running anything else, or is it just open to a blank layout ? I have a few option chains and charts on mine, I'll try loading it up to drag the CPU down.

Any additional info you could provide would be great. thnx!

[Dierk Droth]

Hmm, strange.

Just blank eSignal, no chart, no nothing. We are using the same Release 7.8 Build 688 as of 11/23/2004, right?

Regards

[JimBecker17]

Considering it's an asyncronous timing type thing, if all the users are on CableModem/DSL type connections it could be an issue testing in LAN environment might not showup - too much/clean bandwidth. To track it down might have need to test outside the LAN, if that's what's being done now. Dunno.

-Jim

[Dierk Droth]

Hmm, could be. Both my testing machines are running thru a router and DSL.

Regards

[DionLoy]

Actually I don't work in the eSignal Hayward office. I work out of my own home in Santa Barbara, so I have a similar router/cable connection to the eSignal servers.

I was running the 'Release' version of your stress test application against a 'Debug' version of eSignal Build 688.

I shut that off since it obviously wasn't crashing fast enough and loaded up the 'Debug' version. This one I can see the QueryInterface error right away. However, there does not appear to be any error on the eSignal side of things in the debugger. The error appears (at least from usenet postings) to be related to too many out of process COM transactions happening at once. This might be related to the slower running of the 'Debug' version of the stress test, however, I would have thought this would be caused by eSignal rather than the app connecting to it.

Were you running the 'Release' build of your software against eSignal or the 'Debug' one?

The difference between our COM interface and the interfaces of other quote providers is that this one goes out of process to winsig.exe instead of directly to our servers. This results in a rather slow COM marshalling of all the data across process boundaries.

In any case, I'm going to look into this a bit more to see if there's anything that can be done to lessen the problem.