CRASH - 6.2.1.2142/2143 (icon/download.exe)

[ckelly]

Avery,

I've had several crashes with the latest update (the icon reflects 6.2.1.2142; the download shows 6.2.1.2143).

Any work on resolution?

Thanks,
Carol

[ahhaha]

I'm experiencing the same thing. I thought it started last Friday but today it's definitely a problem.

I wasn't able to do a screen dump which I do whenever the load exceeds 50 megs. It had gotten to 65 megs which my card buffer can handle, and then mysteriously crashed. The crashes progress. Maybe they forgot to call the garbage collector.

[ahhaha]

crashing

When I open 6.2.1 and let it sit there untouched with my minimal setup within a few minutes the program will spontaneously crash. This condition has progressed since my post here several weeks ago. Nothing much has changed with my system during the interim which has 1 gig memory, running a Dell Xeon INTC @ 2.4ghz. I've tried uninstalling. The only suspicious thing I get is a quick jump in foot print to 55 - 60 meg where, in the past, it would gradually move up from 8 meg based upon interface usage. Should I call tech support?

[ahhaha]

I've noticed that when a crash occurs there's two instances listed in task manager. I don't know whether the second instance is merely a phantom listed by task manager when it reports a name of a process located elsewhere in memory or reports the handle to the actual crashed process. I've seen various versions of QC crash before, but never have I seen two instances listed.

[ckelly]

Another Crash.

Crash report sent.

Carol

[ahhaha]

crash report

Maybe it crashed because of "pre-loading".

What is pre-loading? Something I invented.

Let's say QC saved its previous state and that state had a full screen buffer. 2143 already has a memory leak. In fact, the previous version had one too! So if your QC was exited after having sat idly, its screen buffer would have loaded to the limit due to the memory leak since the expansion in memory has to be reflected in the screen in order to support QC's ever growing gadget set and to have those gadgets available on demand. Then a restart reads all that junk back into your screen buffer. Evidence supporting this claim would be seen in screen buffer size as represented on the meg figure on the left extreme of the status bar. When you start QC watch for a jump on start to 60 megs or so. Depending upon your card memory the problem may not appear given that not enough junk would have leaked to fill it. That's why you're not hearing more complaints.

There's another problem related to the above. For various reasons QC expanded the code and didn't anticipate they'd get side effects. Which? Say, you minimize the screen. That should take out the garbage. Problem is, it doesn't take out the garbagy pointers which are then nulled out since they no longer point to any garbage, and this precipitates a crash. If the program deleted the pointers with the garbage, it would have to do a server pull in order to restore the state of all those silly, useless, gadgets, and that's something QC is trying to avoid.

Thus, I predict that your card is older than 5 years. Sometime around 2005 or 2006 cards had to get a lot larger to swallow MSFT bloat, and app developers have become bell & whistle dependent upon the bloat.

[ahhaha]

2143 starting crashing today again. I thought I had it tamed by redoing the workspace, but the old problems and their evidences have reappeared. Saw a new one today.

Specifically, I got an "Out of Memory" message box.

Program:

28 meg loaded
60 symbols

Windows:

Tasks =25
Apps = 8
Overhead 4452 meg
committed 422 meg

Out of memory? Maybe 2143 doesn't garbage collect on resource usage, but instead exhausts the 64k handles XP provides. Inconceivable, but I've got to grasp for straws somewhere.

Also, spontaneous crashing has occurred. That's where the app is started and one does nothing, but suddenly the window pane deletes its caption and the program freezes. I figure its thumbing its gadgets at me.

[ckelly]

Avery - could you provide an update on efforts to eliminate CRASHES?


Another CRASH report sent today.

Carol

[ahhaha]

1. Sending crash reports is futile or useless.

2. The problem isn't widespread enough yet because most users have more powerful machines than you do with bigger screen buffers so they haven't been affected.

3. Try this:

a. If you can get it open, immediately minimize through the upper left Windows button.

b. Once minimized(you may need to repeat step a.) and the status bar shows something like 8 meg, save the workspace.

c. Work on the workspace by getting rid of resource consuming objects like T&S windows and try to use a minimum of symbols. You should try to do this in the symbol list in the Menu bar too which QC claims can be edited, but I have proved that it can't be edited by changing its source file. Maybe you can do what i haven't been able to do.

d. Save the minimal Workspace under a new name. You'll want to start it if you crash again.

[ckelly]

Ahhaha -

Thanks for your ideas. However, my machine is bigger than that recommened by QCharts; my login is set to open to a BLANK Workspace and the CRASH, like this morning, typically occurs prior to my Workspace even being opened. I click on the QCharts icon and it crashes.

I don't run T&S; out of defensive mode, when I open my intial Workspace, it is a very minimal one with only 5 charts and no T&S, no Quote Sheet - just 5 little charts . . . . and so when the CRASH occurs as it is being opened, unless you are seeing something I am not, I really don't think my login is overly taxing of the system.

This is not a new problem. It has been going on since way back in the year 2000 (11 years ago) and what ever QC version that was (I think maybe 2.3?). It occurred with our beloved QC5.1, though not as frequently as it does with QC6, and while the frequency has certainly decreased (indicating to me that something has been done to help), it has continued to consistently be a problem for me (& others I know who are too sorry to take the time to report it)....... I am now on my 5th computer in the last 11 years, and each one has experienced the issue, which implies to me that it is an application issue and not my computer creating the problem.

I have just tried your idea of minimizing the Workspace to reduce the meg usage and saved the Workspace. I admit that I don't understand what exactly is happening with that but I'll sure continue to check it daily if need be. Anything else you can tell me on that I'd appreciate, just curious what is happening there?

Thanks for your ideas and help!
Carol

[ahhaha]

WHat's happening here?

Why, crashing, of course.

Today it's taking a different route: persistent "Out of Memory" message thrown error that doesn't necessarily crash the app.

I know why. It's what I described in an earlier post. 2143 has a nasty memory leak. That situation has occurred for many years. In every version QC adds all kinds of junk operators to satisfy mistaken users. These users think all these silly technical analysis algos are of some value. Problem is, they ALL have a negative expected return. Unfortunately, neither them nor anyone at QC quite comprehends what that means, nor cares.

In any case I don't care if they want to be deluded into losing money, but I do care when QC takes a "all things to all people" MSFT attitude and compromises the interface with bloat. You see, these algos and their support code have side effects and overhead. Programmers don't know how their code will interact with earlier code. One classical symptom of this development: memory leak = failure to take out the garbage. Every version has so leaked.

There's another problem. They're moving the data onto your client. You need a large screen buffer to manage this change which clearly became a more significant issue in 2143. This happened in version 3.0 long ago. Then they moved the stuff back on the server.

One other point. You must start with a new workspace before you apply my suggestions.

[ahhaha]

Update on crashing

About a week ago the crashing stopped. Nothing has changed within my computing environment. I'm forced to conclude that the problem I was having had to do with the old culprit, the server farm, rather than the client. However, it may still be the case that the client will be unable to cope with variances in feed stability. Evidently, it's a matter of degree.

In any event I'll get off the criticism of the write itself, a criticism which didn't make a lot of sense given that over the past year until the crashing started, the program worked well. How could its behavior suddenly change? That would require at least a change in resources, dlls, but none have been supplied. Therefore, the core resource, the server, had to be the culprit.

I wouldn't have complained had eSignal informed me that they were having some difficulties. That's completely acceptable. Then I wouldn't have spent a lot of time chasing ghosts.

[ahhaha]

I'm baaaack

The problem is on again.