Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Wed, 01 May 2024 23:31:55 +0000
Warning: Caught an exception during the processing of a timer event
View Count: 1524
| [2017-06-05 07:32:13] |
| peaceland - Posts: 95 |
|
Seem to be receiving this error. Never saw this until this week. Reloaded charts, still persists. Writes a couple of these errors per second, it is continuous printing in the Message Log, and will not allow me to keep the Message Log window closed. It just keeps opening the window, so I cannot view my chart. I try not to reopen my charts too often, because it takes about 45 minutes for them to load. Looks like I am down for 45 minutes again tonight. I am removing the timer from my template, but it takes a while to apply templates. p.s. - You folks have TradingView beat on DATA by a mile. But in terms of chart performance, their charts load so much faster, and have very fast response when "showing/hiding" elements. Theirs is instant. Sierra takes FOREVER!!! Unless I dumb down the chart and remove everything, then of course, it is just fine. But then, the chart is pretty much useless unless you want to take losses all over the place. Oh well... |
| [2017-06-05 07:43:32] |
| |
|
The exception issue is a serious problem. In the unlikely event that has to do with the problem with a particular version, update Sierra Chart to the current version with Help >> Download Current Version. Do this now. I try not to reopen my charts too often, because it takes about 45 minutes for them to load.
This makes no sense. Something is very very wrong. This is totally and completely insane. Is this the literal truth? Do not make misstatements on this support board. That is completely improper. Do you actually put up with 45 minutes? What on earth are you doing with Sierra Chart? And what kind of computer hardware do you have? The Chartbooks should open in just a few seconds literally. And that is the simple factual truth that anyone else will say on the support board. For the problem, refer to: http://www.sierrachart.com/index.php?page=doc/helpdetails30.html#h30.39 Do you realize how ridiculous that amount of time is? Once again, this is literally totally and completely insane. What on earth are you doing with Sierra Chart? There is no way you could convince us you are doing anything reasonable and have a fast system. None of that can possibly be true. You folks have TradingView beat on DATA by a mile. But in terms of chart performance, their charts load so much faster, and have very fast response when "showing/hiding" elements. Theirs is instant. Sierra takes FOREVER!!!
This is a problem that you have created with what you are doing and also would relate to your computer hardware. We never see anything like this ever. There is no one else who has a problem anything like this. Refer to help topic 30:https://www.sierrachart.com/index.php?page=doc/helpdetails30.php Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2017-06-05 07:48:29
|
| [2017-06-05 07:53:01] |
| peaceland - Posts: 95 |
|
I use a lot of indicators. That is not your fault. It is my own design. With TradingView, I am able to customize the programming such that several of them load together, as one "indicator", but with Sierra, I do not know how to do the programming. So, I just put them in one by one by one. There are 72 studies per chart, and there are at least 5 charts per Chartbook. My guess is, even if I "programmed them" to load together, they would still take a while to load here. It takes a while. Sorry. I am not making mis-statements. I am demanding a lot of the software, and thus it is taking a while to load. I have the same configuration at TradingView and it loads in seconds. This computer is fine, Windows 7, i5 CPU 3.2Ghz 8gb ram, 64-bit It is not the computer. It is the fact that I am asking Sierra to do a lot for me. Not sure why, but that is how it is... It is a fact. Not a mis-statement. Try loading 72 different indicators and see what happens, especially if you are also loading MOAR data. I am loading approx 200 days for an M1 chart, 20 days for a 5 sec chart, etc. I need at least this much data to see what I am looking for. Beyond M10 I am loading ALL of the data that is available. Yep, 45 minutes to load the full chartbook of half a dozen charts with 72 indicators and TONs of data. Yes, indeed. Fact. |
| [2017-06-05 07:53:36] |
| |
|
and have very fast response when "showing/hiding" elements. Also, many months ago, we removed the study calculations for showing and hiding studies when done directly through the chart or directly from the Analysis menu and not the Chart Studies window.So there is zero calculation time with this. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2017-06-05 07:54:59
|
| [2017-06-05 08:19:00] |
| peaceland - Posts: 95 |
|
Ended up having to close all chartbooks and restart Sierra. Decided to load a fresh symbol, M1 20 days data, and apply my template without the CountDown Timer. It took 5 minutes to load ONE chart. If there are more charts to load in a chartbook, Sierra will basically "blank out" until they ALL LOAD. If there are 5 charts, we'll call it 5 min each, at least 25 minutes to load them all. During that time, I am unable to access ANY of the charts, until the rest of the charts finish loading. Sure, I could just load one chart, but that's not really ideal. Sure, I could just be a PA kinda trader. But, that's not my style. Sure, I could use "less indicators" (because you're not supposed to use this many, I know), but then, I would not have the complete perspective I have achieved, which has taken nearly 20 years of research to perfect. If I decide to switch FX pairs on this chart, it will take another 5 minutes at least to load the new data. With tview it is pretty much instantaneous when I change pairs (even with 72 indicators on every chart, and they have multi charts, and it changes all of them instantly) Probably for people who have naked charts, and use far less data, everything is fine. Well, seem to have solved the countdown problem. The timer is causing issues. If I remove it, start fresh without it, the error window has disappeared. |
| [2017-06-05 08:24:02] |
| peaceland - Posts: 95 |
|
BTW, I am grateful that at least Sierra does allow me to load this many indicators as well as this much data. This is the only place I have found that has this much power under one roof. It just takes a while to load. Fortunately, the charts stay running for weeks on my server, so I don't have to reload them very often. I am grateful, just got frustrated by the CountDown Timer error. I added that in, so that I could see right away whether a chart was still "running" or whether it had stopped feeding me data (which was an issue in the past - the data feed would just cut out here and there). I have not seen those problems as much recently. But now I do not have the timer to verify. |
| [2017-06-05 08:28:32] |
| peaceland - Posts: 95 |
|
I reloaded the template with the timer to see if the error resumed. It did not. The time does appear to be working without the error now. I do notice now that I am paying attention to it that the timer only moves when there is price movement. Is that how it is supposed to work? Why isn't the timer continuous count down? |
| [2017-06-05 08:29:13] |
| peaceland - Posts: 95 |
|
It took another 5 minutes to apply my template.
|
| [2017-06-05 08:31:12] |
| peaceland - Posts: 95 |
|
I have only opened 1 chart so that I could experiment with it. Time for Zzzz here, so I'll go ahead and reload the other charts and see how they look in the morning. Appreciate all your help, and I hope I am not upsetting anyone here. Most folks will never drive Sierra this way. "It's too confusing"... ;-) |
| [2017-06-05 08:53:45] |
| peaceland - Posts: 95 |
|
Charts are loading... Zzzz... BTW, I did reinstall the latest update, so we'll see in the morning here... Sorry I got upset about having to load the charts again... it's my issue. I can live with it. It's worth the wait. Peace |
| [2017-06-06 18:57:35] |
| |
|
With tview it is pretty much instantaneous when I change pairs (even with 72 indicators on every chart, and they have multi charts, and it changes all of them instantly)
There is some difference that we do not know, with what you are doing with this program and how it works which accounts for the difference.There will be a lot of calculation time if there are a lot of studies on the chart, if they use a lot of CPU time, the fact that they are fully calculated across all chart bars, and if there are a lot of chart bars in the chart. I do notice now that I am paying attention to it that the timer only moves when there is price movement. Is that how it is supposed to work? Do you want us to give you a name of a programmer who can maybe look at what you are doing and create a more efficient study to do what you need? Rather than using the built in studies. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2017-06-06 18:59:01
|
| [2017-07-13 19:05:06] |
| i960 - Posts: 360 |
|
This doesn't seem to be 100% related to custom studies. I also get these errors on trying to load up all my chartbooks on a fresh restart (probably 40 chartbooks total). I've seen it through various versions over the last 6 months or so. I'm currently running a pretty recent version as well (updated as of last week). Here's what I see in the logs: CL-201708-NYMEX [CV] 121393 Volume #9 | Volume based rollover from CL-201612-NYMEX to CL-201701-NYMEX occurs at 2016-11-17 | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 121393 Volume #9 | Volume based rollover from CL-201701-NYMEX to CL-201702-NYMEX occurs at 2016-12-16 | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 121393 Volume #9 | Volume based rollover from CL-201702-NYMEX to CL-201703-NYMEX occurs at 2017-01-18 | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 121393 Volume #9 | Volume based rollover from CL-201703-NYMEX to CL-201704-NYMEX occurs at 2017-02-16 | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 121393 Volume #9 | Volume based rollover from CL-201704-NYMEX to CL-201705-NYMEX occurs at 2017-03-17 | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 121393 Volume #9 | Volume based rollover from CL-201705-NYMEX to CL-201706-NYMEX occurs at 2017-04-18 | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 121393 Volume #9 | Volume based rollover from CL-201706-NYMEX to CL-201707-NYMEX occurs at 2017-05-18 | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 121393 Volume #9 | Volume based rollover from CL-201707-NYMEX to CL-201708-NYMEX occurs at 2017-06-16 | 2017-07-13 11:23:12 HD Request # 1305 | Receiving historical Daily data for CLF99 starting at 1996-08-21 | 2017-07-13 11:23:12 HD Request # 1305 | Writing historical Daily data to the file CLF99.dly | 2017-07-13 11:23:12 HD Request # 1305 | Received 566 records from 1996-08-21 00:00:00 to 1998-12-21 00:00:00 (2.3 years) and wrote 566 records for CLF99 | 2017-07-13 11:23:12 HD Request # 1305 | Daily download COMPLETE for CLF99. Completion time: 2s. Unique request ID: 2953 | 2017-07-13 11:23:12 Removed historical data download ID 2953 | 2017-07-13 11:23:12 Error reserving space for Time and Sales for symbol. | 2017-07-13 11:23:12 * HD Request # 1306 | Downloading Historical Daily chart data for CLZ98. Starting date: 1967-07-14. Service: ib | 2017-07-13 11:23:12 HD Request # 1306 | Using user Barchart Historical data account. | 2017-07-13 11:23:12 HD Request # 1306 | Requesting historical Daily data for CLZ98 starting at 1967-07-13 | 2017-07-13 11:23:12 Warning: Caught an exception during the processing of a timer event. | 2017-07-13 11:23:12 * Warning: Caught an exception during the processing of a timer event. | 2017-07-13 11:23:12 * Warning: Caught an exception during the processing of a timer event. | 2017-07-13 11:23:12 * HD Request # 1306 | Receiving historical Daily data for CLZ98 starting at 1995-05-04 | 2017-07-13 11:23:12 HD Request # 1306 | Writing historical Daily data to the file CLZ98.dly | 2017-07-13 11:23:12 Warning: Caught an exception during the processing of a timer event. | 2017-07-13 11:23:12 * Warning: Caught an exception during the processing of a timer event. | 2017-07-13 11:23:12 * CL-201708-NYMEX [CV] 46368 Volume #3 | Reloading chart. | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 46368 Volume #3 | Date rule based rollover from CL-201607-NYMEX to next contract occurs at 2016-06-17. | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 46368 Volume #3 | Date rule based rollover from CL-201608-NYMEX to next contract occurs at 2016-07-18. | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 46368 Volume #3 | Date rule based rollover from CL-201609-NYMEX to next contract occurs at 2016-08-18. | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 46368 Volume #3 | Date rule based rollover from CL-201610-NYMEX to next contract occurs at 2016-09-16. | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 46368 Volume #3 | Date rule based rollover from CL-201611-NYMEX to next contract occurs at 2016-10-18. | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 46368 Volume #3 | Date rule based rollover from CL-201612-NYMEX to next contract occurs at 2016-11-18. | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 46368 Volume #3 | Date rule based rollover from CL-201701-NYMEX to next contract occurs at 2016-12-16. | 2017-07-13 11:23:12 CL-201708-NYMEX [CV] 46368 Volume #3 | Date rule based rollover from CL-201702-NYMEX to next contract occurs at 2017-01-18. | 2017-07-13 11:23:12 After that the situation becomes very bad. If I close everything out, various chartbooks will be written out with 18 bytes of data containing only: 00000000 53 43 5f 43 48 41 52 54 5f 42 4f 4f 4b 00 be 00 |SC_CHART_BOOK...| 00000010 00 00 |..| It even does this if I say "no" to "save all?" The other problem is that it's hard to determine where this error is actually occurring because so much stuff is going on in parallel. Based on my own history of threaded programming it has the feeling of a thread race (multiple things accessing the same data without a lock) somewhere. It would also help if that error message were associated to a particular chart or chartbook so we have some kind of clue which one is associated with the exception. |
| [2017-07-13 19:06:37] |
| i960 - Posts: 360 |
|
I should also add, that when these exceptions show up and I close SC entirely (and say "no, do not save") it closes instantly and Windows reports: Problem Event Name: APPCRASH Application Name: SierraChart.exe Application Version: 0.0.0.0 Application Timestamp: 595b5856 Fault Module Name: SierraChart.exe Fault Module Version: 0.0.0.0 Fault Module Timestamp: 595b5856 Exception Code: 40000015 Exception Offset: 00863c35 OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 1033 Additional Information 1: 02f9 Additional Information 2: 02f9a52d6a4cd48f26b5af0b00014dbd Additional Information 3: 67ea Additional Information 4: 67eaf1bd0951a84db7fbf255fe734343 |
| [2017-07-14 02:08:37] |
| |
|
This is clear evidence of what the underlying problem is: Error reserving space for Time and Sales for symbol. | 2017-07-13 11:23:12 *
You are running out of the available memory. Once this happens, you are going to have all kinds of problems and instability. You must start using multiple instances: Using DTC Server for Data and Trading in Another Sierra Chart Instance: Using DTC Server for Data and Trading in Another Sierra Chart Instance Based on my own history of threaded programming it has the feeling of a thread race (multiple things accessing the same data without a lock) somewhere. No this is definitely not the case at all.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2017-07-14 19:09:57] |
| i960 - Posts: 360 |
|
You are running out of the available memory. Once this happens, you are going to have all kinds of problems and instability. So then why proceed past that and allow exceptions to continue? I've clearly watched it have enough available memory and the exceptions still continue on and on. And if I exit and my chartbooks are truncated to 18 bytes? There's absolutely no reason for SC to be allowing itself into this state regardless of if a user hits out of memory or not. The fact of the matter is that the program becomes unstable and does destructive things after that exception occurs. |
| [2017-07-14 19:42:17] |
| |
|
And if I exit and my chartbooks are truncated to 18 bytes? 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. Also, there are backup Chartbooks saved: Chartbooks (Workspaces): Accessing a Backup Chartbook File 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. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2017-07-15 14:09:25
|
| [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
|
| [2017-07-17 03:20:13] |
| |
|
Clearly I'm not but SC is truncating the chartbooks anyway.
This is completely impossible. Sierra Chart will not save part of a Chartbook. It has no such functionality for that. We do not trust what you are saying based upon your previous postings. Nobody has such a problem. Absolutely nobody has a problem like this when they do not save the Chartbooks. and still ended up with around 10+ chartbooks that had written out the initial SC_CHART_BOOK header and only that stream of bytes. Maybe you have enabled the option to automatically save Chartbooks. SC still remains in this broken state and just catches exceptions on timer events and logs them, forever.
In regards to your other statements, primarily what you are describing is the consequence of the concept of the exception. These exceptions are thrown by the operating system and MFC and STL. We have no control over this. It is not possible for us to catch all of these at the point where they occur. That would be ridiculously complicated and problematic. And there is no way we could possibly catch them all. This is what makes the exception concept so insanely stupid and we totally disagree with them. They put the program into an uncertain and unreliable state with a wild jump of execution to a different location. All significant memory allocations are gracefully and properly handled. And all memory allocationss done by our own string class are properly handled. And gradually we are migrating all strings to our own new class. Basically your statements demonstrate overwhelming ignorance as to the problem that a program developed for the Windows operating system and MFC and STL face. When a program is bombarded with so many exception possibilities due to when memory is low, there is no way it can possibly handle that and get out of the situation safely. It is just simply impossible. You are extremely extremely extremely naïve to believe otherwise. So once again do not blame the consequence of other stupid idiotic programming done by others upon us. You really really are demonstrating massive ignorance by thinking that Sierra Chart is both the operating system and all libraries and operates in complete isolation. This is just not the case. So not only are you seeing a stability problem within Sierra Chart due to faulty programming by others, but also the operating system, MFC and STL. And other libraries like parsers. To think all those others are perfect is completely ludicrous. They are all having problems. There simply is no safe way of recovery, once you run out of memory. Even if we did everything perfect in regards to catching exceptions everywhere, which is incredibly impossible, we would be working until we die, it does not change the fact that there is stability problems in all these other components including the operating system. Also your comments are exceedingly ludicrous, being that Sierra Chart is one of the most stable and reliable programs that runs on Windows. This is proven fact. We have tens of copies of Sierra Chart running our servers, for months at a time with complete stability. OK, after reading your entire post, we are going to openly call you "stupid". This is the dumbest commentary we have seen. You are not a knowledgeable programmer who understands the practical realities of programming. And how you cannot possibly be catching exceptions everywhere. This is completely insane and which makes the exception concept totally stupid which we have publicly said that many times. 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 You are not helping us in the slightest, and we are telling you to leave. You are not worth it as a customer.Also any symbol settings related items you have pointed out before generally is just wasting our time. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2017-11-16 09:36:04
|
To post a message in this thread, you need to log in with your Sierra Chart account: