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: [email protected]
To: [email protected]
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: [email protected]
To: [email protected]
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 [email protected]
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 [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
