Support Board
Date/Time: Fri, 22 Nov 2024 21:11:18 +0000
OpenGL Exception/Stability Issues
View Count: 4815
| [2020-06-05 01:21:34] |
| Tooth Fairy - Posts: 79 |
|
ESM20_FUT_CME[M] Rev. 2t #1 | Caught exception in c_Chart::DrawStudyGraph. | 2020-06-04 20:55:00.979 * Unhandled Exceptions in chart drawings, in market historical depth loading, etc, makes OpenGL really unpredictable. Sometimes it loads & works several days then the next day, it rears its ugly head against. And when it crashes, it took down the whole system w/ them so u have to terminate the process and restart the PC. Nothing we can do to make it works w/o crashing so we have to turn it off. And the difference between chart drawing time is like 300ms for non-OpenGL vs 20ms for OpenGL, making interactive chart operation like using 3rd world country toilets. As a group of traders of close to 100 persons w/ different PC configurations, every single one of us has seen the beauty of OpenGL when it works and the ugly side, when it doesn't. (See my screen capture of my 2nd display when SC crashed. The 1st & the 3 displays are completely blank & unresponsive). this problem never goes away since the 1st report of months ago. We just so tired to say the same thing over & over. Just a suggestion. Maybe u need to have a better debugging log & better handling of exceptions so it won't crash the system when your app goes nut. Thank you. Edit: Normal screen do not display icons in a disarray manner like the rioters just went to town. Your SC app did that when it goes nut. Date Time Of Last Edit: 2020-06-05 01:34:42
|
 Screen Shot 6-4-2020 at 5.37 PM.png / V - Attached On 2020-06-05 01:19:56 UTC - Size: 1.24 MB - 737 views |
| [2020-06-05 05:33:39] |
| |
|
so it won't crash the system when your app goes nut. How do you know this? The simple fact is you do not and you are no position to come to such conclusions. This is simply just not correct.The OpenGL software on your system would seem to have a problem if you are running into this level of problem. Maybe you need more GPU memory. We will check on the potential issue involving the GPU memory running low. 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-06-05 06:02:21
|
| [2020-06-05 10:53:09] |
| nosast - Posts: 312 |
|
I also love the performance of OpenGL and there is now way I would ever go back to GDI and update intervals for depth historical bigger than 250ms. But sometimes I also experience stability issues that not crash the whole PC but only SC. Seems like SC will continue in background but no visual updates (heard alerts fire while screen frozen). This never happened on SC with GDI or any other graphic intense app (games,..) I use. Any way to report this issue with logs or something? As I need to restart SC I have no chance to look into the message log files... Checked everything on system and all seems fine. Plenty of RAM and GPU RAM free, also no CPU core maxed out or GPU performance greater than 30% in spikes. Using nvidia quadro P-series with latest drivers. System is super stable beside SC freezing when on Open GL occasionally. Sometimes I'm thinking it starts transparancy issue related (flickering), other times I open a chart with volume profiles per last 100 days in ES and scroll or zoom before the graphics freeze. This issues with Volume profile is happening quite often and could maybe be a tell. Let me know if I could be of any help to get SC on OpenGL as rock solid as SC on GDI. Update: Seems like crashing is not related to Volume Profile! Date Time Of Last Edit: 2020-06-05 17:37:43
|
| [2020-06-05 12:29:30] |
| Tooth Fairy - Posts: 79 |
|
The OpenGL software on your system would seem to have a problem if you are running into this level of problem. Maybe you need more GPU memory. We will check on the potential issue involving the GPU memory running low.
You need a better debugging log so u don't have to assume wrongly then chase the wrong tail forever like this. See the attached images of my system spec. FYI, I am an accomplished hardware/software designer (both disciplines) in my other life. Just a friendly reminder that not all users are stupid in term of technical knowledge. I really love your OpenGL implementation when it works. Very remarkable. Edit: Yesterday, OpenGL works on main & 2nd instance. Today 2nd instance crashed so I turn off OpenGL on 2nd instance. On other days, main didn't. As I said above, u really don't know when or where the rioters going to show up to ruin your days. Edit2: In case it's not obvious, it crashes during loading market depth, sometimes one day depth load helps, sometimes, it doesn't matter. Once it works, it normally not crashing anymore. Edit3: I let 2nd instance running for 30min, change to OpenGL, exit then start new 2nd instance again. It works. Strange thing like this is how we learn to tolerate OpenGL. Pain in the ass if main doesn't work then we need to switch charts around. Date Time Of Last Edit: 2020-06-05 13:03:32
|
| SysSpecImg.png / V - Attached On 2020-06-05 12:27:26 UTC - Size: 208.47 KB - 483 views GPUMemUsage.png / V - Attached On 2020-06-05 12:27:42 UTC - Size: 8.68 KB - 447 views |
| [2020-06-05 13:48:40] |
| Tooth Fairy - Posts: 79 |
|
I do not know whether these things are related to the problem above but this happens a lot lately (prob at the time when version newer than 2092 introduced) when new column is painting, the texts are missing in some rows of several left columns and only black background there. Could it be something related to new compression scheme?
|
Private File |
| [2020-06-06 10:27:06] |
| |
|
We will obtain the same video hardware that you have, thank you for the screenshot showing the hardware, and we will install the same driver. But we want more specific details regarding the driver. We need to specific details shown in the attachment. We also need to get your Chartbook which you are using. Instructions: https://www.sierrachart.com/index.php?page=PostingInformation.php#AttachFile 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-06-06 10:27:27
|
| ExampleVideoDriverDetails.png / V - Attached On 2020-06-06 10:26:52 UTC - Size: 6.9 KB - 398 views |
| [2020-06-07 00:24:23] |
| Tooth Fairy - Posts: 79 |
|
Main: The crash mostly starts w/ chart #1 but sometimes chart #3 did too. 2nd Instance: Chart #4 only. The problem mostly happens during market historical depth load, either crashes while it is still loading or it has finished loading & running while another chart is still loading. Regardless, the historical depth loading is frozen, then the craps hit the fan. If all of them finished loading, then very unlikely u will see exceptions happen or if it happens, it's very rare. What I did during the crash is to exit and not to save anything and try again if it's the main chart. For the 2nd instance, OpenGL isn't a must like the main, so I can turn it off & let it runs for a while, save it then restart w/ OpenGL. Date Time Of Last Edit: 2020-06-07 00:24:44
|
| DriverImage.png / V - Attached On 2020-06-07 00:15:46 UTC - Size: 9.3 KB - 407 views Private File Private File |
| [2020-06-07 07:55:25] |
| |
|
Makes no sense this is associated with loading of historical market depth data because that itself does not involve OpenGL and all of that code is 100% stable. Not to mention the fact that historical market depth data loading will never ever cause system instability and we mean never. That is technically impossible and there has never been a known case of anything like this ever in the history of Sierra Chart. We will test the Chartbooks using OpenGL. 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-06-07 07:57:47
|
| [2020-06-07 08:18:49] |
| Tooth Fairy - Posts: 79 |
|
Maybe a screen capture next time it happens will clarify what I’ve said. I will try some replays to see if it will create problem. I think it does, but not so sure. I am glad that we are both interested into solving this problem one and for all. Once we can pinpoint the root cause, we can put the issue to rest. As a designer myself, it’s totally wasteful to see nice piece of works like this not truly living to its potential. |
| [2020-06-07 08:54:51] |
| |
|
We do not need anything more at this time. Tentatively we think we discovered the problem. OpenGL has been handled by one of our "other" developers who is experienced in this area of development. And I have discovered a core fault with the code. It does not perform memory allocation failure checks. And when there are large memory allocations going on with the loading of market depth data, there can potentially be be memory allocation failures in the OpenGL code like with fonts. And this also means, that the probability that we would be able to reproduce your issue, is very low. So we will have to add error handling for that. But this is also going to mean when there is a failure like this, that there will be a problem with output from OpenGL where it just will not display what it is intended to. We need about a couple of weeks to get this resolved. But this also shows that the operating system cannot be trusted, to always respond to memory allocation requests no matter how much memory is available. Sometimes these allocations will just fail. Now we do not know for sure whether this is really the problem. But there is clearly an issue, where there is not any checking of memory allocation failures or graceful handling of those. 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-06-07 08:58:04
|
| [2020-06-07 09:03:30] |
| nosast - Posts: 312 |
|
Could this also cause occasional freezes of graphics output from SC? As stated above I experience this and need to restart SC to get it back running. I also think it happens when I load a long market profile chart of more than 100 days and have ticks in chart settings combined. In my case ES chart with combining 4 ticks to smoothen profiles. |
| [2020-06-07 09:10:22] |
| |
|
It is hard to say. One thing that it definitely is going to cause is an "exception" error message in the Sierra Chart Message Log and once that starts to happen, the whole state of the program is unstable which then leads to just other subsequent problems. But this should not lead to system instability. That must be happening at the video driver level. But we would also say, that the memory allocations really should not be failing. And we think if we tested the chartbooks given to us we would never reproduce the described 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: 2020-06-07 09:12:56
|
| [2020-06-07 10:05:59] |
| nosast - Posts: 312 |
|
Attached is a chartbook to reproduce the errors. I know that the I have set volume at price multiplier in chart settings and in the profile study which is not necessary. If I only set it in the study no crashes on GL. But when I use the chartbook with both price multipliers with GDI it's stable! Attached also a screenshot from the error messages when the freeze occurs. Hope this helps. Date Time Of Last Edit: 2020-06-07 10:06:25
|
SNAG_ 2020-06-07 - 12.00.39.png / V - Attached On 2020-06-07 10:05:25 UTC - Size: 114.27 KB - 421 views  Crash_Chartbook1.Cht - Attached On 2020-06-07 10:05:42 UTC - Size: 3.24 KB - 407 views Attachment Deleted. |
| [2020-06-07 15:17:24] |
| Tooth Fairy - Posts: 79 |
|
I'd certainly seen some error messages related to exceptions at system event levels making me kinda guessing some connections between loading many days of market depth & the frequency of crashes hence my crude method to limit the depth load to 1 day. So certainly there are weaknesses at system relationship level the way your developer implements his codes. Hopefully, better error handling procedure will reduce the severity reactions & let SC graciously exits or coexists. All for the better. I'm curious that your codes didn't task graphic memory allocation as hard as gaming software. They could eat up 50% of GFX memory like no tomorrow while yours only take like 1 or 2GB of my GFX 8GB memory. I will surely pay attention more into this area next time. Date Time Of Last Edit: 2020-06-07 15:26:05
|
| [2020-06-10 13:47:24] |
| Tooth Fairy - Posts: 79 |
|
Testing 2119 Version now & it seems SC is much gracious in exception handling. I still get this message once in a while during starting the chart but it has not degraded further into WM_PAIN & WM_MOUSEMOVE event cuz once it get there, there is no way out. Triggering next historical data download in queue. | 2020-06-10 09:31:42.090 Loaded depth data records for ESM20_FUT_CME 2020-06-09 from 2020-06-08 20:00:00 to 2020-06-09 20:00:00. | 2020-06-10 09:31:45.090 Loaded depth data records for ESM20_FUT_CME 2020-06-10 from 2020-06-09 20:00:00 to 2020-06-10 09:31:14. | 2020-06-10 09:31:45.732 ESM20_FUT_CME 10 Sec #2 | StartDateTimeForLoadingOrderFills: 00:00:00 | 2020-06-10 09:31:45.748 Opened cached Intraday file: D:\SierraChart\SierraChartInstance_2\Data\ESM20_FUT_CME.scid. Thread ID: 11556 | 2020-06-10 09:31:45.892 ESM20_FUT_CME 10 Sec #2 | Caught exception in c_Chart::DrawStudyGraph. | 2020-06-10 09:31:49.323 * Thanks for the works, guys. Date Time Of Last Edit: 2020-06-11 12:49:31
|
| [2020-06-10 18:12:59] |
| |
|
Even one exception though is a problem. We are still working on thorough handling of out of memory conditions related to graphics.
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-06-10 18:13:34
|
| [2020-06-12 13:12:47] |
| Tooth Fairy - Posts: 79 |
|
I just report the events here because I don't know if it's a separate issue or all related to the same thing whether interrelationship at system level or not. It's for SC to decide. 1) It crashed very hard today & locking up my system so I have to turn OpenGL off. Incidentally, it happens during contract change period. Crashes in many different ways: loaded then crash, crash during load, running for a while then crashes. Totally unstable. 2) NonOpen GL black box appeared as in OpenGL noted in post #5. See attached image. 3) Occasionally missing depth in 1 chart but it appears fine in other chart, side by side. See attached image. The left circle indicates approx time happened in the right-side chart where right red circle indicated. Same study of depth for both. Edit 1: After posting this, I happen to look at # of days market depth loaded, on the main 2 charts show in pic attached, they all have 3 days load, so I change to 1 day and it seems it's working. Contract change, 3 days vs 1 day in market depth loaded, maybe it will give u guys some hints of where the problem located. The black box happens whether I'm using OpenGL or not. Edit 2: To clarify, I didn't change the contract today and stay at ES June contract in all cases. Edit 3: I did change the contract to U20 last night around 6PM PST then decided to switch back to M20 about 30m later. Date Time Of Last Edit: 2020-06-12 22:15:39
|
Private File Private File |
| [2020-06-13 10:43:12] |
| |
|
Test version 2021. We identified a problem where there was an invalid pointer being used, when more than 1000 graphics objects of a particular type were being allocated. This would be a very uncommon condition. We do not know if it is the source of the problem or not.
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-06-13 10:43:40
|
| [2020-06-13 14:33:23] |
| Tooth Fairy - Posts: 79 |
|
I test w/ the rev 2021. Since market is not active, I load the chart & then using replay function which also loads saved historical depth to test. Loading chart by itself doesn't cause any problem perhaps due to market not active. Replay function on the other hand produces this exception "ESM20_FUT_CME 10 Sec #2 | Caught exception in c_Chart::DrawStudyGraph" everytime. The first exception crashes SC to desktop. All other subsequent loads/replays (after restarting SC to make sure it's free from previous error) exceptions just produce that 1 message & SC remains functionally active. I copy the whole message log from the start of SC for u to peruse. Date Time Of Last Edit: 2020-06-13 14:36:00
|
Private File |
| [2020-06-15 00:20:18] |
| |
|
The Message Log in a case like this is of not any value. The only thing we can test is the Chartbook to see if we can reproduce the exceptions but that would be unlikely. Attach the Chartbook by following these instructions: https://www.sierrachart.com/index.php?page=PostingInformation.php#AttachFile 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-06-15 00:20:38
|
| [2020-06-15 00:26:09] |
| Tooth Fairy - Posts: 79 |
|
See attached.
Date Time Of Last Edit: 2020-06-15 00:30:08
|
Private File |
| [2020-06-15 04:01:35] |
| |
|
We will test. Also for the record this was an incorrect conclusion: We identified a problem where there was an invalid pointer being used, when more than 1000 graphics objects of a particular type were being allocated. This would be a very uncommon condition. We do not know if it is the source of the problem or not.
There was not an invalid pointer. There was not a problem to begin with. This was simply an observation that was never actually tested. Testing showed that there was a correct pointer at all times.In general, the only things we have identified, is failure to check for memory allocation errors in the graphics related code and other very exceptional conditions in some areas of OpenGL related code. But when it comes to small memory allocations which are the vast majority of them, those do not need to be checked because if something like 10 bytes of data cannot even be allocated, Sierra Chart cannot even function to begin with. We also tested one of your other Chartbook's which was encountering exceptions (MAIN.Cht). After four days of testing using OpenGL there just was no problem at all. Completely stable. Once again completely stable and no issues. So as time goes by, our original belief that these are system specific issues and the problem lies elsewhere outside of Sierra Chart is proving to be correct so far. Now we could invest in the same hardware that you are using and the same driver and find out what we discover but it should not matter. 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-06-15 04:08:13
|
| [2020-06-15 07:36:48] |
| nosast - Posts: 312 |
|
@SC Did you see my post #13 and test the chartbook attached? When scrolling/zoomhing into the profile chart I can reproduce the crash of SC (last tested with 2119 so I don't know if your latest fixes addressed this). |
| [2020-06-15 12:30:10] |
| samual sprat - Posts: 343 |
|
Just my 2 cents, but i've had these opengl related stability issues since the chartbook format update around 2093. Opengl was Rock Solid before that. Not sure if we're barking up the wrong tree here Just a thought If it helps - my issue is still thereand i'm using NVidia 1070 GTX with latest drivers. Past 2 sets of drivers have same issues Date Time Of Last Edit: 2020-06-15 12:31:36
|
| [2020-06-15 13:34:12] |
| Tooth Fairy - Posts: 79 |
|
We also tested one of your other Chartbook's which was encountering exceptions (MAIN.Cht). After four days of testing using OpenGL there just was no problem at all. Completely stable. Once again completely stable and no issues.
Would u clarify your statement above about your testing method? Load market depth once then let it runs 4 days or continue load then reload like replay function loading market from certain date? So as time goes by, our original belief that these are system specific issues and the problem lies elsewhere outside of Sierra Chart is proving to be correct so far. Now we could invest in the same hardware that you are using and the same driver and find out what we discover but it should not matter.
I understand your assumption if this is just a couple users involved but this is an issue observed by our group having close to 100 users. Our group has a wide diversification of system of desktop & laptop, OS version, revision, graphic cards manufacturing, drivers etc. so it's an extremely low probability of a system-specific issue. The reason I'm the only one speaking here is I wish to keep this channel to be clear of noises that could divert our (you & us) attention. I believe we did not have this problem in version 2054 ish and below (those w/ transparent fill issue). The problem start surfaced after you implemented the new chart book & new compression and never go away since. It's a difficult issue no doubt, but hey it also shows how good u are. I've been there. |
To post a message in this thread, you need to log in with your Sierra Chart account: