Memory leak in 64-bit version

[Nick Fedoseev]

Stellarium 0.13.1.95 (64bit) becomes very slow after a few hours of work Simple investigation tells us that it eats memory with average rate of ~96Kb/second.

Perhaps the bug is somewhere in Star drawing module, as memory leakage stops after hitting 's' key. Switching off drawing other elements do not affect the bug.

Stellarium 0.13.1.95 (32bit) built here does not eat memory.

[Alexander Wolf (alexwolf)]

Are you use prepared packages or build Stellarium from source code?

[Nick Fedoseev (nick-ut2uz)]

32 bit is built here with QT Creator and QT 5.3.1 (mingw482_32)
64 bit is installed from https://launchpad.net/stellarium/trunk/trunk/+download/stellarium-0.13.1.95-win64.exe

[Alexander Wolf (alexwolf)]

Are you build Stellarium from source code in Release mode?

I'm used RelWithDebInfo for all testing packages.

[Nick Fedoseev (nick-ut2uz)]

I built 32bit debug version under QT Creator.
Just verified for RC2 (aka .96):
stellarium-0.13.1.96-win32.exe - no memory leakage
stellarium-0.13.1.96-MESA-win32.exe - can't run, according bug has been reported
stellarium-0.13.1.95-ANGLE-win32.exe - can't run

stellarium-0.13.1.96-win64.exe - leakage exists when many stars are displayed (small FOV of 1 ° or big stars absolute scale )
stellarium-0.13.1.96-ANGLE-win64.exe - can't run

[Nick Fedoseev (nick-ut2uz)]

Two more versions:

stellarium-0.13.1.96-DSS-win32.exe - no memory leakage
stellarium-0.13.1.96-DSS-win64.exe - same leakage as in stellarium-0.13.1.95-win64.exe

[Alexander Wolf (alexwolf)]

Hm, MSVC specific issue?

[Guillaume Chereau (guillaume-chereau)]

This might be Windows specific, I could not reproduce it on my Linux
machine.

[Nick Fedoseev (nick-ut2uz)]

About two years ago I dealt with a similar leakage. That was cured by installing newer drivers. Now I use the latest available. Also checked for the leakage in several OpenGL applications and tests, including heavy ones. No leakage was detected.

Definitely leakage stops with turning stars off (with S key).

I can assist with remote debug if needed.

[gzotti (georg-zotti)]

Sorry, I can confirm growing memory use by about 32kB/s with downloaded 0.13.1.96 (OpenGL) on Win7 with NVidia GTX580M. To reproduce, I first zomed in (1.8° fov in my case). This memory growth is observed also with only default catalogs loaded, and it stops growing if I switch off star display [S]. But after zooming out again with stars displayed I now see it grows even faster, so maybe it has to do with number of stars visible in the viewport? During daylight (no stars visible) nothing bad happens. Memory footprint grew from 92MB at program start to 137MB within just 10 minutes or so, never went smaller.

[gzotti (georg-zotti)]

In Star.hpp there are some typedefs. Maybe win64 has some other int types? Not sure if changing those to using types defined in <qglobal.h> (qint32 etc) would help? There should be at least compiler warnings when building a 64bit version, are there any?

[Nick Fedoseev (nick-ut2uz)]

To build 64 bit version I need MS compiler. I have not tried that before. I worked a lot under 32bit MSVC/2005.
So, after installing MSVC 2013 (express, x64) and according QT 5.4.0, Stellarium x64 was built successfully with QT Creator, the log is attached. There are a few warnings, but looks like they do not point to windows specific problem.

The new exe file works but has the same leakage.

It'a pity, but I can't run valgrind/memcheck as it does not work under windows.
Perhaps somewhere is a MSVC project, where one can use MSVC-specific
#define new DEBUG_NEW
etc ?

[Guillaume Chereau (guillaume-chereau)]

I am right now trying to update my compilation environement on Windows so that I can build the 64bit version (until now I only built the 32bit version). I think there are tools similar to valgrind for Windows, I will see what I can do once I get a build.

[Guillaume Chereau (guillaume-chereau)]

OK, since I am running Windows 7 32 bits, I cannot install Qt 64 bits. I am afraid I won't be able to help much until I find a machine with a 64bit version of Windows.

[gzotti (georg-zotti)]

There is a Valgrind for Windows project on sourceforge, but it's in pre-alpha stage. :-(
Nick, can you please build a win64 version in Release mode (no debug info) and check that for leakage?

[Nick Fedoseev (nick-ut2uz)]

Release build has same leakage.

What about remote debug? I did that a few years ago across ocean. Internet pipes are much better now.

I'm a newcomer for QT+VS environment, so any suggestion is welcome.

[gzotti (georg-zotti)]

I know nothing about remote debugging. Also I would be surprised if you can connect Valgrind to a Stellarium on Windows when Valgrind itself is not available on Windows.

Maybe you can try removing these typedefs in Star.hpp (and change the uses with the respective qint32, quint32 etc)? I think this would be useful anyway to be a bit more Qt-ish. But I would be surprised if that change was really relevant, I assume something bad happens in the Star* classes.

[Nick Fedoseev (nick-ut2uz)]

QT doc says:
Memcheck is supported locally on Linux and Mac OS. You can run it on a remote host from Windows.

Below are results of attempts to locate the leakage.
(1) - Application verifier by MS reports:
=======================================
VERIFIER STOP 0000000000000900: pid 0x1DD8: A heap allocation was leaked.

 0000000011A2ADB0 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
 0000000000333F30 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
 0000000011869FD8 : Address of the owner dll name. Run du <address> to read the dll name.
 000007FEF1510000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.

=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

=======================================
VERIFIER STOP 0000000000000900: pid 0x1DD8: A heap allocation was leaked.

 0000000011A2CFF0 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
 0000000000334040 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
 0000000011869FD8 : Address of the owner dll name. Run du <address> to read the dll name.
 000007FEF1510000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.

=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

=======================================
VERIFIER STOP 0000000000000900: pid 0x1DD8: A heap allocation was leaked.

 0000000011A40FE0 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
 0000000000334BF0 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
 0000000011869FD8 : Address of the owner dll name. Run du <address> to read the dll name.
 000007FEF1510000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.

=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

=======================================
VERIFIER STOP 0000000000000900: pid 0x1DD8: A heap allocation was leaked.

 0000000011A42800 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
 0000000000334D00 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
 0000000011869FD8 : Address of the owner dll name. Run du <address> to read the dll name.
 000007FEF1510000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.

==========================...

[Alexander Wolf (alexwolf)]

I'm switched to use the definitions of types from Qt but it shouldn't solve problem IMHO.

[Nick Fedoseev (nick-ut2uz)]

Types in Windows are identical.

[Nick Fedoseev (nick-ut2uz)]

0.13.97/w64 still has leakage.

It is interesting:
Key S starts/stops leakage in parallel with stars.

But if we disable star drawing by limiting star magnitude to 0, leakage remains fast. After that one can see no visible change at the screen on key S, but leakage still can be turned on/off by that key.

[Guillaume Chereau (guillaume-chereau)]

I just found a memory leak that only appears on Windows (fixed in commit 7308). Can you check if that solves the problem?

[Nick Fedoseev (nick-ut2uz)]

Just built Stellariumx64 (commit 7309).

Great! Leakage has gone.

Thanks.