OpenCPN Beta Version 3.3.1931 Released

[nohal]

Dave...
Just got a crash while building the texture cache somewhere along the east coast of US.

*** opencpn (wxWidgets 2.8.12) crashed ***, see backtrace!
0x73745d in wxCrashPrint::Report() at ??:?
0x5107cc in MyApp::OnFatalException() at ??:?
0x7f5399adc9fc in wxFatalSignalHandler at ??:0
0x7f5397265880 in  at ??:0
0x7f53979e9870 in __dynamic_cast at ??:0
0x74712b in GetLevel0Map(glTextureDescriptor*, wxRect const&, ChartBase*) at ??:?
0x7473b0 in GetFullMap(glTextureDescriptor*, wxRect const&, ChartBase*, int) at ??:?
0x74858d in CompressionWorkerPool::DoJob(JobTicket*) at ??:?
0x748365 in CompressionWorkerPool::ScheduleJob(glTexFactory*, wxRect const&, int, bool, bool) at ??:?
0x7492eb in glTexFactory::DoImmediateFullCompress(wxRect const&) at ??:?
0x73a41e in CompressChart(wxThread*, ChartBase*, wxString, wxString, wxEvtHandler*, wxString const&, int, int) at ??:?
0x746225 in CompressedCacheWorkerThread::Entry() at ??:?
0x7f5399ad8983 in wxThreadInternal::PthreadStart(wxThread*) at ??:0
0x7f539725e062 in  at ??:0
0x7f5396f92a3d in clone at ??:0
Aborted

Sorry, don't have more info at hand - will debug it if it repeats...

Pavel

[Hakan]

Originally Posted by bdbcat

Hakan...

I looked at your crash dump.
Did you build 3.3.1931 from source for this test? If so, I cannot use the dump file. The .pdb debugging information does not match up with my locallly saved information.

Will you try again with the as-released 3.3.1931 binary?

Thanks
Dave

Dave..
Now I've the same scenario using the official beta binary and got a couple of similar crashes. I couldn't catch the first since the PC was completely hanged. From the second there's a crash report on this link: https://dl.dropboxusercontent.com/u/...fa2c05eeeb.zip
The environment is the same as before:
W7 32,
3.3.1911 as the main OCPN where all NMEA are connected and further broadcast to portable by UDP.
3.3.1931 as portable, switch -p, beside the main installed in it's own directory. It was installed to a clean directory but after installation I copied my old opencpn.ini and navobj.xml to the same dir. The charts are read from the same place as for the main OCPN.
(Also for the main OCPN a crash once occurred when using 3.3.1931 but that was my own variant so I went back to my own 1911)
A screenshot is attached
Håkan

[Rasbats]

Hello Dave.

Using OpenGL the same picture break up happens.

Tried a few different settings from the Options panel but with no better result.

Mike

[bdbcat]

Rasbats...

Wow, not good. I need to get my hands on one of these chart sticks.

For fun, will you please try some NOAA raster charts on your machine, in OpenGL mode? Just to try and show this error is chart-specific, you understand. And to get some idea of performance on your hardware.

Thanks
Dave

[yachtman]

Hi

I am using a visit my harbour chart stick only get the crashed image with open GL off.

never tried gl off before as visit my h recommend the use of GL

With open GL on no problem or slowness. havnt got a nmea stream though to test with as am at home.

sony i7 ram 8gb

ps

Just been looking at the same area of the humber and estuary.

No problems with GL, on my lap top

[Rasbats]

Dave ...

With NOAA raster charts I get the same aberrations with both OpenGL ON and OFF.

My copy of 3.3.1931 is from the O downloads page.

Mike

[Rasbats]

Dave,

Interesting.

I rebuilt the chart database with only the NOAA charts and bits of the VMH UK charts appear in the panel.

Mike

[cagney]

Originally Posted by Rasbats

Dave,

Interesting.

I rebuilt the chart database with only the NOAA charts and bits of the VMH UK charts appear in the panel.

Mike

Dave

Looking at Mikes screen dumps I had a deja vu - flashback, to this old thread http://www.cruisersforum.com/forums/...tml#post834226

Chart cache-handling-regression?

Thomas

[bdbcat]

Rasbats....

OK, thanks for the tests.
Two separate problems here.

1. No-OpenGL. Well understood problem, introduced by 3.3.1931.

2. OpenGL patch scrambling: I see a way that this could be happening, although I have never seen it before in testing. Definitely related to cagney's comment regarding cache coherency, seen earlier. I will have a tentative solution in the next Beta.

Sorry for the trouble today.
Dave

[pkrawetzky]

Version 3.3.1931
Windows XP
Panasonic Toughbook CF-29

Used the latest beta version going from Mystic, CT to Block Island. Several issues with screen refresh and distorted charts showing up. I zoom out and then which seems to be resolve the problem. If I move the cursor around and drag the map thats when the distortion happens. It sounds like it might be a know problem.

[bdbcat]

Hakan...

OK, thanks to your crash dump report I have discovered the root cause of the problem you report.

We had a leak in GDIObjects, specifically Windows Regions. Windows has a hard limit of 10,000 GDI Objects per process, and fails ungracefully when the limit is reached.

We leaked about 1 Object per second, when an active GPS was showing ownship on the screen. Works out to about 3 hours, give or take.

This leak may explain many of our "un-explained" crashes. I know it explains some of the Windows crash reports I have analyzed recently.

For the devs, a nice tool to look at this kind of problem is GDIView.exe, from Nirsoft. Freeware.

GDIView - View GDI handles/resources list and detect GDI leaks

New OCPN code in github master now.

Thanks
Dave

[Ptizef]

Hi Dave

Tested 3.3.1931 rasters low pow W8.1

Originally Posted by bdbcat

Have you tried dense quilted raster charts with 3.3.1931 with texture compression ON and caching OFF on your low end machine? This is the worst case in performance, theoretically. Especially for a single core CPU.
Dave

I tested all configurations
Compression OFF, caching OFF
Compression ON, caching OFF
Compression ON, caching ON but no cache pre-built

In all these cases , with very minor differences, I got the same result
Slowness and frequent hangs
When panning/zooming a bit quickly, it take less than a minute to get O hanging for several ten seconds
Also I got "real" crashes with the last config. Two crash reports have been sent this night
Only after a complete cache rebuilt, things are OK. Not extremely fast but correct

Originally Posted by bdbcat

It might be useful for testing to activate the Windows Task Manager, and monitor the CPU load while you are zooming and panning. If it goes very high for long periods of stall, that would be interesting to know.
Dave

I did it
When panning/zooming, the CPU load from O goes up to around 50-55%
Curiously, when hanging, the CPU load tend to go down to about 20% even less
Another element is the memory usage
with CM93 it never overcomes 100 MO
when I start raster in a zone without map, also the memory usage is far less than 100 MO. But when rasters are displayed, it grows up to 600 MO even 700 MO around a hang ( 70% !)
And after having displayed rasters, this parameter never goes down. Even if I pan to a zone without map, or switch to CM93, it stay at 500-600 MO

Jean Pierre

[Gilletarom]

Hello Dave,

Originally Posted by bdbcat

....
We had a leak in GDIObjects, specifically Windows Regions. Windows has a hard limit of 10,000 GDI Objects per process, and fails ungracefully when the limit is reached.

We leaked about 1 Object per second, when an active GPS was showing ownship on the screen. Works out to about 3 hours, give or take.

This leak may explain many of our "un-explained" crashes. I know it explains some of the Windows crash reports I have analyzed recently.
.......
Dave

Dave, if I had no trouble with my internet connection, I have reported yesterday that the problems we had with the 322 version of this summer.

We sailed in the Channel, an area where many, many circulating cargo, tankers etc. ... but increasingly also sailboats with an AIS transmitter. Besides all tags that have an AIS transmitter on the coasts. This makes a huge amount of AIS messages are received and qur O must deal.

During the return to France, between the Isle of Wight and Cherbourg, whenever O has stopped working (3 times), I struggled to revive O. AIS targets were not displayed briefly . It was a long wait. Too long we have the patience to wait.
Twice I stopped and restarted the PC completely PC. The third time, I was content to use the PolarWiew software, which always runs in parallel with O in spare wheel, never stop working. But Polarwiew only receives NMEA sentences from a GPS backup (ND100 GlobalSat)

In addition, this summer, twice the power of 12V PC has been idle without me noticing. Each time, when the battery in my PC was too low, O stopped working. I suspected VHF that transmits NMEA sentences from the GPS and AIS sentences to be the cause of the blockage. I guess O was unable to process all sentences correctly because those he received was poor.

I hoped to solve this problem by reducing the number of AIS targets visible. I limited distance, acceptable targets, less than 10 miles, but it seems to have been ineffective.

Best regards

Gilletarom.

[bcn]

Dave...

Further testing with the Australian S63 set (W7, No OpenGL).

Panning will encrease allocated memory starting from 60MB and OpenCPN will get slower and slower. Memory now > 650MB (2GB RAM total).
And as now Firefox is up as well free memory goes close to zero.

Hubert

[CarCode]

The latest commit of wxWidgets 3.1.0 shows:

Commit: 3c7ba391352d3a8d781df7d83738d4ca4616b8a6 [3c7ba39]
Parents: e58975a7e4
Author: Vadim Zeitlin <vadim@wxwidgets.org>
Date: 7. August 2014 01:31:41 MESZ
Labels: HEAD origin/master origin/HEAD master
Subversion Revision: 77018

Allow requesting core OpenGL profile and explicit OpenGL version.

Add WX_GL_CORE_PROFILE and WX_GL_{MAJOR,MINOR}_VERSION attributes which can be
used to use modern OpenGL with wxGLCanvas.
Closes #16402.

Does this help to solve the desaster introduced by the so called "optimizations"?
As Hubert already wrote there might be 80% Windows, 10% Mac and 10% Linux users, which is my assumption as well. I don't understand how a single person is able to spoil the code of OCPN with his "optimizations" for a Raspberry Pi.

Gerhard