From: Bogdan M. <dag...@gm...> - 2012-04-18 13:31:42
Attachments:
mutex_in_release_r5138.diff
|
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 |
From: Barry G. <bar...@ho...> - 2012-04-18 19:34:41
|
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: dag...@gm... To: ste...@li... 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 Ste...@li... https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: Barry G. <bar...@ho...> - 2012-04-18 20:13:48
|
Hi Bogdan I did the patch by hand however the program fails to compile at the linking stage to libstelmain.dll cmakeFiles'stelmain.dir/core/stelpainter.cpp.obj:stelPainter.cpp(.text.0xd6a0):undefined reference to 'stelpainter::globalmutex' This line is repeated 3 times then the compile fails Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" From: bar...@ho... To: ste...@li... 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: dag...@gm... To: ste...@li... 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 Ste...@li... 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 Ste...@li... https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: Barry G. <bar...@ho...> - 2012-04-18 22:25:10
|
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: bar...@ho... To: ste...@li... 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: dag...@gm... To: ste...@li... 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 Ste...@li... 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 Ste...@li... https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: Brady B. <br...@br...> - 2012-04-18 22:27:57
|
Slightly off-topic: has anyone measured the effect of that change on framerate? I thought it's dipped on me on the Android devices (I disabled the rendering as a cheap way to get around the OpenGL issue, but it's still calculating the clouds), but I don't have an FPS counter hooked up. On Wed, Apr 18, 2012 at 3:25 PM, Barry Gerdes <bar...@ho...>wrote: > 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: bar...@ho... > To: ste...@li... > 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: dag...@gm... > To: ste...@li... > 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 Ste...@li... > 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 Ste...@li... > 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 > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > |
From: Barry G. <bar...@ho...> - 2012-04-20 01:16:11
|
Hi Alex I compiled 5319 and it now works in the release mode Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" |