Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Fri, 26 Apr 2024 11:51:07 +0000
[Programming Help] - Two issues with my custom study incl. crashing computer during replay
View Count: 1179
| [2018-10-07 17:26:14] |
| Yoda - Posts: 106 |
|
I created a custom trading study that has two issues that I hope someone can help me with. I've attached a copy of my chart book and the cpp file. This custom trading study should: BUY when price crosses and closes above a moving average line and SELL when the price crosses and closes below the moving average line. Exits should happen in reverse: BUY EXIT when price crosses and closes below the moving average & SELL EXIT when price crosses and closes above the moving average. Issue #1 - The buy & sell works, but the exits do not work. It appears that the trade is closed based on the Trade Window setting. Issue #2 - The script sometimes crashes my computer during a replay. I've read thru Sierra Chart Unexpectedly Shutting Down | Memory Errors | Unusual Software Problems | Exception Errors | Freezing of User Interface and particularly the paragraph that states "Under no circumstances does a program like Sierra Chart which is a normal program that uses standard operating system functions, cause a computer to restart or freeze." I understand this, however based on the error messages, I do believe that my custom study is crashing the computer and I do not have faulty hardware. The crash usually happens after running the script thru Replay a few times. Depending on how many days I'm back testing, the computer will either recover from the crash or will completely shutdown. I've been testing the script with SC data for NQZ18 for the period of 2018-09-01 to 2018-09-30. I've been testing on the 15 min time period. From the SC Message Log I see a "Windows error code 1455: The paging file is too small for this operation to complete" And from the Windows Event Viewer I see the following message: " The following programs consumer the most virtual memory: SierraChart_64.exe (12824) consumed 71808061440 bytes, MsMPEng.exe(628) consumed 149725184 bytes, and explorer.exe(4168) consumed 125263872 bytes" The paging file was set to automatic. However, to try to stop the crashing I increased it to 40 GB, but obviously considering how much memory SC is consuming, this still didn't stop the crashing. Additional details: Sierra Chart Version: 1815 64-bit DLL: Is created using Remote Build Data used: SC Data - All Services [data] OS: Windows 10 pro HD: Samsung Pro 960 NVMe Memory: 32 GB Anti-Virus: Only Windows Defender & SC folder is excluded from program |
 MAvgX-Shared-20181007-1057.cpp - Attached On 2018-10-07 17:07:13 UTC - Size: 7.7 KB - 308 views MAvgX-Shared-20181007-1140.Cht - Attached On 2018-10-07 17:07:25 UTC - Size: 30.01 KB - 293 views |
| [2018-10-07 22:34:17] |
| |
|
but obviously considering how much memory SC is consuming, this still didn't stop the crashing. You mean how much memory your study is using or whatever it is doing to cause such memory use by the system.. Depending on how many days I'm back testing, the computer will either recover from the crash or will completely shutdown. There is something seriously wrong with your custom study or what you are doing or with your system if you are running into this kind of an issue.From the SC Message Log I see a "Windows error code 1455: The paging file is too small for this operation to complete" And from the Windows Event Viewer I see the following message: " The following programs consumer the most virtual memory: SierraChart_64.exe (12824) consumed 71808061440 bytes, MsMPEng.exe(628) consumed 149725184 bytes, and explorer.exe(4168) consumed 125263872 bytes" 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: 2018-10-07 22:38:07
|
| [2018-10-08 00:48:05] |
| Yoda - Posts: 106 |
|
Something is terribly wrong with your custom study or what it is doing. And it is not Sierra Chart itself. Or perhaps something wrong with the compiler itself. Or another program on the system is using so much memory.
I completely agree that this has something to do with my custom study which is why I titled this "Two issues with my custom study", filed it under Programming Help and included my custom study hoping that someone would look at the study and let me know what I'm doing wrong. I'm also assuming that there isn't anything wrong with the compiler since I used SC's online compiler. |
| [2018-10-08 01:00:36] |
| |
|
I'm also assuming that there isn't anything wrong with the compiler since I used SC's online compiler. We would not think so but we cannot rule that out 100% because this is not a Microsoft compiler.We had a quick look now at your cpp code, and there is nothing there of any concern. What we suspect at this point in time is that there is another program on your system causing a lot of memory use maybe when Sierra Chart is reading an Intraday data file. Perhaps the operating system. What is the size of the intraday data file you are back testing with? When you check the SierraChart.exe process in the Windows Task Manager at the time of this problem, what is its memory use? 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: 2018-10-08 01:09:07
|
| [2018-10-08 01:49:08] |
| Yoda - Posts: 106 |
|
We had a quick look now at your cpp code, and there is nothing there of any concern.
Thank you for looking. What is the size of the intraday data file you are back testing with?
NQZ18.scid is only 215,033 KB When you check the SierraChart.exe process in the Windows Task Manager at the time of this problem, what is its memory use?
I've shutdown most other programs on my computer and reran the above chart book with my custom indicator. I can report the following results from the Task Manager: SierraChart_64.exe (SC) starts off at 0% CPU and 40MB Memory. During the 1st replay of 3 days (Sept 26 - 28, 2018 @ 15min) the CPU maxes out at 14% while the memory steadly grows to 1,530 MB. After the replay ends, SC's memory does not reduce. So when I start the 2nd 3 day replay, the memory continues to grow from 1,530 MB to over 3k MB. Each subsequent replay increases the memory used by SC until my computer crashes. What we suspect at this point in time is that there is another program on your system causing a lot of memory use maybe when Sierra Chart is reading an Intraday data file. Perhaps the operating system.
While I'm running SC, no other program in Task Manager exceeds 1% CPU or Memory of 150 MB. |
| [2018-10-08 03:20:47] |
| |
|
Based on user feedback set this to 0 instead of 1 sc.FreeDLL = 1;
If that resolves the problem we want to know why this is causing a problem. It is certainly not Sierra Chart which is allocating this memory. It could not be . This is as we said is utterly ridiculous amount of memory. Is there some other program running on your system which has access to the Sierra Chart address space allocating this memory. Normally we would suspect the operating system. That could be it but if this were the case we would think we would hear about this kind of issue more often. 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: 2018-10-08 03:21:12
|
| [2018-10-08 03:47:08] |
| Yoda - Posts: 106 |
|
Based on user feedback set this to 0 instead of 1
This resolved the issue with SC's memory never going over 43 MB after running the replays a couple of times for the full month of September 2018. This also significantly reduced the CPU usage during most of the replay. It only went over 14% once during the replay and didn't stay there for very long. Is there some other program running on your system which has access to the Sierra Chart address space allocating this memory.
How can I determine this? According to the Task Manager, no other program is increasing their memory usage or CPU while SC is running. |
| [2018-10-08 03:57:19] |
| |
|
Certainly reducing CPU usage is known and you will get a warning in the Sierra Chart Message Log about this variable being set to true and affecting performance. The insane amount of memory use has got to be something running on the system that is allocating within the Sierra Chart address space. Like we said most likely the operating system but we are going to run a test now to see if that is happening. If not, then we would have to assume some kind of driver or other security software on your system. We did run a test now and we can see that it is not the operating system allocating this memory. We are testing on Windows server 2008. There is no change in memory use when running a chart replay with that custom study , at least not of significance. It is about 38 MB. So it would be good for you to determine what this is and let us know and then we can write up some information about this. Our recommendation is to disable non-Microsoft services on your system to see if it is one of those. And for the record, it is when Sierra Chart is calling the operating system function LoadLibrary is what is triggering the problem. 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: 2018-10-08 04:16:55
|
| [2018-10-08 05:24:16] |
| Yoda - Posts: 106 |
|
So it would be good for you to determine what this is and let us know and then we can write up some information about this. Our recommendation is to disable non-Microsoft services on your system to see if it is one of those.
I very much appreciate you looking into this. I closed all other programs, turned off Windows Defender and I continue to have a steady increasing memory usage when sc.FreeDLL is set to 1. So as you suggested, I started disabling all non-Microsoft services and then the Microsoft services which the system would allow me to disable. All the while, shutting down, reopening and testing SC. I disabled all services except 33 which could not be disabled (see attached screenshot). Unfortunately, the increasing memory issue never went away. I'm at a loss of what else I can do to track down the issue. If you have any other ideas please let me know, otherwise I think we will have to leave it as an unsolved issue. |
 2018-10-08 00_07_14-Services-Running.png / V - Attached On 2018-10-08 05:19:03 UTC - Size: 106.04 KB - 242 views |
| [2018-10-08 06:06:56] |
| Yoda - Posts: 106 |
|
I would like to take a moment to revisit issue #1 and ask if anyone could have a look at my cpp file attached in the first post and let me know why the exits are not working. I'm using the same code for the buy exit as I use for the sell and the same code for the sell exit as I use for the buy. Since the buy and sell work, I cannot understand why the exits don't work. It appears to me that the exits are based on the Trade Window and not my exit code. Therefore, is there perhaps some line I'm missing to tell SC to use the exit code and ignore the Trade Window? |
| [2018-10-08 06:35:17] |
| |
|
In regards to post #9, we think this is some kind of Windows 10 issue. Even if in the hypothetical case Sierra Chart is not releasing the DLL before calling LoadLibrary again, that would not cause increasing memory use. And if that were the case, users would not be able to make code changes using Remote Build. Saving of the new file would fail. And we apologize for having you go through all that task related to services. We just did not really think this would have been a Windows issue but apparently it is. If indeed this is a Windows 10 issue, it only shows the deteriorating state of the Windows platform as we have been saying all along. Although eventually they are going to have to fix this. It is too ridiculous and absurd for it to go on. 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: 2018-10-08 06:56:46
|
| [2018-10-08 08:40:36] |
| |
|
What we have decided to do is we are going to implement centralized tracking of DLL loading, and only release a DLL only when doing a remote build and when the user manually releases it. A problem like this is very detrimental and you are not the only user who has experienced it. There is probably more problems than we are aware of. 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: 2018-10-08 08:47:27
|
| [2018-10-08 13:02:56] |
| binaryduke - Posts: 360 |
|
and only release a DLL only when doing a remote build and when the user manually releases it.
Are you saying that only DLLs built using remote build will be supported? If so, better I suggest to release DLLs that are remote build OR manually released by a user. There are scenarios for library inclusion where the remote build is insufficient and local build in e.g. Visual Studio is necessary. |
To post a message in this thread, you need to log in with your Sierra Chart account: