oeSENC 4.0.2 crash on Linux

[jongough]

I have been using the oeSENC charts for Australia since they became available on my Linux machine. They have worked well. I have just upgraded to the new oeSENC to get the latest charts, however, there appears to be a problem on both my Ubuntu based machine (Linux Mint 19) and my Raspberry PI 3B.

If I am zoomed in showing a small area it all works OK. If I zoom out to show a much bigger area the display starts to suffer "grey areas" rather than the chart. At this point opencpn will crash a little while after these areas show. On the Linux machine the following is shown in the journal:

Mar 02 08:07:52 mishka kernel: opencpn[3492]: segfault at 4 ip 00007f27ee7cdc45 sp 00007ffdcf57bf00 error 4 in liboesenc_pi.so[7f27ee705000+19d000]
Mar 02 08:09:17 mishka kernel: opencpn[3850]: segfault at 4 ip 00007f7b5d982c45 sp 00007fff29462bb0 error 4 in liboesenc_pi.so[7f7b5d8ba000+19d000]
Mar 02 08:20:00 mishka kernel: opencpn[5191]: segfault at 4 ip 00007fbe2e670c45 sp 00007ffe9cc65c20 error 4 in liboesenc_pi.so[7fbe2e5a8000+19d000]

This is from three separate crashes but shows that it occurs in the same location within oeSENC. This is on OpenCPN version 5.0.0 .

On the Raspberry PI 3B the same grey areas occur but in the system journal lines showing 'kernel: [drm] Resetting GPU' occur. At this point the PI is essentially locked up and takes 5 or more seconds to respond to any input. OCPN may crash or lock up the PI to make it unusable unless I can zoom in more. The CPU consumption goes from ~10-20% to 1% at this time.

The zoom level, i.e. how far out I can zoom, is considerably less than on the PI than the Ubuntu machine.

Due to the slowdown on the PI and the inability to interact with it I cannot get a screen shot of it happening.

[bdbcat]

Jon...


Did you build locally, or install from PPA?


Dave

[bdbcat]

Jon...
Cannot reproduce immediately. Will you show a screenshot from your PC before zooming out? And tell how many zoom steps are required to produce the crash...


Thanks
Dave

[jongough]

Both environments are from 'Production', I installed them from the official repositories. There are no custom built (my own build) plugins installed. The PI uses OpenPlotter 1.0.2.

[jongough]

This is from the PI. The location is Manly marina, Brisbane on the SE corner of Qld. The first shot is the starting point, then 4 presses of the "-" button is the next shot and 1 press of the "+" button is the last shot. The "Resetting GPU" shows up in the journal once the "grey areas" start to show up. Also the system becomes really unresponsive. The charts are in their own group and currently only the oeSENC charts are being displayed. If I show the CM93 charts instead it all work OK. I have tried both 64M and 128M for the graphics split but it makes no difference. The system is using OpenGL.

[jongough]

I am now trying to recreate it on the Ubuntu machine, but am having difficulty causing the issue. Typical, when doing the checking for the post it happened a few times, now that you want further detail I cannot get it to create the issue. I will keep trying.

[jongough]

Further investigation shows that reducing the detail on the charts alleviates the issue of the GPU resetting. If I set the vector chart detail level to 0 on the display/advanced/weight the system seems to work, whereas at 1 and above causes the problem.

Trying to navigate around Morton bay we need as much detail as possible as it is all shallow, hence normally using a setting of 2 on the PI and 5 on Ubuntu.