Support Board
Date/Time: Wed, 15 Jan 2025 17:41:03 +0000
Post From: Warning: Caught an exception during the processing of a timer event
| [2017-07-15 18:24:47] |
| i960 - Posts: 360 |
|
We have no idea what you are doing despite what you may claim you are doing.
Do not save your Chartbooks once an exception is encountered and you will not have any issue. I am NOT saving the chartbooks. I am clicking NO on every single dialog that comes up about saving after this situation occurs. Do you seriously think I'm just dumb and saying save everything after this happens? Clearly I'm not but SC is truncating the chartbooks anyway. I'm well aware. It was the only way I was able to restore these chartbooks. Do not blame this problem on us. Your whole approach over the years in order to try to get us to make changes, is simply a failure. It does not mean anything to us because we know how to do things. Stop assuming all your users are idiots and doing crazy things behind the scenes they're not telling you about. I have 25+ years in computing with plenty of hardcore dev background behind it which is why I'm able to clearly report that which is a problem. Are you blaming not handling an OOM situation on how the user uses the program now? Who knows why it ran out of memory, hell it might have even been handles or something else - but we don't know that because the error message simply says "Error reserving space" which could mean all sorts of things under Windows. I'm telling you with 100% conviction that the last time this happened (which was a few days ago) I absolutely was aware of the risk to the chartbooks, closed SC via alt-f4 and answered no to every single save dialog and still ended up with around 10+ chartbooks that had written out the initial SC_CHART_BOOK header and only that stream of bytes. And for the record I received zero OS level global warnings about memory usage during this time, otherwise I would have clearly connected the two dots of "Error reserving space for time and sales" and "Out of memory." However, I can say that CPU was completely pegged as all the chartbooks were loaded and I'd wager there's a hell of a lot more of a likelyhood it's a thread-race showing up during non-ideal conditions than a memory issue. Obviously this would be very hard to determine given the fact that I simply have a message log, so there's nothing authoritative proving it and it's just speculation. However, the program straight up crashes on exit after it gets that exception, is that also a user problem? The entire issue here is this: If SC runs into an error on allocating memory, rather than gracefully handling that failure and either refusing to continue load the chartbook or simply retrying after some small time delay, it instead goes into a broken state where an exception is reported to the logs every second until the program is basically restarted. Even if the memory pressure situation has long gone away, SC still remains in this broken state and just catches exceptions on timer events and logs them, forever. What would make sense here? Retry on alloc failure and/or hard-error on alloc failure, don't allow the program to go into undefined behavior land because of a simple alloc failure, report the actual exception message in "Caught an exception" so we have some idea what the exception is even about, actually handle the exception if possible, or otherwise do whatever it takes to avoid undefined behavior and a total lack of robustness if the computing environment suddenly isn't perfect at that moment. When it comes to my "whole approach" the reason you're having an issue with it is because you expect your users to be dumb idiots and when they aren't, you have an issue with them pointing potential problems because you consider your code nearly infallible. Every reasonable developer knows their code is not infallible and if you have an expert level user base you should be listening to them not fighting them as they're basically doing free troubleshooting for you to make a better product for everyone. I've reporting issues to you around partially written out files on error (because of not using a temp file or intermediate file, things like the above etc, and the continual theme here is the code-base assuming everything goes perfect at runtime, basically setting itself up for these types of issues. I've also reported *plenty* of legitimate bugs, missing data configurations, even written utilities to parse the global symbols file and programmatically find missing settings, etc. and clearly reported them. I don't just sit here and report extremely hard problems all day and my thread history shows that. Date Time Of Last Edit: 2017-11-16 09:39:26
|