|
|
Post by George on May 8, 2021 13:03:41 GMT -5
Robert: Sounds just wonderful, but just an enormous pile of work. This is one of those scattergun changes, requiring a review/search of all those 'significant' events. Just did a quick scan, there are over 850 error messages and over 100 popup error message boxes. Now add in all the possible logging events like the user inputs, primary cmds, Line cmds, File events (Open, Close, Watches), etc
Each to be reviewed, decide if a worthy event, what info should be collected, is the info readily available, etc.. Then where to log it, how to format it.
Not in my lifetime.
George
|
|
|
|
Post by George on May 8, 2021 15:47:42 GMT -5
Robert: It's very simple. Consider that right now almost none of the information that currently is displayed by the current crash routine is worth a whit.
What counts, plain and simple, is a repeatable sequence of Do 'A', Do 'B', Do 'C' - Crash/Error!
What counts, plain and simple, is a repeatable sequence of Do 'A', Do 'B', Do 'C' - Crash/Error!
What counts, plain and simple, is a repeatable sequence of Do 'A', Do 'B', Do 'C' - Crash/Error!
What counts, plain and simple, is a repeatable sequence of Do 'A', Do 'B', Do 'C' - Crash/Error!
Now maybe a log could provide some of that, certainly, but I have major doubts.
Hindsight says if we could log the correct A, B and C, maybe we'd have a hope. But my bet would be that no matter what 'things' we choose to log, when a problem occurs, we won't have logged any helpful information, that's the case with the current debug info. Like, for example, what's the data being edited, what's the users CFG settings (so many errors only occur with a certain combination of CFG settings).
I'm just not prepared to go in and try and log all kinds of data in the hope that maybe we've chosen the right info to log, and that it would really be any assistance in solving a problem.
Look, I'm the only one debugging these reported problems, the effort to log all this data is considerable, and I just don't see this logging ever providing me with what I need.
I'm not trying to exaggerate the effort, it is considerable. And right now all I see coming out of it is some pretty log data that, in the end, does nothing to help solve a problem.
George
|
|
|
|
Post by George on May 9, 2021 13:34:55 GMT -5
Robert: I don't want to belabor this either. But I reiterated what I wanted 4 times, because THATS WHAT I NEED.
This isn't the old mainframe days, where we could plow through SYSUDUMPS, LKED maps, System trace tables etc. and burrow our way back to the failing instruction in the code.
I can't think of a single example of the current Debug trace being the key in finding a problem.
Regardless of the effort involved, adding even more 'stuff' to a log does nothing. I can't even think of a single thing that could be added to a log that would be helpful. The current Debug trace is as good as it gets, it tries to indicate the last function that was in control. And even that is limited because we don't track each and every function, just the main ones because of the overhead.
When all you have is the source, what other data could possibly be logged to assist in solving a C0000005 memory exception (the commonest crash)
I don't sit here thinking "If only I had xxx and yyy logged, this would be so simple to fix".
I do sit here thinking "Give me a repeatable scenario to trigger the error".
George
|
|
