OpenCPN Beta test 4.1.602 Release

[NahanniV]

Now I have a problem forcing texture cache rebuild:

/home/aruntu/OpenCPN/src/glTexCache.cpp(208): assert "dim*dim == 2*size" failed in CompressDataETC(). [in thread b0daf270]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0xb05af270 (LWP 9905)]
__libc_do_syscall ()
    at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
44    ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
(gdb) bt
#0  __libc_do_syscall ()
    at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
#1  0xb643465a in raise (sig=5)
    at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#2  0xb6e6c59c in wxDefaultAssertHandler(wxString const&, int, wxString const&, wxString const&, wxString const&) () from /usr/local/lib/libwx_baseu-3.0.so.0
#3  0xb6e6a1cc in wxOnAssert(char const*, int, char const*, char const*, char const*) () from /usr/local/lib/libwx_baseu-3.0.so.0
#4  0x003708ba in CompressDataETC (
    data=0xaf4079b8 "\325\324\324\332\332\331\342\335\323\355\351\343\035", 
    dim=2, size=8, tex_data=0xaf401df0 "H")
    at /home/aruntu/OpenCPN/src/glTexCache.cpp:208
#5  0x00370df6 in DoCompress (pticket=0xaf406b20, ptd=0xaf407cc0, level=8)
    at /home/aruntu/OpenCPN/src/glTexCache.cpp:353
#6  0x00371c0e in CompressionWorkerPool::DoJob (this=0x13a25c8, 
    pticket=0xaf406b20) at /home/aruntu/OpenCPN/src/glTexCache.cpp:858
#7  0x00371a70 in CompressionWorkerPool::ScheduleJob (this=0x13a25c8, 
    client=0xaf4079f0, rect=..., level=8, b_throttle_thread=false, 
    b_immediate=true, b_postZip=false)
    at /home/aruntu/OpenCPN/src/glTexCache.cpp:800
#8  0x003728a4 in glTexFactory::DoImmediateFullCompress (this=0xaf4079f0, 
    rect=...) at /home/aruntu/OpenCPN/src/glTexCache.cpp:1252
#9  0x0035e9da in CompressChart (pThread=0xdca8d0, pchart=0x13b3668, 
    CompressedCacheFilePath=..., filename=..., pMessageTarget=0x73af18, 
    msg=..., thread=1) at /home/aruntu/OpenCPN/src/glChartCanvas.cpp:281
#10 0x0036faec in CompressedCacheWorkerThread::Entry (this=0xdca8d0)
    at /home/aruntu/OpenCPN/src/glChartCanvas.cpp:341
#11 0xb6f53b56 in wxThread::CallEntry() ()
   from /usr/local/lib/libwx_baseu-3.0.so.0
#12 0xb6f53f58 in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/local/lib/libwx_baseu-3.0.so.0
#13 0xb642dfbc in start_thread (arg=0xb05af270) at pthread_create.c:314
#14 0xb63d420c in ?? ()
    at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
#15 0xb63d420c in ?? ()
    at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

[Gilletarom]

Hello Dave,

I am searching a new version of NV-Verlag plugin to test my NV-Verlag chart with O 4.1.602.

Is it exist ?

best regards. Gilletarom

[seandepagnier]

Originally Posted by NahanniV

I added it like this and it fixed the problem:

bool MyApp::OnInit()
{

    wxStopWatch sw;
    
    if( !wxApp::OnInit() ) return false;

+#if defined(__WXGTK__) && defined(ARMHF) && defined(ocpnUSE_GLES)
+    // There is a race condition between cairo which is used for text rendering
+    // by gtk and EGL which without the below code causes a bus error and the
+    // program aborts before startup
+    // this hack forces cairo to load right now by rendering some text
+ //   if( !m_bsetup ){
+        wxBitmap bmp( 10, 10, -1 );
+        wxMemoryDC dc;
+        dc.SelectObject( bmp );
+        dc.DrawText( _T("X"), 0, 0 );
+ //   }
+#endif

I didn't think about the setup flag, but you did the right thing.

So.. yes it works then 100% of the time? I don't really like this turd but I am also not sure of any other way to deal with it.

Should this be added to the master ?

I would say so.

I am also altering glChartCanvass.cpp to disable the stencil buffer every time I get a new version. based on this conversation with Dave:
http://www.cruisersforum.com/forums/...ml#post1797100
That was to fix a problem with displaying certain features of ENCs. Perhaps that could be added by checking for MALI graphics ?

Can you find some specific examples? I would rather use the stencil if it can be used.

Originally Posted by NahanniV

Now I have a problem forcing texture cache rebuild:

/home/aruntu/OpenCPN/src/glTexCache.cpp(208): assert "dim*dim == 2*size" failed in CompressDataETC(). [in thread b0daf270]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0xb05af270 (LWP 9905)]
__libc_do_syscall ()
    at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
44    ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
(gdb) bt
#0  __libc_do_syscall ()
    at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
#1  0xb643465a in raise (sig=5)
    at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#2  0xb6e6c59c in wxDefaultAssertHandler(wxString const&, int, wxString const&, wxString const&, wxString const&) () from /usr/local/lib/libwx_baseu-3.0.so.0
#3  0xb6e6a1cc in wxOnAssert(char const*, int, char const*, char const*, char const*) () from /usr/local/lib/libwx_baseu-3.0.so.0
#4  0x003708ba in CompressDataETC (
    data=0xaf4079b8 "\325\324\324\332\332\331\342\335\323\355\351\343\035", 
    dim=2, size=8, tex_data=0xaf401df0 "H")
    at /home/aruntu/OpenCPN/src/glTexCache.cpp:208
#5  0x00370df6 in DoCompress (pticket=0xaf406b20, ptd=0xaf407cc0, level=8)
    at /home/aruntu/OpenCPN/src/glTexCache.cpp:353
#6  0x00371c0e in CompressionWorkerPool::DoJob (this=0x13a25c8, 
    pticket=0xaf406b20) at /home/aruntu/OpenCPN/src/glTexCache.cpp:858
#7  0x00371a70 in CompressionWorkerPool::ScheduleJob (this=0x13a25c8, 
    client=0xaf4079f0, rect=..., level=8, b_throttle_thread=false, 
    b_immediate=true, b_postZip=false)
    at /home/aruntu/OpenCPN/src/glTexCache.cpp:800
#8  0x003728a4 in glTexFactory::DoImmediateFullCompress (this=0xaf4079f0, 
    rect=...) at /home/aruntu/OpenCPN/src/glTexCache.cpp:1252
#9  0x0035e9da in CompressChart (pThread=0xdca8d0, pchart=0x13b3668, 
    CompressedCacheFilePath=..., filename=..., pMessageTarget=0x73af18, 
    msg=..., thread=1) at /home/aruntu/OpenCPN/src/glChartCanvas.cpp:281
#10 0x0036faec in CompressedCacheWorkerThread::Entry (this=0xdca8d0)
    at /home/aruntu/OpenCPN/src/glChartCanvas.cpp:341
#11 0xb6f53b56 in wxThread::CallEntry() ()
   from /usr/local/lib/libwx_baseu-3.0.so.0
#12 0xb6f53f58 in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/local/lib/libwx_baseu-3.0.so.0
#13 0xb642dfbc in start_thread (arg=0xb05af270) at pthread_create.c:314
#14 0xb63d420c in ?? ()
    at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
#15 0xb63d420c in ?? ()
    at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Can you reproduce it? What did you do? any chance you can bisect to find the offending commit?

Sean

[Baikal]

boat_alexandra, Dave - please tell me how things are going to correct the error display ENC what I wrote above?

[seandepagnier]

Baikal,

I think it's fixed in my projection's branch, at least for opengl. It's course-up quilted ENC correct?

Sean

[Baikal]

Originally Posted by boat_alexandra

Baikal,

I think it's fixed in my projection's branch, at least for opengl. It's course-up quilted ENC correct?

Sean

I can not compile your assembly out compilation errors
you can send me opencpn.exe ready for the test?

[NahanniV]

Originally Posted by boat_alexandra

I didn't think about the setup flag, but you did the right thing.

So.. yes it works then 100% of the time? I don't really like this turd but I am also not sure of any other way to deal with it.

I would say so.

I will test a bit more to be sure it is fixed and not causing any other problems. Is this because of something that was recently introduced in Ubuntu ?

Originally Posted by boat_alexandra

Can you find some specific examples? I would rather use the stencil if it can be used.

Yes, this is a problem we talked about before. Some C-Map/ENC features do not display correctly when using the stencil buffer on CubieTruck.
An example with C-Map charts and "Dredged area" is at: 43 17.9088 N 079 47.7904 W just zoom in and out on the bridge ("Dredged area"); Be sure to have that chart feature enabled.
There are other features that cause similar problems as well: Quality Of Data, Unsurveyed Area, and Shoreline Constructions.
I do not notice a performance hit, and there seem to be a few other platforms with Stencil buffer problems, so I was thinking of adding it based on MALI.

Originally Posted by boat_alexandra

Can you reproduce it? What did you do? any chance you can bisect to find the offending commit?
Sean

I just deleted the texture cache. I will test this further next week, going sailing this weekend.

Cheers,
JM.

[seandepagnier]

Originally Posted by NahanniV

I will test a bit more to be sure it is fixed and not causing any other problems. Is this because of something that was recently introduced in Ubuntu ?

No. Basically it's as it says in the comment. OpenCPN -> gtk -> cairo -> egl and also at the same time glshim is using egl. Now for our purposes, cairo isn't using egl, but it links with it so it will load it. If we are also loading egl with dlopen then somehow it crashes like what you found. I really don't understand it fully, only that if we render some text really early to a memory buffer, it initializes cairo and the program will never crash. If you know of a better solution let me know.

I do not notice a performance hit, and there seem to be a few other platforms with Stencil buffer problems, so I was thinking of adding it based on MALI.

Cheers,
JM.

Maybe a good idea, but also there is probably a workaround to make the stencil buffer work correctly. In any case you will probably only notice a performance hit in obscure cases.

[seandepagnier]

Originally Posted by Baikal

I can not compile your assembly out compilation errors
you can send me opencpn.exe ready for the test?

Maybe you can try again now? I fixed some compile problems. Otherwise please post the errors in the projection thread.

[Ptizef]

hi all
the last git don't compile
I get this compilation error :

ocpndc.cpp
3>..\src\ocpndc.cpp(677): error C2668: 'sqrt' : appel ambigu à une fonction surchargée
3> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\math.h(589): peut être 'long double sqrt(long double)'
3> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\math.h(541): ou 'float sqrt(float)'
3> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\math.h(127): ou 'double sqrt(double)'
3> lors de la tentative de mise en correspondance de la liste des arguments '(wxCoord)'


Thanks for your help
JP

[CarCode]

Something wrong with your compiler?
sqrt() should be normally double sqrt(double).
But the float or the long double version of sqrt() should be sqrtf() or sqrtl().

Gerhard

[Ptizef]

My compiler is vs2010 as it always been (Vs2013 is a nightmare!)
Jp

Sent from my D5803 using Cruisers Sailing Forum mobile app

[CarCode]

So perhaps check the include file math.h for informations.

Gerhard

[Ptizef]

Originally Posted by CarCode

sqrt() should be normally double sqrt(double).
But the float or the long double version of sqrt() should be sqrtf() or sqrtl().

Gerhard

Yes sqrt() could be double or long double or float but not wxCoord !
in the expression in ocpndc.cpp:677
int steps = ceil(sqrt(r));
r is wxCoord type

My workaround is ocpndc.cpp(677):
int steps = ceil(sqrt((double) r));
It compile and works but I don't know if there is negative consequence somewhere
thanks
JP

[bdbcat]

baikal....

I have been unable to reproduce the problem with rotated, quilted, S57 ENC on OpenGL, Windows platform. See attached screenshot.

Do you have any more information that might be useful?

Thanks
Dave