Hi All
 
I don't want to be too critical of new features but all the trouble I have had with the windows compiling has stemmed from the changes made to the display of clouds with the perlin noise additions. Compiling in linux and Mac does not appear to have any problems so it is some way that the windows compiler (minGW) handles the code.
 
This change added some upgraded textures which cause no problems but added synthesised clouds to some of the solar sytem objects. This display is quite unreal with synthetic clouds moving at speeds in the thousands of miles per hour and personnally I think it looks awful. However it is easily inhibited by editing the ssystem.ini file to display in the older manner.
 
There were changes to many of the core source files and I suspect that the trouble lies in one of these.
 
There have now been 28 commits to the main branch since the trouble appeared and these should not have been made til the problem was rectified.
 
Barry


Barry Gerdes
Beaumont Hills Observatory
S 33' 41' 44"    E 150' 56' 32"

 



From: barrygastro@hotmail.com
To: stellarium-pubdevel@lists.sourceforge.net
Date: Thu, 19 Apr 2012 05:34:34 +1000
Subject: Re: [Stellarium-pubdevel] Windows crash with Qt 4.8.*: thread safety

Hi Bogdan
 
I have not applied a patch for over four years and can't remember the procedure. I tried what i thought was the method but it did not work and I can't find the information on applying a patch
 
Barry Gerdes
Beaumont Hills Observatory
S 33' 41' 44"    E 150' 56' 32"

 
Date: Wed, 18 Apr 2012 16:31:29 +0300
From: daggerstab@gmail.com
To: stellarium-pubdevel@lists.sourceforge.net
Subject: [Stellarium-pubdevel] Windows crash with Qt 4.8.*: thread safety

Hello to all.

It seems that the current crash on Windows when Stellarium is compiled
in Release mode with Qt 4.8.* is caused by some kind of thread safety
issue. Stellarium doesn't crash when it's compiled in Debug mode
because it activates a mutex mechanism normally hidden in an #ifndef.
The mutex ensures that only one copy of StelPainter is active at the
time due to some limitation of OpenGL. The attached patch solves the
crash by enabling the mutex in release mode, but it would be better if
we can find the root reason.

The crash is reproducible when Stellarium is built in "release mode
with debug symbols", which allows debugging (see lines 27 and 299-302
in the main CMakeLists.txt). Stack trace from a crash run:
0 ZN7QObjectD2Ev C:\QtSDK\Desktop\Qt\4.8.1\mingw\bin\QtCore4.dll 0 0x6e1de8e0
1 StelTexture::~StelTexture StelTexture.cpp 148 0xfa6773
2 deref qsharedpointer_impl.h 342 0xfd474c
3 deref qsharedpointer_impl.h 336 0xfd474c
4 ~ExternalRefCount qsharedpointer_impl.h 401 0xfd474c
5 ~QSharedPointer qsharedpointer_impl.h 467 0xfd474c
6 StelLoadingBar::~StelLoadingBar StelLoadingBar.cpp 50 0xfd474c
7 StelApp::init StelApp.cpp 330 0xf83fe8
8 StelAppGraphicsWidget::init StelAppGraphicsWidget.cpp 58 0xf94e9e
9 StelMainGraphicsView::init StelMainGraphicsView.cpp 254 0x108c703
10 StelMainWindow::init StelMainWindow.cpp 107 0x108ede2
11 _fu3___ZN11StelFileMgr13fileLocationsE main.cpp 341 0x403790

It crashes with a segmentation fault in the destructor of
StelLoadingBar/StelTexture. Sometimes the crash occurs only when I'm
running the build with the debugger, depending on what else I'm
running, which is another indicator of a thread safety issue.

Note that in all cases, the splash image is not displayed, even though
things are loading in the background (my disk activity indicator is
flashing, etc.)

Anyway, I really don't have any more time for this now. I will
probably have more time next week. I can probably test proposed
changes to the code in the meantime, and it makes more sense to send
them as patches instead of committing to the repository.

Regards,
Bogdan Marinov

------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________ Stellarium-pubdevel mailing list Stellarium-pubdevel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel

------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________ Stellarium-pubdevel mailing list Stellarium-pubdevel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel