stellarium
stellarium copied to clipboard
Stellarium
stellarium-1.1.1-qt6-win64.exe quits when using SharpCap
This may be a duplicate of Issue #2724 but it's possible this is not related to the Telescope Control plugin.
Expected Behaviour is for Stellarium to work when using SharpCap, just as 0.22.2 works.
Actual Behaviour is Stellarium 1.22.3 and 1.22.4 start up fine, Telescope Control plugin loads fine, Gemini Telescope.NET is selected and connected fine, and mount is slewed to the first target fine. Then as soon as I switch to SharpCap and make any mount adjustments, Stellarium quits. This can be repeated over and over.
Initially I thought this was related to the Telescope Control plugin but perhaps it is something else.
The steps described above can reproduce the problem every time.
- Stellarium version: stellarium-1.1.1-qt6-win64.exe
- Operating system: Windows 10 Pro
- Minisforum Celeron Mini-PC running ASCOM, Gemini Telescope.NET (latest non-beta version), Stellarium and SharpCap (latest 64-bit version).
A log file from a prior 1.22.3 session was posted in Issue #2724
Thanks for adding your first issue to Stellarium. If you have questions, please do not hesitate to contact us.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Maybe the same issue: Stellarium closes after a few seconds, if I minimize the EQMOD window to the Taskbar.
- Stellarium version: stellarium-1.1.1-qt6-win64.exe
- Operationg system: Windows 10 Pro
- Running EQMOD ASCOM V2.00u
It was suggested on Cloudy Nights that I check and make sure the apps I'm using for EAA are not set to "Run as Administrator". I will check Gemini Telescope.NET, SharpCap and Stellarium tomorrow to see how they are run. I've not set any of the apps to "Run as Administrator" unless they install that way by default.
I've checked all the apps I run for EAA and none are set to run as administrator. I did look around in the Event Manager and came up with a couple of Windows Application logs. One if for 1.22.3.1292 and the other is for 1.22.4.0.
WindowsErrorLog_Stellarium_10242022.txt WindowsErrorLog_Stellarium_11032022.txt
Can confirm same issue - haven't had a chance to re-produce, but seems similar, Sharpcap, EQMod, Minimise - Gone! Will test this weekend.
Hello!
I can confirm this, too. I use Stellarium version 1.22.4 in combination with actual SharpCap 4.0 and EQMod 2.00v and Windows 10. I try to align with SharpCap-crosshair. When i return to Stellarium for synchronisation it crashes before i can do any mouseclick on a button. The issue is usually reproducable, but it is very annoying too. Yesterday night it crashes over one dozen times... :-(
Best regards! StarFlea
I'm not sure if this is related but Stellarium 0.22.2 quit last night. I don't think this has happened before. The log is attached.
StellariumErrorLog_11232022.txt
Here are the extracted problem details from Windows Maintenance:
Description Faulting Application Path: C:\Program Files\Stellarium\stellarium.exe
Problem signature Problem Event Name: APPCRASH Application Name: stellarium.exe Application Version: 1.22.4.0 Application Timestamp: 635fec63 Fault Module Name: Qt6OpenGL.dll Fault Module Version: 6.4.0.0 Fault Module Timestamp: 62bcd033 Exception Code: c0000005 Exception Offset: 0000000000018dd6 OS Version: 10.0.19045.2.0.0.256.48 Locale ID: 1031 Additional Information 1: 51d3 Additional Information 2: 51d3b4e5fcdd7ac4b6b18a4bce08df38 Additional Information 3: 3c3e Additional Information 4: 3c3e336bcfd525dddaeef651e95c34a1
Extra information about the problem Bucket-ID: 65fb1fc8e0be7c7d8016912a656b9e9f (1159273565370687135)
This is a good task for the community to participate in the contribution into Stellarium. Who wants to help us?
Please check the fresh version (development snapshot) of Stellarium: https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot
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.
Hello @kantn8r!
Please check the fresh version (development snapshot) of Stellarium: https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot
Hello @kantn8r!
Please check the latest stable version of Stellarium: https://github.com/Stellarium/stellarium/releases/latest
Georg, thank you for reopening this issue. I was not sure what to do since the issue was closed before I tested the G11G, SharpCap and Stellarium together. I need clear skies to do testing and it's been quite cloudy lately. It's very hard for me to follow all the weekly snapshots so is there a way for someone to notify me when you have a Qt6 snapshot ready to test?
Since the Qt6 does not yet work do you recommend I try the 23.3 Qt5 version until this is fixed?
Usually every week, or at least if there was developer activity (which is usually the case) there are weekly snapshots. We had hoped that the two fixes applied in July also would have closed this one. However, without being tortured (or at least affected) by your issues I will likely not be able to trace this one. If somebody else provides a solution, there will be a new notification in this issue thread.
Sure, as long as the Qt6 build has a problem, using the else same-numbered Qt5 build is the workaround. Going back to an older version is not recommended.
I don't have any telescope nor Windows, so please give me some details:
- Does SharpCap connect to Stellarium, or is it just an independent program you run in parallel?
- Does SharpCap connect to the telescope?
- Does the crash only happen when Stellarium is connected to the telescope?
- What exactly does "make any mount adjustments" mean—do these adjustments affect how the telescope is controlled? Does the crash reproduce if you don't adjust anything, just go to SharpCap window, wait a few seconds and go back?
Hello,
So for now I can only talk about my own experiences:
Regarding number 1: SharpCap is NOT connected with Stellarium. It is a live stacking program to capture camera images.
Regarding number 2: Yes, SharpCap is always connected to the mount for me: for GOTOs and platesolving.
Regarding number 3: I have to answer this question as YES because, as I said, SharpCap is always connected to the mount. I can't answer whether it will crash if there is no connection!
Regarding number 4: In my experience, adjustments to the mount are not absolutely necessary. It's more like this: A quick switch to the SharpCap window and back to Stellarium is enough to cause the program to crash.
In my opinion it may not be a specific problem with SharpCap, but rather a general problem with the parallel running telescope control plugin (#2874), possibly also the GUI, since I I've also recently had crashes with Qt5.
Best regards Star Flea
Stop! Did you connect to the mount from Stellarium and from SharpCap in the same time?
That's exactly how it is! I use Stellarium to see exactly where the telescope is pointing and to perform manual GOTOs. SharpCap is then responsible for the capturing and plate solving including a SYNC and a Re-GOTO...
Stop! Did you connect to the mount from Stellarium and from SharpCap in the same time?
When using ASCOM that should not be an issue - it allows Multiple programs to connect at the same time. I regularly have used it this way, whether capturing in Sharpcap or N.I.N.A -etc.
I can add some more to this from my own recent Experience too. A PC I rebuilt for imaging with, it is an AMD Threadripper 1950x 64GB RAM, Radeon 5700xt GPU - so not shy on resources. Windows 10, installed latest Stellarium - I think 23.something - Open Stellarium...set everything up to work same as previous builds - ALL GOOD. Controlling scope, Capturing fine...Crash...oh wait what ?!? This time at least it wasn't crashing JUST from slewing...it was random.
In the end - Iooked at the download file to notice it was QT6 - and recalled there should be a QT5 - so did a bit of poking around, Bingo, there was a QT5 of the same version. Installed it - 100% operational, No crashes, whether Using Sharpcap or not... I'm yet to test one more element that used to Crash - which was if I RDP to the PC and it resizes the Stellarium window...that would cause it to crash too.
I guess we need to employ a stack tracer for Windows builds. Otherwise such issues will take quite a long time to debug.
I tried the 23.3 Qt6 version at the request of Georg and it did not work. Luckily it's only Stellarium that quits and the other ASCOM programs continue running (CPWI, PHD2, SharpCap). I use SharpCap the same way as StarFlea. Stellarium is my planetarium application for viewing the sky and selecting objects to Go-To, at which point I use SharpCap. It's the switching between SharpCap and Stellarium that seems to cause Stellarium to quit. The Qt5 version works fine.
I tried the 23.3 Qt6 version at the request of Georg and it did not work. Luckily it's only Stellarium that quits and the other ASCOM programs continue running (CPWI, PHD2, SharpCap). I use SharpCap the same way as StarFlea. Stellarium is my planetarium application for viewing the sky and selecting objects to Go-To, at which point I use SharpCap. It's the switching between SharpCap and Stellarium that seems to cause Stellarium to quit. The Qt5 version works fine.
exactly same symptoms as me - randomly, but predominately that. It sort of wouldn't be an issue if setting an image, and getting hours of shots on it before moving on. Mine was a bit embarassing the other night when it happened, as it was a public event where we would take a few shots of an object, then move along to the next object... Meaning having to flick to Stellarium each time, but the moment you did it would crash. But if I went from Stellarium to sharpcap, then back again to stellarium fairly quickly, not an issue. Seems to be that time plays a factor in the crashing - maybe a memory leak somewhere...
As I already said in thread #2874 the problem is probably not specifically related to SharpCap but rather to a window change to any program.
Apparently there is an inoperability between Qt6 and ASCOM (and possibly also OpenGL). I use ASCOM platform 6.6SP2. I can now reproduce the error quite reliably with a Qt6 version of Stellarium, but I can't figure out the cause:
- Start Stellarium and go to the Telecope Control ("Slew telescope to" button, then the "Configure telescopes" button).
- Connect to the ASCOM telescope simulator "ScopeSim.Telescope" or the "ASCOM.Simulator.Telescope". Neither GSS nor EQMOD or a connection from SharpCap ist necessary!
- Switch to any other running program window (e.g. Firefox, Windows Explorer, SharpCap, ...)
- Switch back to the Stellarium program window.
- After a few moments, Stellarium says goodbye silently without a specific message and without any further action on my part.
The Qt5 version does not show this behavior. In addition, there is no problem as long as no connection to ASCOM is established.
Maybe one of you has another idea? Perhaps some of you can also reproduce this or can narrow down the problem even further?
I now ran the Microsoft Debug Diagnostic Tool during the crash and analyzed the whole thing with DebugDiag Analysis. Unfortunately I don't know enough about the subject, but maybe one of you can do something with it:
An access violation occurs in the module Qt6OpenGL.dll The suspicious instruction is called Qt6OpenGL!QOpenGL2PaintEngineEx::setState+56 or perhaps Qt6Gui!QPainter::restore+124
Just a wild guess, but could there be a problem redrawing the main Stellarium window? Maybe it's not a bug in Stellarium but in the Qt6 framework?
As long as no other program window is open, or as long as you don't switch to another program window and return to the Stellarium window, there is no crash.
I have attached the complete diagnostic file as a PDF. Stellarium_Crash_Dump.pdf
Qt6Widgets!QGraphicsScene::~QGraphicsScene+34f9 Qt6Core!QMetaCallEvent::placeMetaCall+84 Qt6Core!QObject::event+169 Qt6Widgets!QGraphicsScene::event+75a
This like as if some event happened in QGraphicsScene that resulted in destruction of a QGraphicsScene. If I understand correctly, the only instance of this class is StelGraphicsScene. It's a child of StelMainView and is never deleted explicitly, so it could only be deleted when StelMainView is being destroyed.
Right? If yes, then what event could come to StelGraphicsScene that would lead to a shutdown?
Another guess is that this is a result of memory corruption, so some Valgrind-like tool would be needed to debug this.
Good idea, but what kind of event would that be?
I noticed something strange: The crash only seems to occur as soon as I connect an ASCOM telescope via the telescope control and briefly bring any program window (e.g. Notepad) to the foreground via the Windows taskbar and then via the Windows taskbar bring Stellarium back to the foreground or the other program to the background. But when I bring Stellarium back to the foreground using the title bar, nothing seems to happen.
The problem may occur if ... ... the main window or parts of it are redrawn? ... the window status is restored?
- Perhaps an unconsidered window state is being triggered and is being handled incorrectly?
- And why is a connection to an ASCOM telescope a mandatory requirement for the crash? Does the connection change the window state somehow?
- Maybe a telescope control thread issue related to the GUI?
I'm confused! Unfortunately I have no knowledge of Qt6 or C++. My programming focus is more on Java and Swing...
If you could build Stellarium in debug mode (i.e. passing -DCMAKE_BUILD_TYPE=Debug to cmake), following the instructions here, we would be able to get more information about the crash.
Let's see, I first have to work in and inform myself with the basics...
But a stupid question: Is it possible to include Qt6.6 in Stellarium? I found some fixed bugs in the release notes (https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.6.0/release-note.md) that could be related to our problem...