Cruisers Forum
 


Reply
 
Thread Tools Search this Thread Rate Thread Display Modes
Old 03-08-2012, 02:37   #1
Registered User

Join Date: Jul 2012
Location: UK
Boat: Albin Vega, 27'
Posts: 79
Chart Problems on Raspberry Pi

I am having problems using vector charts (ENC and M93) on armhf on a raspberry pi.

This is a follow-on from an earlier post http://www.cruisersforum.com/forums/...ml#post1000186

I have recompiled against 3.1.802 but the previous symptoms (detailed in the above post) remain, i.e. the app crashes when opening vector charts. The default chart is fine (the new look is great) as is a set of raster charts.

Running opencpn with gdb gives the following after adding a chart directory to a clean installation:


loading ENC charts:

(gdb) run
Starting program: /usr/local/bin/opencpn
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0x002a8eac in s57chart::CreateSENCRecord (this=0xc36c00, pFeature=0x650db0, fpOut=0x672f08,
mode=1, poReader=0xe7d730) at /home/pi/OpenCPN/src/s57chart.cpp:4978
4978 *pdf++ = easting;
(gdb) bt
#0 0x002a8eac in s57chart::CreateSENCRecord (this=0xc36c00, pFeature=0x650db0,
fpOut=0x672f08, mode=1, poReader=0xe7d730) at /home/pi/OpenCPN/src/s57chart.cpp:4978
#1 0x002a57e8 in s57chart::BuildSENCFile (this=0xc36c00, FullPath000=..., SENCFileName=...)
at /home/pi/OpenCPN/src/s57chart.cpp:3998
#2 0x0029fd88 in s57chart::FindOrCreateSenc (this=0xc36c00, name=...)
at /home/pi/OpenCPN/src/s57chart.cpp:2629
#3 0x0029f260 in s57chart::Init (this=0xc36c00, name=..., flags=FULL_INIT)
at /home/pi/OpenCPN/src/s57chart.cpp:2451
#4 0x000fd930 in ChartDB::OpenChartUsingCache (this=0xc793b8, dbindex=16, init_flag=FULL_INIT)
at /home/pi/OpenCPN/src/chartdb.cpp:1019
#5 0x000fca84 in ChartDB::OpenChartFromStack (this=0xc793b8, pStack=0x75a6c0, StackEntry=0,
init_flag=FULL_INIT) at /home/pi/OpenCPN/src/chartdb.cpp:690
#6 0x000fe078 in ChartDB::OpenStackChartConditional (this=0xc793b8, ps=0x75a6c0,
index_start=0, bSearchDir=false, New_Type=CHART_TYPE_DONTCARE,
New_Family_Fallback=CHART_FAMILY_RASTER) at /home/pi/OpenCPN/src/chartdb.cpp:1177
#7 0x000e1858 in MyFrame:oChartUpdate (this=0xd37c80)
at /home/pi/OpenCPN/src/chart1.cpp:5829
#8 0x000d8624 in MyFrame::ClearbFollow (this=0xd37c80) at /home/pi/OpenCPN/src/chart1.cpp:3688
#9 0x000cec94 in MyApp::OnInit (this=0x4313b0) at /home/pi/OpenCPN/src/chart1.cpp:1794
#10 0x000eb498 in wxAppConsole::CallOnInit (this=0x4313b0) at /usr/include/wx-2.8/wx/app.h:76
#11 0x400c3690 in wxEntry(int&, wchar_t**) ()
from /usr/lib/arm-linux-gnueabihf/libwx_baseu-2.8.so.0
#12 0x000cb668 in main (argc=1, argv=0xbefffd24) at /home/pi/OpenCPN/src/chart1.cpp:723
(gdb)


loading CM93 charts:

(gdb) run
Starting program: /usr/local/bin/opencpn
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0x002be840 in cm93chart::CreateS57Obj (this=0x158df20, cell_index=3901020, iobject=1,
subcell=48, pobject=0x17fd018, pDict=0xba3a70, xgeom=0x178dd70, ref_lat=0, ref_lon=0,
scale=3000000) at /home/pi/OpenCPN/src/cm93.cpp:3338
3338 *pAVR = *pf;
(gdb) bt
#0 0x002be840 in cm93chart::CreateS57Obj (this=0x158df20, cell_index=3901020, iobject=1,
subcell=48, pobject=0x17fd018, pDict=0xba3a70, xgeom=0x178dd70, ref_lat=0, ref_lon=0,
scale=3000000) at /home/pi/OpenCPN/src/cm93.cpp:3338
#1 0x002bb29c in cm93chart::CreateObjChain (this=0x158df20, cell_index=3901020, subcell=48)
at /home/pi/OpenCPN/src/cm93.cpp:2331
#2 0x002baa4c in cm93chart::SetVPParms (this=0x158df20, vpt=...)
at /home/pi/OpenCPN/src/cm93.cpp:2160
#3 0x002c38f0 in cm93compchart::PrepareChartScale (this=0x16cd380, vpt=..., cmscale=1)
at /home/pi/OpenCPN/src/cm93.cpp:4840
#4 0x002c7ee0 in cm93compchart::AdjustVP (this=0x16cd380, vp_last=..., vp_proposed=...)
at /home/pi/OpenCPN/src/cm93.cpp:6083
#5 0x0012ed08 in ChartCanvas::SetViewPoint (this=0xcfb200, lat=57.191999473727378,
lon=-2.8123173608082683, scale_ppm=0.0011999999999999999, skew=0, rotation=0,
b_adjust=true) at /home/pi/OpenCPN/src/chcanv.cpp:4782
#6 0x0012e7dc in ChartCanvas::LoadVP (this=0xcfb200, vp=..., b_adjust=true)
at /home/pi/OpenCPN/src/chcanv.cpp:4702
#7 0x0012e650 in ChartCanvas::ReloadVP (this=0xcfb200, b_adjust=true)
at /home/pi/OpenCPN/src/chcanv.cpp:4684
#8 0x000da6d8 in MyFrame::ChartsRefresh (this=0xc12dc8, dbi_hint=-1, vp=..., b_purge=true)
at /home/pi/OpenCPN/src/chart1.cpp:4162
#9 0x000d91cc in MyFrame:oOptionsDialog (this=0xc12dc8)
at /home/pi/OpenCPN/src/chart1.cpp:3884
#10 0x000d6a7c in MyFrame::OnToolLeftClick (this=0xc12dc8, event=...)
at /home/pi/OpenCPN/src/chart1.cpp:3296
#11 0x40095314 in wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-2.8.so.0
#12 0x4010f954 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEn tryBase const&, wxEvtHandler*, wxEvent&) () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-2.8.so.0
#13 0x4010fab4 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) ()
from /usr/lib/arm-linux-gnueabihf/libwx_baseu-2.8.so.0
#14 0x4010fe70 in wxEvtHandler::ProcessEvent(wxEvent&) ()
from /usr/lib/arm-linux-gnueabihf/libwx_baseu-2.8.so.0
#15 0x4010fde8 in wxEvtHandler::ProcessEvent(wxEvent&) ()
from /usr/lib/arm-linux-gnueabihf/libwx_baseu-2.8.so.0
#16 0x403825dc in wxWindowBase::TryParent(wxEvent&) ()
from /usr/lib/arm-linux-gnueabihf/libwx_gtk2u_core-2.8.so.0
#17 0x4010fe04 in wxEvtHandler::ProcessEvent(wxEvent&) ()
from /usr/lib/arm-linux-gnueabihf/libwx_baseu-2.8.so.0
#18 0x4010f894 in wxEvtHandler::ProcessPendingEvents() ()
from /usr/lib/arm-linux-gnueabihf/libwx_baseu-2.8.so.0
#19 0x40095520 in wxAppConsole::ProcessPendingEvents() ()
from /usr/lib/arm-linux-gnueabihf/libwx_baseu-2.8.so.0
#20 0x40318870 in wxAppBase::ProcessIdle() ()
from /usr/lib/arm-linux-gnueabihf/libwx_gtk2u_core-2.8.so.0
#21 0x402973e0 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_gtk2u_core-2.8.so.0
#22 0x402973e0 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_gtk2u_core-2.8.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Alisdair is offline   Reply With Quote
Old 03-08-2012, 03:09   #2
Registered User

Join Date: Dec 2008
Boat: Journeyman
Posts: 705
Re: chart problems on raspberry pi

Do you have any tools at your disposal on the Pi that can help you asses if you are not simply running out of memory? It is quite possible that the code is not very robust in that kind of situation, I am afraid, and charts eat a lot of RAM...
JesperWe is offline   Reply With Quote
Old 03-08-2012, 03:26   #3
Registered User

Join Date: Jul 2012
Location: UK
Boat: Albin Vega, 27'
Posts: 79
Re: chart problems on raspberry pi

Quote:
Originally Posted by JesperWe View Post
Do you have any tools at your disposal on the Pi that can help you asses if you are not simply running out of memory? It is quite possible that the code is not very robust in that kind of situation, I am afraid, and charts eat a lot of RAM...
Just top, and NCacheLimit=1
I also used the smallest ENC package I could find.
I would expect raster charts to use most memory, but they are OK (though slow).
Alisdair is offline   Reply With Quote
Old 10-08-2012, 15:28   #4
Registered User

Join Date: Dec 2008
Boat: Journeyman
Posts: 705
Re: chart problems on raspberry pi

To elaborate a bit, given that there are a few people interested in the subject: The reason vector charts might end up using more ram than raster is that O makes a lot of efforts to cache every possible little rendered piece of graphics it can. Rendering vectors to bitmap is a performance expensive operation, so this caching is one of the main reasons why O is one of the fastest vector chart renderers you'll find out there.

The Pi is RAM starved more than any other device we typically run on, which makes this heavy caching more of a problem than an asset here...

(I never tried a Pi myself so I'm not 100.00% sure that RAM is the issue here, but looking at the back-traces it certainly seems a likely culprit since the crashes happen while building the datastructures)
JesperWe is offline   Reply With Quote
Old 12-08-2012, 15:18   #5
Registered User

Join Date: Jul 2012
Location: UK
Boat: Albin Vega, 27'
Posts: 79
Re: chart problems on raspberry pi

Quote:
Originally Posted by JesperWe View Post
To elaborate a bit, given that there are a few people interested in the subject: The reason vector charts might end up using more ram than raster is that O makes a lot of efforts to cache every possible little rendered piece of graphics it can. Rendering vectors to bitmap is a performance expensive operation, so this caching is one of the main reasons why O is one of the fastest vector chart renderers you'll find out there.

The Pi is RAM starved more than any other device we typically run on, which makes this heavy caching more of a problem than an asset here...

(I never tried a Pi myself so I'm not 100.00% sure that RAM is the issue here, but looking at the back-traces it certainly seems a likely culprit since the crashes happen while building the datastructures)
The charts work fine on the pi under the original Debian, the problen arises when O is compiled for hard float (armhf).
Alisdair is offline   Reply With Quote
Old 12-08-2012, 16:12   #6
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 7,384
Re: Chart Problems on Raspberry Pi

OK, all geeks gather 'round and maybe we can get this one understood.

Consider only the cm93 case, as it is simpler fault.

The code is:
Code:
                 case 'R':
                        pf = ( float * ) aval;
                        pAVR = ( double * ) malloc ( sizeof ( double ) );   //new double;
                        *pAVR = *pf;
                        pattValTmp->valType = OGR_REAL;
                        pattValTmp->value   = pAVR;
                        break;
The fault happens on the line:

*pAVR = *pf;

Now, this is simple stuff. Here with comments

case 'R':
//Get a pointer the the attribute, which is encoded as a 4 byte float.
pf = ( float * ) aval;
// Allocate a double (8 byte) piece of memory
pAVR = ( double * ) malloc ( sizeof ( double ) ); //new double;

// Store the (float) attribute into the (double) storage location
*pAVR = *pf;
pattValTmp->valType = OGR_REAL;
pattValTmp->value = pAVR;
break;

So, the error occurs (maybe) on conversion from (float) to (double),
or on the malloc line.
Definitely sounds like it relates to the "hard float" option.

We might try, for grins, something like:
*pAVR = (double)(*pf);

or change the malloc line to
pAVR = ( double * ) malloc ( 8 );

and recompile, see if the error moves further along.

I don't have access to a hf compatible arm box. I wonder if qemu could be setup for armhf?

Anyway, some ideas. Please hack and report.

Dave
bdbcat is offline   Reply With Quote
Old 12-08-2012, 21:48   #7
Registered User

Join Date: Dec 2008
Boat: Journeyman
Posts: 705
Re: Chart Problems on Raspberry Pi

Quote:
Originally Posted by bdbcat View Post
I wonder if qemu could be setup for armhf?
Looks like it can.

qemu here: Raspberry PI Emulation

For windows there is also Raspberry Pi emulation for Windows | Free software downloads at SourceForge.net

I guess an emulator will likely not reproduce the crash if it is related to assembly code generated by the hard float implementation. But it should make it easy to check the effects of different sized RAM.
JesperWe is offline   Reply With Quote
Old 12-08-2012, 23:06   #8
Registered User

Join Date: Dec 2008
Boat: Journeyman
Posts: 705
Re: Chart Problems on Raspberry Pi

...so I thought I'd give qemu a shot this morning but right now something is not right in the R-Pi debian mirrors, half of the required apk packages got 404 Not Found (like apt-get install git-core for example) so I ran out of energy
JesperWe is offline   Reply With Quote
Old 14-08-2012, 04:44   #9
Registered User

Join Date: Jul 2012
Location: UK
Boat: Albin Vega, 27'
Posts: 79
Re: Chart Problems on Raspberry Pi

Quote:
Originally Posted by bdbcat View Post
We might try, for grins, something like:
*pAVR = (double)(*pf);

or change the malloc line to
pAVR = ( double * ) malloc ( 8 );

and recompile, see if the error moves further along.

I don't have access to a hf compatible arm box. I wonder if qemu could be setup for armhf?

Anyway, some ideas. Please hack and report.

Dave
Unfortunately, neither of those worked.

- The first returned a bus error, similar to before.
- The malloc change just failed

... I'll try again and get back with something more objective
Alisdair is offline   Reply With Quote
Old 14-08-2012, 14:17   #10
Registered User

Join Date: Jul 2012
Location: UK
Boat: Albin Vega, 27'
Posts: 79
Re: Chart Problems on Raspberry Pi

I don't know what happened first time round, but I tried again and it's working!

"*pAVR = (double)(*pf);" failed at that line with a bus error as before.

changing the malloc line as follows, as suggested, works :
"pAVR = ( double * ) malloc ( 8 );"

Thanks!

---

There are a couple of problems remaining that I need to address before I'm happy building a package to share:

- the status bar is hidden underneath the main window, and the only way I can find to pop it in order to swap charts is to push the OpenCPN window using (in this case LXDE) "layer - window on bottom" ... suggestions welcome.
- NOAA ENC files still crash O
- I'm having problems with GPS, but that's still a pi/usb/gpio hardware tussle.

---

If anyone else wants to try it, here's what I did (IIRC):

boot using the latest Pi armhf debian SD image

The pi is overclocked by creating the following /boot/config.txt

arm_freq=850
core_freq=500

(I also have disable_overscan=1 to make it fill my monitor)

I have given it maximum memory split:

cp /boot/arm224_start.elf /boot/start.elf

ensure the system is up-to-date:
apt-get update && apt-get upgrade

git clone openCPN 3.1.802 (per sticky)

changed the one line in cm93.cpp
pAVR = ( double * ) malloc ( sizeof ( double ) );
to
pAVR = ( double * ) malloc ( 8 ); ]

follow standard instructions (apt-get dependencies, mkdir build, cmake, make, make install)

addded NCacheLimit=10 to [Settings] in /root/.opencpn/opencpn.conf

I think that's it ... oh yes, take a copy of the working SD card image

Alisdair
Alisdair is offline   Reply With Quote
Old 14-08-2012, 18:37   #11
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 7,384
Re: Chart Problems on Raspberry Pi

Alisdair....

I'm glad its working, but I'm afraid if

Code:
malloc(sizeof(double));
does not work right on armhf, you will have many other problems with OpenCPN.

This is very mysterious. We need arm help.

Dave
bdbcat is offline   Reply With Quote
Old 30-09-2012, 08:23   #12
Registered User

Join Date: May 2010
Location: Med
Boat: Westerly Renown
Posts: 38
Re: Chart Problems on Raspberry Pi

Hi All. I've compiled 3.0.2 opencpn on the latest wheezy image on my rPi. It compiled without problem and runs - up until I give it the charts! Begins to read CM93 then crashes. I have messed with the mem split and overclock, even tried s-video ( awful picture ) hoping S wouls require less CPU/RAM but all to no avail.
Is there an answer yet please?
Thanks
Stuart
stuartb is offline   Reply With Quote
Old 01-10-2012, 02:36   #13
Registered User

Join Date: May 2010
Location: Med
Boat: Westerly Renown
Posts: 38
Re: Chart Problems on Raspberry Pi

opencpn 3.0.2 on rPi. I cannot find MEMCacheLimit in opencpn.conf. Has something changed or just more of my mistakes?
Cheers
stuartb is offline   Reply With Quote
Old 01-10-2012, 03:03   #14
Registered User

Join Date: Dec 2005
Location: Helsingborg
Boat: Dufour 35
Posts: 3,891
Re: Chart Problems on Raspberry Pi

Quote:
Originally Posted by stuartb View Post
opencpn 3.0.2 on rPi. I cannot find MEMCacheLimit in opencpn.conf. Has something changed or just more of my mistakes?
Cheers
Just add it yourself !
More here Low Power Systems | Official OpenCPN Homepage

Thomas
cagney is offline   Reply With Quote
Old 01-10-2012, 03:07   #15
Registered User

Join Date: Dec 2008
Boat: Journeyman
Posts: 705
Re: Chart Problems on Raspberry Pi

Quote:
Originally Posted by stuartb View Post
opencpn 3.0.2 on rPi. I cannot find MEMCacheLimit in opencpn.conf. Has something changed or just more of my mistakes?
Cheers
Usually it is calculated automatically but if you enter it manually I think O will honor your setting. It should go under "Settings"
JesperWe is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Advertise Here


All times are GMT -7. The time now is 01:20.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2024, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.