Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Thu, 18 Apr 2024 22:42:02 +0000
Caught an unhandled exception in AsyncWindowProc for ACSIL Study
View Count: 958
| [2015-11-22 01:09:27] |
| Jayturn - Posts: 15 |
|
I have been developing a custom ACSIL study for quite some time and recently this exception message has started arising a few minutes after the study has loaded. It is being run on historical data only. Unfortunately I don't have any way of debugging the exception logic myself to identify where I may be going wrong in my code. Can you please provide me with information relating to where this error is triggered and what commonly causes it so I can resolve my code accordingly? Steps taken to reproduce issue: - Open SierraCharts - Disconnect from Data Feed - Open Chart Book where the custom ACSIL study is attached - Wait a few minutes for the exception message to be logged in the Message Log Window Copy of the Log is below: Software version: 1323 | 2015-11-22 00:48:18
Uses New Spreadsheets | 2015-11-22 00:48:18 Usage end date: 2015-11-22 | 2015-11-22 00:48:18 Enabled for: Advanced Features. | 2015-11-22 00:48:18 Enabled for: Advanced Features 2. | 2015-11-22 00:48:18 Enabled for: Sierra Chart Historical Data Service. | 2015-11-22 00:48:18 Allow Support for Sierra Chart Data Feeds is enabled. | 2015-11-22 00:48:18 Current selected Data/Trading service: SC Historical Data | 2015-11-22 00:48:18 Chart Update Interval: 500 | 2015-11-22 00:48:18 Time Zone: +00:00:00 (UTC+00) | 2015-11-22 00:48:18 2015-11-21 19:48:18 Local computer time | 2015-11-22 00:48:18 2015-11-22 00:48:18 Local computer time in UTC | 2015-11-22 00:48:18 2015-11-22 00:48:18 Local computer time in SC Time Zone | 2015-11-22 00:48:18 Program path: C:\SierraChart\ | 2015-11-22 00:48:18 Data Files path: F:\Trading\Data\SierraCharts\ | 2015-11-22 00:48:18 OS Version Number: 6.2 | 2015-11-22 00:48:18 Locale Information: C | 2015-11-22 00:48:18 Checking for new symbol settings for ddf | 2015-11-22 00:48:18 HTTP connection to www.sierrachart.com:80 (0) | Resolved address sierrachart.com to IP 5.9.8.236 | 2015-11-22 00:48:18 HTTP connection to www.sierrachart.com:80 (3) | Connected. | 2015-11-22 00:48:20 SC Historical Data | Connected to data server. | 2015-11-22 00:48:23 SC Historical Data | Historical Intraday data will now be requested. | 2015-11-22 00:48:23 File >> Disconnect selected. | 2015-11-22 00:48:29 SC Historical Data | Disconnected | 2015-11-22 00:48:29 Symbol settings are up-to-date for ddf | 2015-11-22 00:48:30 Notice: The study 'Support and Resistance Lines' has sc.FreeDLL set to true. Use only during development! Set to false to reduce CPU time. | 2015-11-22 00:48:31 Intraday data recording state for symbol ESH13 is set to download 'Pending'. | 2015-11-22 00:48:31 HD Request # 2 | Downloading Intraday chart data for ESH13 to the file ESH13.scid. Service: cme | 2015-11-22 00:48:31 HD Request # 2 | Download start Date-Time: 2013-03-15 13:29:59.000 | 2015-11-22 00:48:31 HD Request # 2 | Using server: scdf1.sierracharts.com port 10149 | 2015-11-22 00:48:31 Socket (0) | Resolved address ds6.sierracharts.com to IP 8.18.161.131 | 2015-11-22 00:48:31 Socket (4) | Connected. | 2015-11-22 00:48:34 HD Request # 2 | Sending historical data logon request message. | 2015-11-22 00:48:34 HTTP connection to www.sierrachart.com:80 (3) | Closed. No error. | 2015-11-22 00:48:35 HTTP connection to www.sierrachart.com:80 (3) | Shutdown and closed. | 2015-11-22 00:48:35 HD Request # 2 | Requesting Intraday data. Start Date-Time: 2013-03-15 13:29:59. Record interval: 0. Symbol: ESH13 | 2015-11-22 00:48:38 HD Request # 2 | Decompressing data. | 2015-11-22 00:48:41 HD Request # 2 | Receiving Intraday data for ESH13 starting at 2013-03-15 13:29:59 | 2015-11-22 00:48:41 Socket (4) | Shutdown and closed. | 2015-11-22 00:48:41 The network socket for historical data has been closed. | 2015-11-22 00:48:41 Chart #3 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:42 Chart #3 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:42 Chart #5 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:42 Chart #5 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:42 Chart #4 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:42 Chart #4 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:42 HD Request # 2 | Historical data for ESH13 is delayed because connection to main data feed is not present. Current data will be received upon connection. | 2015-11-22 00:48:42 HD Request # 2 | Received 4 records from 2013-03-15 13:29:59 to 2013-03-15 13:29:59 (0.0 seconds) and wrote 0 records for ESH13 | 2015-11-22 00:48:42 HD Request # 2 | Intraday download COMPLETE for ESH13. Completion time: 11s. Unique request ID: 1 | 2015-11-22 00:48:42 Removed historical data download ID 1 | 2015-11-22 00:48:42 ESH13 50 Trades #1 | Performing a full recalculation because it has been tagged. Chartbook: JayES.cht | 2015-11-22 00:48:42 Chart #2 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:54 Chart #3 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:54 Chart #4 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:54 Chart #5 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:54 Chart #7 has tagged chart #1 for full recalculation. Chartbook: JayES.cht | 2015-11-22 00:48:54 ESH13 50 Trades #1 | Performing a full recalculation because it has been tagged. Chartbook: JayES.cht | 2015-11-22 00:48:54 Caught an unhandled exception in AsyncWindowProc. Message: 1025, wParam: 5, lParam: 72 | 2015-11-22 00:51:17 * |
| [2015-11-22 02:40:28] |
| |
|
Refer to help topic 17: Http://www.sierrachart.com/index.php?page=doc/helpdetails17.html We cannot answer your question because where in the code this is triggered is completely irrelevant and not useful in any way. What we think is that your code is causing a memory corruption which usually happens when violating the bounds of an array. 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: 2015-11-22 02:41:13
|
| [2015-11-22 03:51:58] |
| Jayturn - Posts: 15 |
|
Thank you for the response Sierra Chart Engineering. You are most likely correct about memory corruption being the issue, though it's related to my introduction of the log4cplus library to manage various facets of my custom study logging. If I disable my object interface, forming a connection between the ACSIL Study and the Log4Cplus DLL, the error doesn't occur. The reason I asked you for more details around error message 1025 and the parameters provided is so I can get an idea of what is breaking. I know you guys won't help me debug an issue with the level of custom development I am going to, however right now the only thing I have to go on is an ambiguous error message (Message: 1025) that doesn't help me. Can you please at least provide me with the description of the message 1025 and what wParam and iParam points to? |
| [2015-11-22 04:19:06] |
| |
|
Is this something that you developed?: "Log4Cplus library" "message 1025 and what wParam and iParam points to". 1025 is a message code used for various messages within Sierra Chart. It is nonspecific. For your information, if we saw this error while we were doing debugging, in most cases we would not even bother to check any of these parameters because they are not relevant to the problem. And assuming we did look at the message for more details, we would only look at the 1025 message code parameter which is nonspecific. The additional parameters are totally irrelevant. Also that message can occur for numerous reasons and to us it is very vague as to where exactly it is happening. So the message in and of itself basically tells us very little. Please trust us when you we say that you are going very far off course by putting attention on the details of that message. The only thing you need to know, is that most likely memory is getting corrupted. Memory corruptions can cause totally unrelated problems and problems at a later point in time compared to when the corruption occurred. You really should perform step-by-step debugging. Refer to the documentation for the instructions for that for Visual C++. Usually when an exception occurs in a program and the program is terminated by the operating system and the operating system provides a large amount of details which include the memory address where the exception occurred, the exception code, CPU register values, and numerous other details, none of that other than the exception code is something that we pay attention to because most that information is too low-level to be useful. We may look at the address where the exception occurred in the case of an access violation exception to see if it is very close to zero which indicates the use of a null pointer. 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: 2015-11-22 07:34:55
|
| [2015-11-22 21:28:46] |
| Jayturn - Posts: 15 |
|
Thank you Sierra Chart Engineering. The "Log4Cplus Library" is a popular C++ library used for application logging, allowing for the creation and separation of log files based on severity levels. My study is integrated with a number of classes I've built into various DLL's with UnQlite integration for database storage, so I'm very familiar with C++ programming. Thanks for explaining the generic nature of the 1025 message code. I suspect somewhere along the line there is a pointer to an object that isn't being destroyed and leading to a memory leak. It's difficult to debug due to occurring about 3-4 minutes after the study has loaded. I appreciate the time you took to respond. |
To post a message in this thread, you need to log in with your Sierra Chart account: