Crashes of Stellarium 1.1 (1.22.4 based on Qt 6.4)

[smoinard18]

Hello,

Multiple craches while connected to a ASCOM telescope (real EQ6R-pro ASCOM, or simulated ASCOM). Works well few minutes and crashed randomly while capturing video on another software, no special action in Stellarium.

Hope the following informations will help... Returning to 0.22.1.

Note that the provided log has been generated with a simulated ASCOM telescope (same crashes with a real connected telescope).

Platform and operating system:

Windows 11 Pro 21H2 build 22000.181.0, 64bits up to date

What kind of graphics card do you have? Driver version?

Intel Iris Plus Graphics. Driver Intel 27.20.100.9365

Which version of Stellarium causes problems:

stellarium-1.1.1-qt6-win64.exe - Stellarium 1.1 (1.22.4 based on Qt 6.4)

The LOGFILE:
See joined file log.txt

Stef
log.txt

[github-actions]

Thanks for adding your first issue to Stellarium. If you have questions, please do not hesitate to contact us.

[gzotti]

Duplicate of #2821. However, with note that an ASCOM simulator is enough to cause crashes.

[smoinard18]

Please note that when the crash has been reproduced with an ASCOM simulator, I was not using Sharpcap.
However Sharpcap is installed on the same PC, and the crashes with my real telescope occured while using Sharpcap and Firecapture, but both were not connected to the mount.

[github-actions]

This is a good task for the community to participate in the contribution into Stellarium. Who wants to help us?

[smoinard18]

What kind of participation do you want me to help ?

[gzotti]

Somebody with an interest and motivation in removing INDI/ASCOM/SharpCap/DeviceHub-related problems must look into them. It probably requires some changes in the code, so building from source is a prerequisite, then checking the code of the ASCOM/INDI-related parts of the Telescope plugin. Knowledge about running a debugger may be advantageous.

[ouiouiblog]

@smoinard18, I don't know if that may help. I had the same problem with 1.1.1-QT6-W64. Crashing with an Ascom telescope. Crashes may occur randomly or immediately if I used Alt-Tab.

Problem is gone since I use 1.1.1-QT5-W64. You could try by our own.

Platform and operating system:
Windows 10 Family 22H2 build 19045,2251 64bits up to date

What kind of graphics card do you have? Driver version?
AMD ATI HD4500. Driver Intel 27.20.100.9365

Which version of Stellarium causes problems:
stellarium-1.1.1-qt6-win64.exe - Stellarium 1.1 (1.22.4 based on Qt 6.4)

[Blanshan91]

I am having the same issue. Since updating to v1.1, Stellarium will crash after 1-2 minutes when running, especially after a sync. Are the previous version avaiable for download so I can further test?

[gzotti]

Yes. All releases are available when following the "All releases" link on stellarium.org.
Can you try with Qt5-based release 1.1?

[Kev1909]

Hello,
Same problem also with v1.0.
I was going back to v0.22.2 and have no problems anymore with crashes.
I use Stellarium Scope to connect and control my EQ6-R.
The crashes comes only when I jump between different Windows (Sharpcap, NINA) and go back to the Stellarium Window.

[ouiouiblog]

@Kev1909 you should try 1.1.1-QT5-W64. it solved my problem

[gzotti]

@Kev1909 the same request to you: can you try Qt5-based version 1.1 (https://github.com/Stellarium/stellarium/releases/download/v1.1/stellarium-1.1.1-qt5-win64.exe) ? We have several reports regarding Qt6-based builds when changing between Stellarium and NINA/SharpCap etc, and we tend to believe them. OK, error registered. However, probably no developer currently seems to have enough spare time to ever go observing. My own demands were always fulfilled with my old little drive, LX200 protocol (no chance to experience ASCOM or INDI issues), external autoguider (no chance to see NINA/SharpCap issues), and my DSLR's auto timer.

Going back to a previous version is one option for users, but no step towards solving the problem. (Probably Stellarium 0.14 or 0.16 was good enough for driving telescopes in the 2020s.) Knowing that the problem lies in the actual Qt5/Qt6 transition would be a little but valuable piece of information for the community.

[gzotti]

@ouiouiblog thank you for this confirmation!

[Kev1909]

Ok I will try it and give u feedback. Thank you both!

[Kev1909]

@gzotti You are right! Qt5 runs without any crashes and works well! Thank You.

FYI: The crashes in Qt6 happens only when I connected to to Telescope and jump between diffenrent windows.

Kind regards
Kevin

[gzotti]

OK. So, telescope users with problems should use Qt5-based builds. And one of them should feel invited to fix this.

[fl0wm0ti0n]

I have this issue too... recent version of ASCOM EQMOD and Stellarium with EQ5 Mount Goto

it seems crashing when switch open windows.

[ouiouiblog]

you should try 1.1.1-QT5-W64. it solved my problem

[fl0wm0ti0n]

you should try 1.1.1-QT5-W64. it solved my problem

thanks! this version works in this case, but i have a different problem... idk if it is the same related issue...

if i make slew and sync with the eqmod aligment tool, after the second "sync" button press SynScan geors back to non PC direct mode and Stellarium freezes, or nearly freezes cause it seems to be ultra slow with the time refreshing only every few minutes.

so first "Sync" works, second not

[whiochon]

I want to help with this issue.
I have run the latest stable Stellarium with the debugger in Qt Creator, and found where it crashes.
Confirmed that it occurs with all versions of QT6, including the latest 6.5, but not QT5.

First, it is easy to reproduce, without specific equipment.
An ASCOM driver with simulated telescope is sufficient. I used the latest ASCOM and Green Swamp Server.

1. Configure Stellarium with a simulated ASCOM telescope to connect at startup
2. Move the telescope somewhere in Stellarium
3. Change windows context (I put Chrome maximised over the top of Stellarium)
4. Wait 60 seconds
5. Switch back to Stellarium

Crash:
C:\Users\qt\work\qt\qtbase\src\opengl\qopenglpaintengine.cpp:2619: error: Debugger encountered an exception: Exception at 0x7ff8f0dd8fd6, code: 0xc0000005: read access violation at: 0x1c0, flags=0x0 (first chance)

The error occurs when an OpenGL state is being refreshed, or re-created?

I added some debug with timestamps to ASCOMDevice.cpp, and found that right before the crash, ASCOMDevice::isDeviceConnected() looks like it is called twice, concurrently.
ie, a second call is made before the 1st is finished.
Does QT6 do something that requires plugins to be thread safe?

[whiochon]

Adding to hints of duplicated objects, when building in "Debug" mode, the following exception is triggered, instead of the error above:

There can be only 1 instance of StelPainter at a given time
Debug Error!

Program: C:\Code\Qt\6.4.0\msvc2019_64\bin\Qt6Cored.dll
Module: 6.4.0
File: C:\Code\stellarium\src\core\StelPainter.cpp
Line: 143

This error only occurs if an ASCOM simulated telescope is active.
If using the Stellarium simulated telescope, it does not occur.

Code from StelPainter.cpp::

#ifndef NDEBUG
	Q_ASSERT(globalMutex);
	
	GLenum er = glGetError();
	if (er!=GL_NO_ERROR)
	{
		if (er==GL_INVALID_OPERATION)
			qFatal("Invalid openGL operation. It is likely that you used openGL calls without having a valid instance of StelPainter");
	}

	// Lock the global mutex ensuring that no other instances of StelPainter are currently being used
	if (globalMutex->tryLock()==false)
	{
		qFatal("There can be only 1 instance of StelPainter at a given time");
	}
#endif

[alex-w]

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[whiochon]

Hi @alex-w ,
I did a clean install of snapshot stellarium-23.2-a69d242-qt6-win64.exe but unfortunately, was still able to reproduce the same problem with the steps as above.

[10110111]

Please post the log for this new version.

[gzotti]

Several Qt6/TelescopeControl issues have been solved before 23.3. We would like to clean-out a large group of related issue reports which are hard to reproduce without actual telescopes or external software. If no follow-up to this happens by November 1, 2023, we will close this as tentatively solved.

[10110111]

Tried with ASCOM.Simulator.Telescope too now, no crashes here. Did you start the correct version of Stellarium? Maybe you have multiple installed, and started not the one I linked to above?

[StarFlea]

Version is correct: 24.1.165-d2753bb [HEAD]

[StarFlea]

I tested with ScopeSim.Telescope...
There is a reproducable crash too.

[kantn8r]

Thank you StarFlea, you saved me from wasting my time. As mentioned in my prior response, when a QT6 fix is implemented, I'd be happy to test. Any fix needs to be tested with ASCOM.Simulator.Telescope or equivalent before proposing it to the end users.

[10110111]

when a QT6 fix is implemented, I'd be happy to test

When it's implemented, it will be past the time to test, you will just be using it. And without testing of the versions that I post in this issue the fix will not be implemented.

Any fix needs to be tested with ASCOM.Simulator.Telescope or equivalent before proposing it to the end users.

If you read my posts more carefully, you'll notice that I have tested my proposed fixes, and failed to get any crash with them. So the ball is on the end-users' side.

[10110111]

@StarFlea

Well, I can't reproduce this.

If you could test it on a Windows virtual machine and reproduce the crash (and tell how you did this), this would be very useful. This is the Windows environment I'm using to debug this, and so far I've failed to get a crash with the test version I linked to above.

[kantn8r]

For me it's more about maintaining all the settings I've made in Stellarium for my kit. There are a lot of important subtle settings for doing an EAA session that don't translate between the different fixes/versions when installed and uninstalled and reinstalled. How do I ensure that all the settings/features are not lost when testing?

[StarFlea]

Well, I usually need to switch the windows-frames a few times before I provoke the crash. It doesn't happen immediately.
It can take a few minutes...

I'll try it with the virtual machine. I use Windows 10 productively.

[10110111]

How do I ensure that all the settings/features are not lost when testing?

First, on uninstalling you are asked whether you want to keep the settings or remove them. Then, to make really sure that you don't lose your settings even if your computer gets broken, you should back them up. The location is documented in section 5 of the User Guide (and also showed in the Help dialog inside the app).

[kantn8r]

I'll start backing up my settings.

I'd be happy to purchase a SharpCap Pro license for you or other developers working on fixes to the QT6 / ASCOM / Telescope Control crash. I'm assuming you have a Windows 10 or 11 computer to run SharpCap. It's also possible that you don't need SharpCap Pro to test this issue. Regular SharpCap is free.

Anyone testing should be running ASCOM and a telescope simulator with some other camera control software like SharpCap. All you need to do is cycle between windows a few times and QT6 will crash. It does not always crash immediately.

When you get to a point where QT6 does not crash after many cycles it will be ready for me to test.

[StarFlea]

I was able to reproduce the crash into the virtual machine!

A part of the truth may be that you have to run Stellarium in window-mode (not full-screen mode).
I was only able to reproduce the crash after I copied the config.ini from my productive installation to the virtual machine...

I attached it as txt-file...
config.txt

[StarFlea]

CORRECTION: My config has nothing to do with it!

Now it crashed in the basic configuration! Window-mode seems to be the problem!

[StarFlea]

I will now describe again what I did in the virtual machine:

1. .NET 3.5 activated in Windows Control Panel
2. ASCOM Platform 6.6 SP2 installed
3. Stellarium installed in the debug version 24.1.165-d2753bb [HEAD]
4. Stellarium started and telescope control activated
5. New telescope set up (ASCOM.Simulator.Telescope = Telescope Simulator for .NET)
6. Full screen mode deactivated and settings saved
7. Restarted Stellarium (in window mode) and telescope connected
8. After several window changes between Stellarium and Windows Explorer, the crash is triggered

[10110111]

OK, with your config file and instructions I'm able to reproduce the crash.

[StarFlea]

The config file doesn't matter. It also works in the basic configuration.

[github-actions]

Hello @smoinard18!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions]

Hello @smoinard18!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest

[StarFlea]

Is there a chance that the problem is obsolete with the newly released ASCOM Platform 7?

[10110111]

I don't think so. The issue is in the incompatibility between Win32 COM and Qt6. Until someone implements support for Alpaca in Stellarium, the Qt6 build will not work with ASCOM.

[gzotti]

I cannot say what causes the issue, but it's more future proof to just go directly to ASCOM's successor, Alpaca, without further wasting our time. @StarFlea, you can just reactivate the exclusion in CMakeFiles and build and try if you really want.