stars8 catalogue is not loaded in 0.10.4 and lower (for me)

Could you please download the test build from here:
https://launchpad.net/stellarium/+download

And report if the problem is still present in it?

This is Stellarium 0.10.5 (SVN r6110)

Log:
...
"Loading "C:\Users\Denri\AppData\Roaming\Stellarium/stars/default/stars_7_2v0_0.cat": 7_2v0_0; 57826266"
Found file "C:\Users\Denri\AppData\Roaming\Stellarium/stars/default/stars_8_2v0_0.cat" , checking md5sum..
Error: Unable to checksum file "stars/default/stars_8_2v0_0.cat"
Finished loading star catalogue data, max_geodesic_level: 7
...

This is Stellarium 0.10.5 (SVN r6177)

Log:

...
Found file "C:\Users\Denri\AppData\Roaming\Stellarium/stars/default/stars_7_2v0_0.cat" , checking md5sum..
MD5 sum correct!
"Loading "C:\Users\Denri\AppData\Roaming\Stellarium/stars/default/stars_7_2v0_0.cat": 7_2v0_0; 57826266"
Found file "C:\Users\Denri\AppData\Roaming\Stellarium/stars/default/stars_8_2v0_0.cat" , checking md5sum..
Error: Unable to checksum file "stars/default/stars_8_2v0_0.cat"
Finished loading star catalogue data, max_geodesic_level: 7

OK, this must be because mmap apparently doesn't manage to map the large file. In this case we should fallback to the previous (slower) method. I'll do that now.

Denri, could you please try again with rev 6183?

Fabien Chéreau, yes, i can.

But https://launchpad.net/stellarium/+download doesn't provide a link to rev 6183.

Wait...

Reverting to the previous method only returns us to the situation in the original post. From both my log (revision 6183) and the log in the bug description:

ERROR: SpecialZoneArray( 8 )::SpecialZoneArray: QFile( "D:/StellariumUserData/stars/default/stars_8_2v0_0.cat" .map( 5242912 , 701538504 ) failed: "Not enough storage is available to process this command."

Note that QFile::map() fails at exactly the same place.

I think that the reason is insufficient memory. Which is strange, because on my computer this happens only in Windows, not in Ubuntu - I can load all catalogs there. Linux has better memory management? :) The compiler adds less bloat?

Which windows? I think XP had a 2 gig address limit or something.

I see. Then I guess I can just revert my hack..

Windows XP.

Fabien, don't revert it - it still fixes the problem with the checksum.

I'm going to upload a new test build (revision 6183).

SVN r6184

Log:
...
Found file "C:\Users\Denri\AppData\Roaming\Stellarium/stars/default/stars_8_2v0_0.cat" , checking md5sum..
MD5 sum correct!
ERROR: SpecialZoneArray( 8 )::SpecialZoneArray: QFile( "C:/Users/Denri/AppData/Roaming/Stellarium/stars/default/stars_8_2v0_0.cat" .map( 5242912 , 701538504 ) failed: "Not enough storage is available to process this command."
"Loading "C:\Users\Denri\AppData\Roaming\Stellarium/stars/default/stars_8_2v0_0.cat": 8_2v0_0; - initialization failed"
Finished loading star catalogue data, max_geodesic_level: 7
...

Oh yes indeed Bogdan, so I let it like that. I guess we cannot do more for this bug since it's a hardware/OS problem.
Fab

It is not a hardware/OS problem.

XP 32bit has limit for memory up to 2 GB.

But i have Se7en 64bit, and NO limit for memory up to 2 GB.

This problem was with 8GB memory on Se7en 64bit, now i have 3.3GB memory on Se7en 64bit with the same problem.

I guess you can do more for this bug since it's a problem with the checksum.

***This is Stellarium 0.10.5 (SVN r6110)
***Found file "C:\Users\Denri\AppData\Roaming\Stellarium/stars/default/stars_8_2v0_0.cat" , checking md5sum..
***Error: Unable to checksum file "stars/default/stars_8_2v0_0.cat"
*******
***This is Stellarium 0.10.5 (SVN r6177)
***Found file "C:\Users\Denri\AppData\Roaming\Stellarium/stars/default/stars_8_2v0_0.cat" , checking md5sum..
***Error: Unable to checksum file "stars/default/stars_8_2v0_0.cat"

The checksum problem has been fixed by Fabien and the fix hasn't been reverted. If you look at the log in your original report and in comment #11, you will notice this:

ERROR: SpecialZoneArray( 8 )::SpecialZoneArray: QFile( "..." .map( 5242912 , 701538504 ) failed: "Not enough storage is available to process this command."

I think it's a problem in the Windows implementation of Qt's file engine, something under the map() function - cache size or something else. It appears that "Not enough storage is available to process this command." is a Windows native error message.

Barry Gerdes mentioned that after some of the previous changes, he was able to load catalog 8 together with 7.

I do not know what to say...

0.10.5 will be able or not to load this 8 catalog?

Answer me, please...

I don't know. Right at the moment, there is no fix that addresses the problem that occurs on both my and your system. If this remains so, then - no.

Maybe your file is corrupted? What md5 checksum do you get for the file? It should be:

b804136f5c5584e9508f21a1f7aa1a28 stars_8_2v0_0.cat

Matthew

Matthew, please read again the log in comment #11. The MD5 checksum is performed OK. What fails is the QFile::map() operation in SpecialZoneArray.

my bad

After a user mentioned that number 8 has worked for him in 0.10.2, I decided to have a look at the changes that have been made since then.
https://answers.launchpad.net/stellarium/+question/108429

As there seems to be a problem with QFile::map(), I tried to build a version where ZoneArray::create is called with use_mmap=false for catalog #8. (See line 347 in StarMgr.cpp.)

Unfortunately, it can't run - while loading catalog #8, Stellarium crashes with a segmentation fault in StelPainter (!). Some debugging later I found out that the crash is caused by line 327 in ZoneArray.cpp:

zones = new SpecialZoneData<Star>[nr_of_zones];

I don't know what relation this has to StelPainter, I guess some kind of memory overflow.

Does anyone has any ideas?

(All of this happens on Windows XP SP3.)

It's strange, normally is the allocation fails it should exit, not crash in another place.... you could have a try with valgrind if it exists on win32.
Fab

Correction to the previous comment - It's actually line 404 in ZoneArray.cpp:

stars = new Star[nr_of_stars];

Fabien, according to the GCC documentation, if the "new" operator fails, it throws a std::bad_alloc exception, but this is not captured anywhere in the code.

Ah OK it makes much more sense here indeed. Did you try to add a catch there? It's probably going to solve the problem.
Thanks,
Fabien

Yes, I've confirmed with a try/catch that it throws a std::bad_alloc. I will re-write the code to make it fail gracefully, like it does in the QFile::map case - now it just exits.

But this doesn't solve the mystery why I can load all catalogues on Linux, but not on Windows.

I've tracked the QFile::map() problem to the QFSFileEnginePrivate::map() method in qfsfileengine_win.cpp (line 1916+).

It seems that this is a problem either with Qt's or Windows' implementation of file mapping.
http://msdn.microsoft.com/en-us/library/aa366537.aspx
http://msdn.microsoft.com/en-us/library/aa366761.aspx

It seems that on Linux, the file is mapped to the virtual memory, but on Windows this fails for some reason.

I still continue to have the problem of being able to load the last catalog due to lack of memory on a 2gb system, but it loads just fine on my 1gb system. And both are xp-sp3 now. So this isn't an OS problem.