OpenCPN Beta test 4.1.1108 Release

[Hakan]

Hi..
This wasn't done by itself
I'm down at 4.1.427 commit ac46f43 and still is the memory leak present.
From commit 65c5a58 and older to ver 4.1.0 there are all the time Windows errors so I cant build.
I can't even build 4.1.0 and don't remember how I get that installation package.

Bisect is not possible to use because it's narrowing in by picking old/new commits and the old has all he time build errors.

But still - ver 4.1.0 (? commit) no leak. Commit ac46f43 - leak.

Tired - bed.
Håkan

[rgleason]

Dan,
If a plugin is "Disabled" how can it cause a problem? Can I safely assume a "Disabled" plugin is not affecting the operation of Opencpn? EG: If I "disable" all plugins that are not standard/not being tested, does that limit responsibility?

Rick, ..You have lots of plugins...guessing one of them is responsible.

[rgleason]

Memory Leak

Hakan:

But still - ver 4.1.0 (? commit) no leak. Commit ac46f43 - leak.

Earlier Hakan said he had 4 different Windows 7,8,10 etc machines showing the leak...
He has tracked the change to between version 4.1.0 and ac46f43

Now Dan has run some very long tests without a memory leak. Does this mean UDP is not the problem?

Sean has some ideas.

Hakan you've done so much already, and you're probably sleeping now.., perhaps try TDan's Nmea-Server Pyton Script to play your nmea file. Just to try and change something. Maybe that will suggest something, if you haven't already done this.
Then there are two computers that both ran it the same way Tdan and yours.

Nmea Server using Python Script and Launcher_pi | Official OpenCPN Homepage
His github download for the script is there.

[transmitterdan]

Originally Posted by rgleason

Dan,
If a plugin is "Disabled" how can it cause a problem? Can I safely assume a "Disabled" plugin is not affecting the operation of Opencpn? EG: If I "disable" all plugins that are not standard/not being tested, does that limit responsibility?

It limits the probability of a problem to a fraction of a percent but does not totally eliminate the possibility of problems. If the plugin_pi.dll file exists then O will load it to see if it's a valid plugin (unless it is on the "blacklist"). So some small amount of plugin code gets run each time O starts. If you want to be sure just move the .dll file somewhere where O can't find it. But as Windows get "smarter" it gets harder and harder to do that.

[rgleason]

Hakan, I did a little 1 hour test with Hakefjord nmea, using Tdan's Nema-Server with Launcher to make it easier to repeat when the finished. (It would be nice if there was a command to make it a continuous play.)

Dell Laptop XPS15 L502x, 2011, Win7
Opencpn 4.1.1108 (todays version)
Hakan's Hakefjord.txt nmea file in Sweden
Used Task Manager and Resource Monitor (Had to change theme to Aero Theme)

Time Commit KB Work KB Share KB Private KB MemUsed
6:15 213,392 177,980 20,400 157,592 3.57 gb
7:15 280,976 245,428 20,432 225,012 3.64 gb

On my machine there is no doubt that Opencpn Memory Use is increasing.
I have never measured this before, so I am unable to make an assessment, however I would agree with Hakan that the memory use is constantly increasing. Please see the attached screenshots.

[rgleason]

Hakan, I have squirreled away 4.1.718, 4.1.925 and 4.1.1022 installs. Are any early enough?

[bdbcat]

Hakan/TDan/et al...

New github master available which should correct the cm93 fault on panning at small scale across IDL.

Good Luck
Dave

[seandepagnier]

Originally Posted by transmitterdan

It limits the probability of a problem to a fraction of a percent but does not totally eliminate the possibility of problems. If the plugin_pi.dll file exists then O will load it to see if it's a valid plugin (unless it is on the "blacklist"). So some small amount of plugin code gets run each time O starts. If you want to be sure just move the .dll file somewhere where O can't find it. But as Windows get "smarter" it gets harder and harder to do that.

Disabled plugins get loaded the first time when you navigate to the plugins tab. I did this to greatly improve startup speed on slow machines that have lots of plugins installed. So basically if you want to be sure a plugin isn't causing problems, disable it then restart opencpn.

[seandepagnier]

Originally Posted by rgleason

Hakan, I have squirreled away 4.1.718, 4.1.925 and 4.1.1022 installs. Are any early enough?

Rick,

In that hour, how many times did you have to replay the log file to get 7mb more ram used?

Also, how fast did you replay it?

[Hakan]

Windows memory leak so far a summarize:
Although not being able to trace down to one commit I think the following can be used to narrow it.
I hope "memory leak" is the correct name for when internal memory use is constantly increasing. That's how I will name it here.

I have a leak when:

• OpenGL is on. Not when OpenGL is off
• Use Intel graphic card:
  -Texture rectangle format: de1
  -glGenerateMipmap unavailable
  -disabling Vertexbuffer Objects
  -Vertexbuffer Objects unavailable
  -Framebuffer Objects unavailable
  -Using Depth buffer clipping
  -Using s3tc dxt1 compression
• Boat (or AIS target?) has a moving position. No leak if I move the chart by mouse or arrows before I've a moving boat position.
• Once the leak is initiated it continues even if all NMEA are interrupted.
• The leak is implemented before O version 4.1.427 (ac46f43) and after ver 4.1.0 (commit unknown - can't build)

The leak is NOT caused by:

• UDP massages as such.
  If incoming NMEA stream don't move the boat, e.g. moored, the leak is not initiated.
• Vector nor Raster charts. The leak is present using either or both.
• A plugin. The leak is present even when all plugins are disabled.

Can I collect more info? Please tell.
(Now I realize why I had to restart O every now and then during this summer sails. It hung because of memory built up after every half a day or so.)

Håkan

[transmitterdan]

I am running this version:

commit 28c9200d6869568259d555d4a8928ce0eb76b209
Author: David Register <bdbcat@users.sourceforge.net>
Date:   Mon Nov 23 23:17:07 2015 -0500

    Update Authors list, adding Didier Gautheron.

Here are some facts about my system which does not exhibit the ever growing memory issue:

Windows 10

Lenovo with AMD A8 processor (a relatively poor performing laptop)

OpenGL stats reported in opencpn.log:

11:21:32 PM: OpenGL-> Renderer String: AMD Radeon(TM) R5 Graphics
11:21:32 PM: OpenGL-> Version reported:  4.5.13399 Compatibility Profile Context 15.201.1151.0
11:21:32 PM: OpenGL-> Texture rectangle format: de1
11:21:32 PM: OpenGL-> glGenerateMipmap unavailable
11:21:32 PM: OpenGL-> Using Vertexbuffer Objects
11:21:32 PM: OpenGL-> Using Framebuffer Objects
11:21:32 PM: OpenGL-> Using FBO Stencil buffer
11:21:32 PM: OpenGL-> Using Stencil buffer clipping
11:21:32 PM: OpenGL-> Using Scissor Clipping
11:21:32 PM: OpenGL-> Using s3tc dxt1 compression
11:21:32 PM: OpenGL-> Compressed tile size: 128kb (6:1)
11:21:32 PM: OpenGL-> Minimum cartographic line width:  1.0
11:21:32 PM: OpenGL-> Minimum symbol line width:  1.0
11:21:32 PM: Warning: iCCP: known incorrect sRGB profile

Last night before retiring O was using 202MB of memory. Now about 6 hours later and after having sailed about 1150 virtual miles the memory used is 145MB and stable (by stable I mean the memory goes up and down about 10MB as I navigate various option menus). I was sending NMEA packets on the TCP interface at 1mS intervals thus the ability to sail a long distance (albeit in a mindless loop). I believe Hakan and I are both using the same NMEA data file.

I have OpenGL on, texture compression with caching on, Texture cache = 36.9MB.

My chart file is an old CM93 set.

Now I have slowed down the NMEA packet stream to 25mS per packet. I will see if a slower (albeit nearly real time) playback changes the picture but based on past testing I don't think it will.

[rgleason]

Probably 6 or 7 times. I was running opengl and using Tdan nmea-server python script. The hakefjord.txt file is about 20mb I believe, and I ran it at the Tdan script speed of .033 (the setting tdan has in his first example which i think he sped up). I dont know what baud that is.

I look at the "private memory" increase, Sean, and it is 70 mb not 7mb. No wonder Hakan has to reboot on long runs.

[rgleason]

I was using cm93 old set

[transmitterdan]

Originally Posted by bdbcat

Hakan/TDan/et al...

New github master available which should correct the cm93 fault on panning at small scale across IDL.

Good Luck
Dave

Dave,

The panning bug seems to be exterminated. The panning behavior is different now though. One can scroll around the world whereas before I don't think that worked. The new behavior is better IMO.

I found a nuisance log message regarding TCP connection failure. I will submit a pull request after a day or so of testing this build.

I still have not experienced any evidence of a memory leak.

[Hakan]

Originally Posted by bdbcat

Hakan/TDan/et al...

New github master available which should correct the cm93 fault on panning at small scale across IDL.

Good Luck
Dave

Windows, CM93, (Intel graphic, if relevant), OpenGL is on, when switched off no hangs.

If this issue is connected or not but I can't move the chart, east or west, past 180 degr.
Method to force this issue:

- In attached picture O hangs when I try to move further west. (The same for easterly movements.)
- Set a WP to 16 46.6 S 179 20.1 E and use "center view" in WP manager. Background is all black and O hangs and have to be forced close. Pic 2

Also is it not possible to scale/pan out more than the attached picture. Could be intentional?

Håkan