RADAR and Chart window freezes

[NAHANNIV]

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.

[keesverruijt]

Can you repeat your test with the v1.3 official release instead of the shader test version?

[NAHANNIV]

I cloned: 14e580c last night, Only one commit since then.

[NAHANNIV]

OK, I went back to: b8a2cf4.
Testing now.

[NAHANNIV]

b8a2cf4 seems to be OK.

I also saw the freezing behaviour in test versions prior to V1.3.
Was there a particular fix that got overwritten ?

[keesverruijt]

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:

• Disable the shader (either via UI or direct ini file edit).
• STOP OpenCPN
• Start it again

Then see if it hangs. If you start the process with the shader switched off, and keep it switched off, does this help?

[NAHANNIV]

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.

[NAHANNIV]

V1.3 was fine through a 4H test.

[NAHANNIV]

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.

[NAHANNIV]

This still seems to be a problem in 1.31.
It seems to freeze faster on slower machines.
Setting the REFRESH rate higher also seems to make it freeze faster.
I am testing with the test2w.pcapng capture file.
Tested Ubuntu 14.04.3 LTS on ARM and X86

[keesverruijt]

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.

[NAHANNIV]

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.
Cheers,
JM.

[keesverruijt]

Crashes are bad. Can you compile with a debug release and then analyze the core dumps for me?
e.g. ulimit -c unlimited and once you get the core file run gdb .../opencpn .../core then backtrace and then provide the backtrace here.

[NAHANNIV]

Not sure if you wanted me to post that here ?

Here is the crash when "x"ing the window while RADAR is active:
`ubuntu@tegra-ubuntu:$ gdb opencpn
GNU gdb (Ubuntu 7.7.1-0ubuntu514.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from opencpn...done.
(gdb) run
Starting program: /usr/local/bin/opencpn
Traceback (most recent call last):
File "/usr/share/gdb/auto-load/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.19-gdb.py", line 63, in
from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb3747240 (LWP 2245)]
[New Thread 0xb2dff240 (LWP 2246)]
[New Thread 0xb2153240 (LWP 2263)]
[New Thread 0xb1953240 (LWP 2264)]
[New Thread 0xb1153240 (LWP 2265)]
[Thread 0xb1953240 (LWP 2264) exited]
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
[New Thread 0xb1953240 (LWP 2300)]
[Thread 0xb1953240 (LWP 2300) exited]
[New Thread 0xb1953240 (LWP 2301)]
[Thread 0xb1953240 (LWP 2301) exited]
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
ALSA lib pcm_dmix.c:961:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
[New Thread 0xb1953240 (LWP 2302)]
[Thread 0xb1953240 (LWP 2302) exited]
[New Thread 0xb1953240 (LWP 2303)]
[Thread 0xb1953240 (LWP 2303) exited]
[New Thread 0xb1953240 (LWP 2304)]
[Thread 0xb1953240 (LWP 2304) exited]
[Thread 0xb1153240 (LWP 2265) exited]

(opencpn:2242): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'width >= -1' failed
[New Thread 0xae011240 (LWP 2314)]

(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.
[Switching to Thread 0xae011240 (LWP 2314)]
0xaf6b1a34 in br24::RadarInfo::ProcessRadarSpoke(int, int, unsigned char_, unsigned int, int, wxLongLongNative) ()
from /usr/local/lib/opencpn/libbr24radar_pi.so
(gdb) bt
#0 0xaf6b1a34 in br24::RadarInfo::ProcessRadarSpoke(int, int, unsigned char_, unsigned int, int, wxLongLongNative) ()
from /usr/local/lib/opencpn/libbr24radar_pi.so
#1 0xaf6a8d6a in br24::br24Receive::ProcessFrame(unsigned char const*, int)
() from /usr/local/lib/opencpn/libbr24radar_pi.so
#2 0xaf6aa494 in br24::br24Receive::Entry() ()
from /usr/local/lib/opencpn/libbr24radar_pi.so
#3 0xb6911d16 in wxThread::CallEntry() ()
from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
#4 0xb6912118 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
`

ON my x86 UBUNTU the same action is not causing a crash, but the display gets corrupted with large blank areas.

[NAHANNIV]

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.

[keesverruijt]

Mulling this over a bit and I can see where this is coming from. Needs an extra mutex. Thanks!

On 13 mrt. 2016, at 14:25, NAHANNIV notifications@github.com wrote:

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.

—
Reply to this email directly or view it on GitHub.

[NAHANNIV]

Fixed in V2