Support Board
Date/Time: Fri, 27 Dec 2024 00:20:19 +0000
*IMPORTANT* Notice: Custom Study Improperly Altering Time Scale of Chart
View Count: 5011
| [2020-11-30 17:27:32] |
| |
|
There have been reports of custom studies being used by users, which are changing the Timescale of a chart. Users are seeing 0:00 on the timescale at each bar or the columns after the last bar in the chart have an incorrect time or 0:00. The reason for this is due to the change described with some ACSIL functions in the notes for version 2195: https://www.sierrachart.com/index.php?page=doc/Whats_New.php#SCVer2195 This is an unexpected issue. It is due to essentially a corruption of the stack altering one of the input parameters. The first step is to contact the developer of the custom studies and have them rebuild the studies on Sierra Chart version 2195 or higher. Until the custom studies which are triggering the issue are recompiled, run Sierra Chart in Safe Mode: Sierra Chart - Software Login Instructions: Using Safe Mode 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: 2020-12-05 04:03:38
|
| [2020-12-04 20:38:22] |
| Ackin - Posts: 1865 |
|
If you are the developer of a custom study, never change the elements of this array:
Nobody changes it. The statement above is incorrect. This error occurs after updating the SC when the user does not recompile the library (or when use a third-party library that is not recompiled to a newer version). This is related to the change in SCDateTime functionality described in the 2195 notes. https://www.sierrachart.com/index.php?page=doc/Whats_New.php#SCVer2195 Try this code below recompiled in version 2192 and open Sierrachart 2204. You will get a result with zeros on the axis. (attached file) SCSFExport scsf_example(SCStudyInterfaceRef sc) { if (sc.SetDefaults) { sc.GraphName = "Example"; sc.GraphRegion = 1; sc.AutoLoop = 0; return; } for (int BarIndex = sc.UpdateStartIndex; BarIndex < sc.ArraySize; BarIndex++) { if (BarIndex > 0) { SCDateTime PreviousTradingDayStartDateTimeOfBar = sc.GetTradingDayStartDateTimeOfBar(sc.BaseDateTimeIn[BarIndex - 1]); SCDateTime TradingDayStartDateTimeOfBar = sc.GetTradingDayStartDateTimeOfBar(sc.BaseDateTimeIn[BarIndex]); } } } This is not to say that you are doing something wrong. You warned in advance that libraries should be recompiled. Just my opinion: If the content of a feature changes significantly in this way, it should be a "forced update," not just a "recommended update." Date Time Of Last Edit: 2020-12-04 23:11:08
|
 Lib_v2192_in_SC_v2204.png / V - Attached On 2020-12-04 20:36:37 UTC - Size: 36.94 KB - 459 views |
| [2020-12-04 22:49:08] |
| gomifromparis - Posts: 244 |
|
Same here, had a study with the issue and had to recompile with v2195 lib. Seems like a side effect of some change you guys made. |
| [2020-12-05 01:20:18] |
| |
|
We do not see how what is described in post #2 is even technically possible but we will test. Unless maybe there is an unexpected stack corruption occurring causing some unexpected side effect like this which we would expect is not the case but might be. We will find out. 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: 2020-12-05 01:24:03
|
| [2020-12-05 03:59:07] |
| |
|
We have confirmed what is described in post #2 is correct. There is a stack corruption occurring. We did not believe that was the case because the size of the return type remains the same. It is 8 bytes. Previously a 64-bit double now a 64-bit integer within the SCDateTime type which itself is only a 64-bit object. So we are not sure why the date-time value passed in to sc.sc.GetTradingDayStartDateTimeOfBar is getting changed to 0. We will update post #1. We do apologize for putting the fault on some unknown programmer making an apparent mistake when it was something else. 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: 2020-12-05 03:59:57
|
| [2020-12-05 09:17:59] |
| Ackin - Posts: 1865 |
|
Nothing has happened. You have notified the update in advance. You made a lot of fundamental changes in a very short time - it has to show up somewhere ... so you have my admiration that the sierra is moving forward so fast.
Date Time Of Last Edit: 2020-12-05 09:43:19
|
| [2020-12-05 18:25:01] |
| User816220 - Posts: 80 |
|
It could be a calling convention mismatch. The Windows x64 calling convention passes and returns integers and doubles in different registers; integers in the 64-bit integer registers and doubles in the 128-bit XMM registers. https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160 Parameter passing
By default, the x64 calling convention passes the first four arguments to a function in registers. The registers used for these arguments depend on the position and type of the argument. Remaining arguments get pushed on the stack in right-to-left order. Integer valued arguments in the leftmost four positions are passed in left-to-right order in RCX, RDX, R8, and R9, respectively. The fifth and higher arguments are passed on the stack as previously described. All integer arguments in registers are right-justified, so the callee can ignore the upper bits of the register and access only the portion of the register necessary. Any floating-point and double-precision arguments in the first four parameters are passed in XMM0 - XMM3, depending on position. Floating-point values are only placed in the integer registers RCX, RDX, R8, and R9 when there are varargs arguments. For details, see Varargs. Similarly, the XMM0 - XMM3 registers are ignored when the corresponding argument is an integer or pointer type. Return values
A scalar return value that can fit into 64 bits, including the __m64 type, is returned through RAX. Non-scalar types including floats, doubles, and vector types such as __m128, __m128i, __m128d are returned in XMM0. The state of unused bits in the value returned in RAX or XMM0 is undefined. |
| [2020-12-05 22:29:00] |
| |
|
Yes this does make sense and is the explanation for the problem. When we mentioned "stack corruption" that may not have been the right technical term but what we were thinking is that the new implementation of the affected ACSIL functions in newer versions of Sierra Chart had a different arrangement on the stack and registers for the return value and function parameter and as compared to the DLL and was modifying the variables in the wrong location relative to the arrangement of them on the stack by the DLL. 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: 2020-12-05 22:37:46
|
To post a message in this thread, you need to log in with your Sierra Chart account: