Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Fri, 03 May 2024 19:20:04 +0000
OpenGL Exception/Stability Issues
View Count: 4418
| [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. |
| [2020-06-16 03:21:24] |
| |
|
The problem start surfaced after you implemented the new chart book & new compression and never go away since.
Not sure if we're barking up the wrong tree here
It definitively is not related to this at all. And yes you are on the wrong track here. That is with 110% certainty. Additionally that can be confirmed just by not using any custom studies (run in safe mode) and disabling OpenGL and restarting.There could not be any issue related to Chartbooks or compression. That is so so unrelated. And the idea any fault with that, which does not exist, would degenerate into a system stability problem is nothing short of a 100% totally incorrect determination. And we will never ever be proven wrong on that. That we can say with overwhelming confidence. You can quote us on that all over the Internet. We tested the Chartbook given at Post #21 using the OpenGL option in Sierra Chart which is confirmed by the log: OpenGL enabled | 2020-06-16 01:44:11.849
The Chartbook is 100% stable. We did multiple replays, we did multiple scale changes, and we reloaded all the charts multiple times with Edit >> Reload All Charts. No exceptions. Very high-performance, very stable. No problems at all. We will continue to test it for several days. We are using an Intel HD Graphics 4600 display adapter with an Intel driver. We did notice you are running custom studies, so refer to help topic 17 and disable those: Sierra Chart Unexpectedly Shutting Down | Memory Errors | Unusual Software Problems | Exception Errors | Freezing of User Interface 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.
Probably because you are running all the same custom studies which may be the cause of the problem.so it's an extremely low probability of a system-specific issue.
So far the evidence is clear and does not support this. The evidence is very clear that it is system specific.---- Additionally, we are not just testing on one system but two systems. We will check on the specifications of the other system regarding the display adapter. 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-16 04:23:50
|
| [2020-06-16 05:05:42] |
| Tooth Fairy - Posts: 79 |
|
Thank you for your effort. I think we run into an impasse here 1) Safe mode w/o our custom studies in OpenGL doesn't produce exceptions. I did not test it extensively but that's my impression. Hence your claim, it's not OpenGL but the custom studies. 2) Our custom studies running non-OpenGL do not generate exceptions. I did test it extensively hence the developer claims it's not custom studies but OpenGL As far as I understand about coding, there isn't any specific OpenGL requirement to be inserted in in SC environment codes so if it works in non-OpenGl it should work in OpenGL, am I correct? Naturally, if this statement is correct, it's understandable that people would point the finger at OpenGL when their codes work in NonOpenGl but fail in OpenGL. Could it be certain functions will crashes in OpenGL but not in non-OpenGL? Within our group, we only use very few SC studies so we can't test further SC own studies but it should be noted here nosast is not in our group but his chartbook also causes system freeze. By reading his post #13, I think he uses SC studies, not any custom studies I hope, so would you please also test his chart book? Again, thank you for your effort. U & I know we want to make SC a better system. |
| [2020-06-16 07:40:25] |
| nosast - Posts: 290 |
|
Within our group, we only use very few SC studies so we can't test further SC own studies but it should be noted here nosast is not in our group but his chartbook also causes system freeze. By reading his post #13, I think he uses SC studies, not any custom studies I hope, so would you please also test his chart book? There are no custom studies in this chartbook and SC brings an exception an crashes. Not the whole system, only SC needs to be restarted. Message log also posted in #13. Without OpenGL it's completely stable. I tested with 2119 so maybe this issue is already addressed. Will test again after market close with current prerelease. |
| [2020-06-16 10:57:21] |
| samual sprat - Posts: 343 |
|
All things stated taken into account, I am running 2121 stably for past 2 days now. Reason it starts to work is normally because I copy charts to new chartbook and then restart Sierra. Then as long as I don't update Sierra, make and violent changes or fart in the wind, Sierra remain rock solid till you release the next 'fix update'. Nothing in what I just said points to broken custom studies or broken opengl. Imo it points to something broken elsewhere during the update process and which manages to get fixed by tinkering with things after the update. If it's not the chartbook update that breaks Sierra then maybe it's the Sierra update process. Thoughts? Date Time Of Last Edit: 2020-06-16 10:58:17
|
| [2020-06-16 11:46:30] |
| Tooth Fairy - Posts: 79 |
|
@nosast Please leave that chartbook untouched. In testing,at least in my engineering environment, a small change from the original completely makes reproduction of failure impossible. Date Time Of Last Edit: 2020-06-16 12:30:20
|
| [2020-06-16 11:51:05] |
| Tooth Fairy - Posts: 79 |
|
I have exceptions loading on the same chartbook, 1 day depth only, today. It was working yesterday & I didn't do anything at all after that except turning off & on my PC. So I disable OpenGL and it works. I'm pretty sure in our group some have the same problem as I do today and some doesn't. How do you explain this problem? Working in nonOpenGL but utterly fail in OpenGL. You have 2 working environments & no specific requirement to distinguish coding from one to another. Code working in one SHOULD WORK in another, does it not? It seems to me that SC tested the chart w/ the custom studies disable hence can't reproduce the exceptions. Of course, you can't & will not reproduce the failure when you alter the test conditions and in my previous field, any 2 bits test engineer worth employment know that too. In other words, your OpenGL has an Achille heel and that custom codes just kill the poor guy while your NonOpenGL doesn't exhibit the same issue. Is there anyway I can do to help you to test it in the conditions it produces the exception? Edited to clarify & eliminate gobbledygook. LoL. Date Time Of Last Edit: 2020-06-16 15:51:27
|
| [2020-06-16 12:14:43] |
| nosast - Posts: 290 |
|
SC just crashed on me while changing rollover to "continues with back adjusted" on a PNF Chartbook. Never happened before and this really bothers me. I will try to use GDI for testing to reproduce tonight but no way I will trade live without the load shifted to the GPU with OpenGL. There really seems to be an issue with SC, OpenGL and maybe only Nvidia cards? SC rock solid in GDI for years and as far as I can remember also on Open GL but I don't know the version change when it happened to crash constantly. |
| [2020-06-16 12:16:31] |
| nosast - Posts: 290 |
|
@Tooth Fairy: I leave the CB up for sure. Can you test if the issue is gone when you set Volume at Price Multiplier to 1 (default) again? I think it only happens when I aggregate volume to 4 or so. No need to test it under GDI. This was stable for years. Date Time Of Last Edit: 2020-06-16 12:16:54
|
| [2020-06-16 16:08:26] |
| User929084 - Posts: 60 |
|
Last week I switched to OpenGL and got couple exceptions, which I can't remember ever getting before. I'm on version 2102. Most times SC will run smoothly, but it crashed on me 3 maybe 4 times. For me everything will freeze. Can't even move a cursor and it will stay like that for 10-15 seconds and SC will just shut itself down. Never had a crash before with exactly same setup in GDI. I have few custom and user contributed studies on my charts though. Will test later today in safe mode. |
| [2020-06-16 21:39:57] |
| Tooth Fairy - Posts: 79 |
|
@User929084, Safe mode will disable your custom studies. If it works in GDI, no need to test in safe mode. |
| [2020-06-17 06:44:29] |
| User462086 - Posts: 188 |
|
using SC v2122 with OpenGL enabled: i've also been experiencing crashes while interacting with native dialog boxes (Study Settings & Chart Settings). the dialog boxes are unresponsive for a few seconds then the program closes.
|
| [2020-06-17 07:37:13] |
| |
|
In regards to post # 36. Check your custom studies and run Sierra Chart in Safe Mode. We simply do not observe a problem like this at all. We do not see how that is related to 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 |
| [2020-06-17 12:54:21] |
| nosast - Posts: 290 |
|
Crashed again while basically doing nothing special. Just preparing for the day and looking at charts. This happened while I just put one chart to fullscreen... Message log attached. Same messages keep flowing in until SC is restarted. @SC Please guys. This needs to fixed asap. Let me know if I could be of any help. |
 SNAG_ 2020-06-17 - 14.50.36.png / V - Attached On 2020-06-17 12:53:40 UTC - Size: 107.98 KB - 356 views Attachment Deleted. |
| [2020-06-17 13:00:43] |
| nosast - Posts: 290 |
|
If I interpret the message log correct, the exception is caused by chart #11. Attached is a chartbook with this chart. Hope you can read private - otherwise hit me up to send over via email.
Date Time Of Last Edit: 2020-06-17 20:02:19
|
| [2020-06-17 20:02:07] |
| nosast - Posts: 290 |
|
Further testing showed that my above statement is wrong. Looks like the issue is not tied to a specific chart at least in my case. Is there any way to drill down the cause of this issue in the logs?
|
| [2020-06-17 20:46:27] |
| Tooth Fairy - Posts: 79 |
|
@nosast U need to catch it at the beginning, otherwise the message log will be overran by window crashing messages. It always is the first exception message. U need to close the chart book, not sc, then roll back the log to look at the 1st message. Once it’s overran real bad, u can’t even close the chart book so u have to exit sc or terminate the whole process thru task manager. |
| [2020-06-17 21:41:35] |
| @sstfrederik - Posts: 403 |
|
fyi. You can save msg log to file. Global Settings >> General Setting >> General 2 Second check box from above on right side. Logs will be saved in log directory. Date Time Of Last Edit: 2020-06-17 21:41:49
|
| [2020-06-17 23:13:37] |
| nosast - Posts: 290 |
|
@Tooth Fairy @Frederik Thanks! I will activate this setting and grab some logs on next exception. Really need to sort this out. Often times the exception not only halt Sierra but also it just crashes and closes. So logging constantly would be the best bet. Date Time Of Last Edit: 2020-06-17 23:15:53
|
| [2020-06-18 12:35:10] |
| nosast - Posts: 290 |
|
SC just completely crashed will moving a line to prepare for trading day. The line is linked in from another chartbook with a way slower chart update interval. This never caused any problems but may help to get to the roots. Once again it happened on a 60 Min Profile Chartbook, the one I posted above. Log: Triggering next historical data download in queue. | 2020-06-18 07:09:53.017 Socket (2) | Socket gracefully closed by remote side. | 2020-06-18 07:09:53.132 Socket (2) | Closed. | 2020-06-18 07:09:53.132 ESM20_FUT_CME [CB][M] 2 Min #1 | Performing a full recalculation because it has been tagged. Chartbook: Moneyflow.cht | 2020-06-18 07:09:53.678 Opened cached Intraday file: C:\SierraChart\Data\RTYU20_FUT_CME.scid. Thread ID: 13344 | 2020-06-18 07:09:56.747 Opened cached Intraday file: C:\SierraChart\Data\ESM20_FUT_CME.scid. Thread ID: 13344 | 2020-06-18 07:09:56.747 ESU20_FUT_CME [C][M] 2 Min #4 | Performing a full recalculation because it has been tagged. Chartbook: ES-VolumeScope.cht | 2020-06-18 07:10:00.832 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:16.949 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 11534562 | 2020-06-18 07:22:16.950 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:16.950 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 11337956 | 2020-06-18 07:22:16.955 ESU20_FUT_CME[M] #11 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:16.960 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 11206885 | 2020-06-18 07:22:16.967 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 11075814 | 2020-06-18 07:22:16.978 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10944742 | 2020-06-18 07:22:17.002 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10879206 | 2020-06-18 07:22:17.024 ESU20_FUT_CME [CB][M] Aligned Renko 5t #17 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:17.055 ESU20_FUT_CME [CB][M] 1 Sec #1 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:17.056 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10813670 | 2020-06-18 07:22:17.056 ESU20_FUT_CME[M] #11 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:17.069 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10748134 | 2020-06-18 07:22:17.091 ESU20_FUT_CME [CB][M] Aligned Renko 5t #12 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:17.121 ESU20_FUT_CME [CB][M] 50 Trades #5 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:17.128 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10682598 | 2020-06-18 07:22:17.129 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10617062 | 2020-06-18 07:22:17.137 ESU20_FUT_CME [CB][M] 15 Min #6 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:17.170 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10551526 | 2020-06-18 07:22:17.170 ESU20_FUT_CME[M] #11 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:17.178 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10485990 | 2020-06-18 07:22:17.180 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10420454 | 2020-06-18 07:22:17.205 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10354918 | 2020-06-18 07:22:17.238 ESU20_FUT_CME [CB][M] 60 Min #9 | Caught an unhandled exception in c_Chart::WindowProc. Message: 512, wParam: 0, lParam: 10289382 | 2020-06-18 07:22:17.261 ESU20_FUT_CME[M] #11 | Caught an unhandled exception in c_Chart::WindowProc. Message: 15, wParam: 0, lParam: 0 | 2020-06-18 07:22:17.291 Date Time Of Last Edit: 2020-06-18 12:36:45
|
| [2020-06-18 19:46:03] |
| nosast - Posts: 290 |
|
@SC Engineers: Is this part of the message log sufficient to see the chart that caused the exception? Any idea how to dig deeper? |
| [2020-06-18 23:21:55] |
| |
|
We still want to test one of the other Chartbook's in this thread but we do not expect we will notice any problem. Regarding the last two posts above, these messages just indicate that we need to get the Chartbook and test it and then reproduce the problem under a debugger. If we cannot reproduce the problem then we do not know what the exact cause is. We are absolutely totally astounded at the level of problems being reported here when using OpenGL and we have tested Sierra Chart on three different systems using multiple Chartbooks from this thread and everything works perfectly, zero trouble, very high performance, nothing wrong whatsoever. So this is where we are at at this point in time. Completely bewildered as to what is getting reported here and not knowing what the cause is other than to say that perhaps the OpenGL libraries on your systems has issues. We will test another Chartbook and then we will look at getting similar hardware and driver but we do not know when we would get to that. So at this point, the continued posting of all of these details and issues is largely getting ignored at this point in time. It is just not useful to us or meaningful. We have to go about our other development rather than getting caught up in all of this stuff which is not reproducible and makes no sense to us. So we are not going to be responding further here. And there is no point in posting further about these issues. We have more than enough information, and we will see what more we can discover, there will be some further efforts, but if we come up with nothing, then OpenGL is just not going to work for you. Very sad situation, but we are not noticing any trouble whatsoever. Absolutely nothing, everything is working perfect when using OpenGL using your Chartbooks. And we are not using any custom studies either. We are running in 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-06-18 23:26:07
|
| [2020-06-19 00:21:48] |
| nosast - Posts: 290 |
|
On which systems did you test and on which GPU? Do you suggest one particular GPU that works perfect? I may just get this model than. I use latest Win 10, Nvidia Quadro P600 with latest nvidia drivers and have really no issues with other OpenGL applications like Bookmap. Also I will try to reproduce crashes in safe mode to check if a custom study is causing this. @ Other guys having these issue: I suppose we are not all using the same custom studies so there might be a problem with Windows 10 edition, compatibility to nvdida GPU or GPU driverset? |
| [2020-06-19 06:33:37] |
| samual sprat - Posts: 343 |
|
Windows 10 with Nvidia 1070 and latest Nvidia drivers Here Sierra. Seems the issue is with custom studies? Surely you would need to test with custom studies then. You cannot simply say it’s the fault of the devs making the custom study as they are simply using your libraries in most cases and are competent coders Ignoring this just means that any further custom studies made could be causes of even more issues And further instability. Maybe the devs in this thread can test and share some of their code that is basic but causes these exceptions? |
| [2020-06-19 07:39:16] |
| nosast - Posts: 290 |
|
@sunnyd I will test every and drill down as good as I can over the next couple of days. Strange thing is, if I do nothing and just let it run it's stable. When I prepare for the day I often put the chart to fullscreen, duplicate and move lines and zones (transparency), zoom in and out. These drawings are linked into other charts with different update intervals. Once I have a chartbook without custom studies where I can reproduce crashes I will share it here for broad testing. Seems to me this is not related to a custom study but rather to an issue with chart drawings. Also tried to go back to GDI last night but it is just way too laggy for me. Tried to quickly move trade lines in SIM on a depth chart with an update interval of 250ms just not doable while trading. |
| [2020-06-19 07:51:20] |
| samual sprat - Posts: 343 |
|
@nosast thanks bud, very much appreciated I too use a lot of drawing tools, lines, channels, transparent rectangles and also copy drawings across charts. Zooming often seems to cause crashes, but only when I first open the chartbook. Like you if I leave it alone for a min or two it will be stable for days I mainly get issues after updating to a new version of SC, after which to get it stable I find copying charts in safe mode to a new chartbook fixes most crashing issues. Seems we need to get a list of things that cause issues for people and compile it somewhere so we can find patterns |
To post a message in this thread, you need to log in with your Sierra Chart account: