Absturz beim Start einer zweiten Fassung neben der laufenden behoben - #19
Merged
Merged
Conversation
Absturzbericht Contestprogramm-2026-09-28-110149.ips: 0.1.1 lief seit 08:57, um 11:01:33 EXC_BAD_ACCESS bei 0x30 im Hauptthread, in doActivate <- QIODevice::channelReadyRead <- canReadNotification <- QReadNotifier. Zwei Minuten vorher lag /Applications/Contestprogramm- neu.app zum Testen bereit, und Martin startete sie neben der laufenden. Der Weg: die neue Fassung meldet sich beim SingleInstanceGuard der laufenden mit einem anderen Baustempel. Der liest die Zeile im readyRead des QLocalSocket, sendet newerBuildStarted, main.cpp startet neu und ruft dafür release() auf. release() löschte den QLocalServer sofort, und mit ihm den Client-Socket (dessen Kind), während der noch in seinem eigenen readyRead steckte. Qt sendet direkt danach channelReadyRead() auf demselben Socket: in freigegebenen Speicher. macOS nullt den, d_ptr ist 0, Lesezugriff auf 0x30. Die vier TCP-Clients (ON4KST, Cluster, rigctld, rotctld) scheiden aus: sie leben als Wert-Member von AppController so lange wie das Programm, ihre Sockets werden nur geschlossen, nie gelöscht. Der Fix: release() schließt den Server wie bisher (lauscht nicht mehr, Name frei, Sperre frei), löscht das Objekt aber per deleteLater(), also erst, wenn der Stapel abgebaut ist. Die Annahmeschleife hält den Server als Zeiger statt über m_server, das release() mittendrin leert. Nachgestellt, vorher und nachher: - Test releasingFromTheRestartSignalDoesNotPullTheSocketFromUnderItsOwnRead: ohne Fix rot auf jeder Plattform (Socket überlebt release() nicht); unter ASan mit free_fill_byte=0 Absturz an genau den Offsets des Berichts (QtCore+0xf2f80, Zugriff 0x30). - Live mit Sandbox-Datenordner: installierte Fassung laufen lassen, zweite Fassung daneben starten -> Status 139, neuer Absturzbericht mit denselben fünf Qt-Offsets wie Martins. Mit Fix 3/3 sauberer Neustart, Status 0, kein Bericht. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Absturzbericht
Contestprogramm-2026-09-28-110149.ips: 0.1.1, lief seit 08:57, um 11:01:33EXC_BAD_ACCESSbei0x30im Hauptthread (doActivate←QIODevice::channelReadyRead←canReadNotification←QReadNotifier). Zwei Minuten vorher lag/Applications/Contestprogramm-neu.appzum Testen bereit und wurde neben der laufenden Fassung gestartet.Ursache
Die neue Fassung meldet sich beim
SingleInstanceGuardder laufenden mit anderem Baustempel →newerBuildStartedimreadyReaddesQLocalSocket→main.cppstartet neu und ruftrelease()→release()löschte denQLocalServersofort, und mit ihm den Client-Socket (sein Kind), während der noch in seinem eigenenreadyReadsteckte. Qt sendet gleich danachchannelReadyRead()auf demselben Socket, in freigegebenen (von macOS genullten) Speicher:d_ptr= 0, Lesezugriff auf 0x30.Die vier TCP-Clients (ON4KST, Cluster, rigctld, rotctld) scheiden aus: Sie sind Wert-Member von
AppController, ihre Sockets werden nur geschlossen, nie gelöscht.Fix
release()schließt den Server wie bisher (lauscht nicht mehr, Name und Sperre frei), löscht ihn aber perdeleteLater(). Die Annahmeschleife hält den Server als Zeiger statt über das dabei geleertem_server.Nachweis
releasingFromTheRestartSignalDoesNotPullTheSocketFromUnderItsOwnRead: ohne Fix auf jeder Plattform rot. Unter ASan mitfree_fill_byte=0stürzt der Code ohne Fix an genau den Offsets aus dem Bericht ab (QtCore+0xf2f80, Zugriff 0x30).ctest: 107/107.🤖 Generated with Claude Code