Support Board
Date/Time: Tue, 26 Nov 2024 11:31:27 +0000
Dynamic Memory Allocation
View Count: 2454
[2014-03-07 10:09:22] |
Perseus - Posts: 30 |
I am using the example given here: http://www.sierrachart.com/index.php?page=doc/doc_ACSILProgrammingConcepts.html#DynamicMemoryAllocations When I modify the example to access array elements such as adding "p_DoubleArray[0] = 0;" I start getting the following message in the log: "Warning: The Custom DLL study *** has just caused a CPU exception." If I am not accessing the array elements correctly then please provide an example of how to do this. Thanks. |
[2014-03-08 07:11:20] |
Perseus - Posts: 30 |
Anyone else got setting/getting array elements working (using the above method) without causing CPU exceptions?
|
[2014-03-08 07:38:30] |
ejtrader - Posts: 688 |
Haven't gone through the details - but have you tried with sc.FreeDLL = 0; ?
|
[2014-03-08 07:58:05] |
Sierra Chart Engineering - Posts: 104368 |
We did respond earlier but the response we gave we realized was not relevant to the issue. We have tested this code and it worked properly: SCSFExport scsf_DynamicMemoryAllocationExample(SCStudyInterfaceRef sc)
{ if (sc.SetDefaults) { // Set the configuration and defaults sc.GraphName = "Dynamic Memory Allocation Example"; sc.AutoLoop = 1; // During development set this flag to 1, so the DLL can be modified. When development is done, set it to 0 to improve performance. sc.FreeDLL = 0; return; } // Do data processing double * p_DoubleArray = (double*)sc.PersistVars->i1; if(sc.LastCallToFunction) { if(p_DoubleArray != NULL) { delete p_DoubleArray; sc.PersistVars->i1 = NULL; } return; } if(p_DoubleArray == NULL) { //Allocate an array of 1024 doubles. p_DoubleArray = (double *) new double[1024]; if(p_DoubleArray != NULL) sc.PersistVars->i1 = (int)p_DoubleArray; else return; } //assign value to one of the elements p_DoubleArray[0] = 100; return; } Therefore, there must be some other problem going on. We cannot completely see your code. What happens when you test the function above as it is. 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: 2014-03-08 07:58:28
|
[2014-03-08 11:20:41] |
Perseus - Posts: 30 |
ejtrader: Thanks for your suggestion. My understanding is that this is only required when using global variables / variables defined outside the study function. SC can you comment on this? Is setting FreeDLL to zero a requirement for dynamic allocation to work properly? SC: I tried the function you supplied which is very close the function I have been working with (apart from using an integer array). It still causes an exception. Setting FreeDLL to either 0 or 1 has no effect. Any idea what could be the cause of this? Is it possible to increase the level of the log to get a better view of what could be causing the problem? I am using SC v. 1094 by the way. |
[2014-03-08 12:08:01] |
Perseus - Posts: 30 |
SC, I tried the code you posted in an empty DLL and now it seems that I am not getting the CPU exceptions. I must assume that there is something in my original DLL that is causing the problem. The contents are only SCSFExports and a few utility functions - no global variables. Any idea what could cause the exceptions?
|
[2014-03-10 07:58:12] |
User61322 - Posts: 8 |
Hi, I tried this code. It does not generate exception at " p_DoubleArray[0] = 100;". But it does at " delete p_DoubleArray; ". More over when I put break point at "sc.PersistVars->i1 = NULL;" the debugger will not break at this line. It seems it does not execute code behind "delete". I have installed SC 1102 . And use Visual C++ 2010 Express. |
[2014-03-10 08:58:05] |
Perseus - Posts: 30 |
User61322: As I understand it, what you are describing does not sound like an error. There should be no code left to run after "delete" since that statement is in fact the last code executed (see sc.LastCallToFunction). As mentioned above, dynamic allocation seems to be working fine. The CPU exception I am getting is based on something in my DLL (which contains other functions than scsf_DynamicMemoryAllocationExample). A "clean" DLL with only scsf_DynamicMemoryAllocationExample runs without causing an exception. |
[2014-03-10 12:19:16] |
User61322 - Posts: 8 |
To SC support: If you add "sc.UpdateAlways =1;" to yours example you will get exceptions also when accessing the Array, " p_DoubleArray[0] = 100; ". to User61322: if you put break points at lines "sc.PersistVars->i1 = NULL;" or "return;" in the block if(sc.LastCallToFunction) debugger will not break on them. I am examining the code in Sierra Chart Engineering - Posts: 10257. Nice day. |
[2014-03-10 17:39:12] |
Sierra Chart Engineering - Posts: 104368 |
If you add "sc.UpdateAlways =1;" to yours example you will get exceptions also when accessing the Array, " p_DoubleArray[0] = 100; ". We have an idea what the problem is. When allocating and releasing memory, probably there is a problem when sc.FreeDLL= 1. Therefore, set it to 0. Most likely this is the source of the problem. After recompiling the source code, remove the study from the chart and re-add it. 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: 2014-03-10 17:42:34
|
[2014-05-05 00:00:42] |
wwwingman - Posts: 185 |
I have the same problem and this makes persistence data saving of objects problematic with Visual C++ Express 2010 (and 2013). No problem with MinGW. The sc.FreeDLL = 0 "solves" the problem but it means you have to restart Sierra after each compiling. This is not usable for me. Do you think a better solution will be available ? W. |
[2014-05-05 01:38:11] |
Sierra Chart Engineering - Posts: 104368 |
No.
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 |
[2014-05-06 10:48:56] |
User61322 - Posts: 8 |
Yes I follow your recommendation and set sc.FreeDLL = 0. It works. However with respect to other users the comment "// During development set this flag to 1, so the DLL can be modified. When development is done, set it to 0 to improve performance." in the example code is a bit confusing. Thank you for your help. Regards.
|
[2014-05-06 11:17:01] |
wwwingman - Posts: 185 |
Since the problem is now identified as related to the DLL unload/load architecture and persistence of data between events in case of an unload, it means we MUST rely on Sierra persistent vars/data block or on another persistence mechanism we add/make. It also means the problem is not related to Visual Studio and that the fact that data is not destroyed with MinGW should be considered as accidental. If of interest, I am considering this for persistency (since the SierraChart Persistency vars is not enough for my needs) : http://channel9.msdn.com/Blogs/Interoperability/Redis-on-Windows-Getting-Started Again thank you. W. Date Time Of Last Edit: 2014-05-06 18:53:44
|
[2014-05-06 18:21:43] |
Sierra Chart Engineering - Posts: 104368 |
One thing we can do is add memory allocation and freeing functions to the "sc" structure interface. This should solve 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 |
[2014-05-06 21:32:52] |
wwwingman - Posts: 185 |
> One thing we can do is add memory allocation and freeing functions to the "sc" structure interface. This should solve the problem. This can indeed make my development easier, and faster in execution. Thank you for considering this solution. W. |
[2014-05-06 22:22:12] |
Sierra Chart Engineering - Posts: 104368 |
We will try to get this out within 10 days.
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 |
To post a message in this thread, you need to log in with your Sierra Chart account: