OpenCPN Beta test 4.1.1108 Release

[transmitterdan]

Originally Posted by Hakan

Dan
I use to have the VDR slider on ~15-20%, that equals around 700 B/s.
Any other test you imagine I could do?
Thanks
Håkan

Håkan,

I tried today lots of things to duplicate this memory leak issue but not successful. I don't think it is the UDP multiplexer. I ran over 1800 nautical miles via the UDP input. Memory allocated according to Window 10 task manager actually decreased from start to finish. At one point it was 198MB but now it is 80MB after about 12 hours. I will keep watching for several more hours.

I also ran NMEA data in through the TCP input and it did not show any evidence of a memory leak either.

I could imagine there is some issue with the OpenGL drivers on your system but that seems unlikely. You could try turning OpenGL off to see if that changes the story. But I cannot explain why I don't see the same memory leak as you have seen.

[Hakan]

Additional info for Windows (UDP?) memory built up issue. (See: http://www.cruisersforum.com/forums/...ml#post1966789)
I have tested some old saved install packages:
Version - Builds up memory
4.0 - No
4.1.0 - No
4.1.915 - Yes
4.1.1108 - Yes
I didn't build new versions in between 4.1.0 and 4.1.915 since I have to change /Buildwin/.. ,and so on.., but I can do that if it helps?

Håkan

[Hakan]

Originally Posted by transmitterdan

Håkan,
.............
I could imagine there is some issue with the OpenGL drivers on your system but that seems unlikely. You could try turning OpenGL off to see if that changes the story. But I cannot explain why I don't see the same memory leak as you have seen.

Dan, good point!
On 4.1.1108 and the same VDR-UDP
OpenGl - on - Memory leak.
OpenGl - off - No memory leak.
Raster/vector charts - no difference.
The previous version tests was all using OpenGl.

So, the UDP relation is probably a bad trace, it's more related a moving boat? The "funny" thing is that the memory leak continues after incoming NMEA is switched off.

Edit: OpenGl:

5:44:44 PM: OpenGL-> Renderer String: Intel(R) HD Graphics 3000
5:44:44 PM: OpenGL-> Version reported:  3.1.0 - Build 9.17.10.4229
5:44:44 PM: OpenGL-> Detected Intel renderer, disabling stencil buffer
5:44:44 PM: OpenGL-> Texture rectangle format: de1
5:44:44 PM: OpenGL-> glGenerateMipmap unavailable
5:44:44 PM: OpenGL-> Detected Windows Intel renderer, disabling Vertexbuffer Objects
5:44:44 PM: OpenGL-> Vertexbuffer Objects unavailable
5:44:44 PM: OpenGL-> Using Framebuffer Objects
5:44:44 PM: OpenGL-> Using FBO Stencil buffer
5:44:44 PM: OpenGL-> Using Depth buffer clipping
5:44:44 PM: OpenGL-> Using s3tc dxt1 compression
5:44:44 PM: OpenGL-> Compressed tile size: 128kb (6:1)
5:44:44 PM: OpenGL-> Minimum cartographic line width:  1.0
5:44:44 PM: OpenGL-> Minimum symbol line width:  1.0

Håkan

[transmitterdan]

Maybe your OpenGL driver is way out of date? I looked here:

https://downloadcenter.intel.com/sea...+graphics+3000

and see that the current version is 15. something.

[seandepagnier]

Originally Posted by Hakan

Additional info for Windows (UDP?) memory built up issue. (See: http://www.cruisersforum.com/forums/...ml#post1966789)
I have tested some old saved install packages:
Version - Builds up memory
4.0 - No
4.1.0 - No
4.1.915 - Yes
4.1.1108 - Yes
I didn't build new versions in between 4.1.0 and 4.1.915 since I have to change /Buildwin/.. ,and so on.., but I can do that if it helps?

Håkan

I think if you could build the versions between and use git-bisect to find which commit caused it would be very helpful. Maybe buggy video drivers, but if we can deal with it in opencpn somehow it would be easiest.

[rooiedirk]

Not sure if I am seeing the same thing, but when checking my mem and resourses I see a steadily increase. Until I stop the AIS from, then usage becomes stable.
Attached a file with "top" readings. At line 126 the AIS was stopped, but GPS and wind/weather input continued. All input using UDP

[CarCode]

There are at least 3 potential memory leaks in jsonval.cpp

Gerhard

[rgleason]

As a newby I am very impressed by the persitence, sleuthing and knowledge.

[Hakan]

Dan..Sean.. Video drivers.
I think I've latest possible drivers on all my PCs. (Dan, I'll check your link but it's usual that Intel drivers not fit directly but I've to take from HP/Lenovo instead.)
I've four different PCs and all has Intel video charts and the OpenGl compression type and memory leak patterns are the same for all.

Sean, your point to find a OCPN solution is fine.
Before I start to rearrange my repository and bisect up could you judge Gerhard's points?
Thanks
Håkan

[transmitterdan]

Originally Posted by CarCode

There are at least 3 potential memory leaks in jsonval.cpp

Gerhard

Gerhard,

I am not an experienced developer like you. Can you explain in more detail how the leak can happen? If I know the sequence of events how it can happen then I would try to find a way to prove it happens or not.

This code was not written for OpenCPN as you know. It is developed many years ago. I could not find any reference on internet search about leaks in this widely used module.

[CarCode]

Originally Posted by transmitterdan

Gerhard,

I am not an experienced developer like you. Can you explain in more detail how the leak can happen? If I know the sequence of events how it can happen then I would try to find a way to prove it happens or not.

This code was not written for OpenCPN as you know. It is developed many years ago. I could not find any reference on internet search about leaks in this widely used module.

If you use a smart compiler like LLVM you will see a lot of other issues in the OCPN code like dead variables, dereferenced null pointers, garbage or undefined values and so on. Smart compilers makes some assumptions which might happen or not during runtime of the program and warns the developer about them. It is up to the developer to strengthen the code because such issues are often gateways for hackers for taking over the machine. Well known example of such code is the Flash Player which has every time such holes.

Gerhard

[seandepagnier]

Originally Posted by Hakan

Dan..Sean.. Video drivers.
I think I've latest possible drivers on all my PCs. (Dan, I'll check your link but it's usual that Intel drivers not fit directly but I've to take from HP/Lenovo instead.)
I've four different PCs and all has Intel video charts and the OpenGl compression type and memory leak patterns are the same for all.

Sean, your point to find a OCPN solution is fine.
Before I start to rearrange my repository and bisect up could you judge Gerhard's points?
Thanks
Håkan

Gerhard's points about json values has nothing to do with rendering with opengl.

Most of the points these automatic code checkers find turn out to be cases which can never actually occur in practice. The checker is not smart enough to understand a wider picture.

[CarCode]

Sadly developers even don't see when they mismatches datatypes. Last example was a declared struct which was referenced in the next file as a class as seen in SweepPlotDialog.h
With a smart compiler this is seen immediately.

Gerhard

[seandepagnier]

Originally Posted by CarCode

Sadly developers even don't see when they mismatches datatypes. Last example was a declared struct which was referenced in the next file as a class as seen in SweepPlotDialog.h
With a smart compiler this is seen immediately.

Gerhard

Please submit a pull request. I don't know what is wrong so I need to know what is right.

Interchanging struct and class in this way technically doesn't matter. For forward declarations such as this it is a synonym. So I think your smart compiler isn't so smart.

[Hakan]

Dan..Sean..
I'll start bisect up from 4.1.0
Håkan