-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RADAR and Chart window freezes #88
Comments
Can you repeat your test with the v1.3 official release instead of the shader test version? |
I cloned: 14e580c last night, Only one commit since then. |
OK, I went back to: b8a2cf4. |
b8a2cf4 seems to be OK. I also saw the freezing behaviour in test versions prior to V1.3. |
I just went over all changes between b8a2cf4 and head, and all significant changes are in shaders only. Can you try again with the latest, in the following way:
Then see if it hangs. If you start the process with the shader switched off, and keep it switched off, does this help? |
I did as you said, and without ever having the shader turned on it still froze; Somewhere between 1-2hours runtime. Just FYI the CPU usage running my test with V1.3 was 75% vs. 45% with the latest.. I'm going to run a longer test with V1.3. Just to be sure. |
V1.3 was fine through a 4H test. |
On my ARM system running the same test the chart window freezes sooner, but it can be recovered by simply clicking on one of the RADAR control buttons; This platform can not load the shader. |
This still seems to be a problem in 1.31. |
Can you test with the radarwindow branch? That has a huge rewrite of the code and it is actually quite stable for me in this regard. |
OK, I tried the radarwindow branch and it did not freeze in the same manner as 1.31. It's really come a long way since I tried it last ! Looks good. Had a few random crashes that I could not re-create. Had a problem trying to run a RADAR overlay without a RADAR window; The overlay would become very slow. Closing the RADAR window with the small 'x' in the upper right hand corner caused problems, crashing on my ARM system and Corruption of the display on X86. Keep up the good work. |
Crashes are bad. Can you compile with a debug release and then analyze the core dumps for me? |
Not sure if you wanted me to post that here ? Here is the crash when "x"ing the window while RADAR is active: (opencpn:2242): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'width >= -1' failed (opencpn:2242): Gtk-CRITICAL **: IA__gtk_window_resize: assertion 'height > 0' failed (opencpn:2242): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17 (opencpn:2242): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17 (opencpn:2242): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17 (opencpn:2242): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17 (opencpn:2242): GLib-CRITICAL **: Source ID 6654 was not found when attempting to remove it (opencpn:2242): GLib-CRITICAL **: Source ID 6850 was not found when attempting to remove it (opencpn:2242): Gdk-CRITICAL **: IA__gdk_draw_layout: assertion 'PANGO_IS_LAYOUT (layout)' failed Program received signal SIGSEGV, Segmentation fault. ON my x86 UBUNTU the same action is not causing a crash, but the display gets corrupted with large blank areas. |
I played with the radarwindow version for a while and it seems that the problems all happen around closing(x or toolbar icon) of the RADAR window while data is being received. |
Mulling this over a bit and I can see where this is coming from. Needs an extra mutex. Thanks!
|
Fixed in V2 |
After running the RADAR for some time the RADAR display and the OpenCPN chart window stop being refreshed.
This happens in both Shader and non shader modes.
The text was updated successfully, but these errors were encountered: