QGIS stürzt bei jeder Nutzereingabe im FIM-Plugin ab

[llissel]

Seit ca. 2 Wochen (16. Oktober) stürzt beim Testen des FIM-Plugins jedes Mal QGIS ab, sobald ich eine Nutzereingabe vornehme. Sprich sowohl der Klick auf "Einmessung starten", als auch der Versuch einer Eingabe im Feld "Truppkürzel" crashed das Programm. Wenn gewünscht, hänge ich auch gerne noch einen Fehlerreport von QGIS an.

[b-lack]

@llissel danke für das Feedback. Nach Tests konnte ich den Fehler nicht reproduzieren.

Es wäre daher gut, wenn du doch die Datei "g_los" die du verwendest, schicken könntest und/oder die Fehlermeldung von QGIS.

[llissel]

Hier die Fehlermeldung:

Report Details

Python Stack Trace

Windows fatal exception: access violation

Current thread 0x00001094 (most recent call first):
  File "C:\Users/efcaPAD#4/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\fim\fim.py", line 236 in run
    result = self.dlg.exec_()

Stack Trace

QString::indexOf :
QgsGpsDetector::advance :
QObject::qt_static_metacall :
QgsGpsConnection::stateChanged :
QgsNmeaConnection::parseData :
QObject::qt_static_metacall :
QSerialPort::handle :
KiUserApcDispatch :
NtUserMsgWaitForMultipleObjectsEx :
RealMsgWaitForMultipleObjectsEx :
QEventDispatcherWin32::processEvents :
qt_plugin_query_metadata :
QEventLoop::exec :
QDialog::exec :
PyInit_QtWidgets :
PyArg_ParseTuple_SizeT :
PyEval_EvalFrameDefault :
PyFunction_Vectorcall :
PyFloat_FromDouble :
PyVectorcall_Call :
PyObject_Call :
PyInit_QtCore :
PyInit_QtCore :
PyInit_QtCore :
PyInit_QtCore :
QObject::qt_static_metacall :
QAction::activate :
QAbstractButton::click :
QAbstractButton::mouseReleaseEvent :
QToolButton::mouseReleaseEvent :
QWidget::event :
QApplicationPrivate::notify_helper :
QApplication::notify :
QgsApplication::notify :
QCoreApplication::notifyInternal2 :
QApplicationPrivate::sendMouseEvent :
QSizePolicy::QSizePolicy :
QSizePolicy::QSizePolicy :
QApplicationPrivate::notify_helper :
QApplication::notify :
QgsApplication::notify :
QCoreApplication::notifyInternal2 :
QGuiApplicationPrivate::processMouseEvent :
QWindowSystemInterface::sendWindowSystemEvents :
QEventDispatcherWin32::processEvents :
qt_plugin_query_metadata :
QEventLoop::exec :
QCoreApplication::exec :
main :
BaseThreadInitThunk :
RtlUserThreadStart :

QGIS Info QGIS Version: 3.32.0-Lima QGIS code revision: 311a8cb8a6 Compiled against Qt: 5.15.3 Running against Qt: 5.15.3 Compiled against GDAL: 3.7.0 Running against GDAL: 3.7.0

System Info CPU Type: x86_64 Kernel Type: winnt Kernel Version: 10.0.19045

[b-lack]

@llissel scheint ein Performance Problem zu sein. D.h. bis zur nächsten Version muss nicht getestet werden.

[b-lack]

@twiebke Zur Info: Die Performance Probleme treten mit steigender Komplexität häufiger auf und führen teilweise zum Absturz von Qgis. Ausschließlich auf Windows. MacOs und Linux haben keine Probleme.

Ich schalte jetzt nach und nach Funktionen aus um einen vertretbaren Kompromiss aus Funktionen und Performance zu finden.

[llissel]

Ich habe das Plugin nochmal auf unserem Windows-Tablet getestet, dort stuerzt QGIS weiterhin zuverlaessig ab. Auf meinem eigenen Linux-Laptop konnte ich die Aufnahme abschliessen, allerdings werden scheinbar keine Werte gespeichert, wenn ich den abgeschlossenen Punkt nochmals zur Bearbeitung oeffne, sind keine Werte vorhanden, auch das direkt nach der Beendigung exportierte .geojson enthaelt keine Werte. Dementsprechend scheint das noch ein neues Issue zu sein.

{ "type": "FeatureCollection", "name": "LFB-Regeneration-Wildlife-Impact-Monitoring", "crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } }, "features": [ { "type": "Feature", "properties": { "id": "f12cd27a-6a3f-4f54-bf45-7d9f5c1a1f19", "los_id": "252918", "status": true, "type": null, "version": null, "created": "2023-12-04T14:25:33.601", "modified": "2023-12-04T14:25:33.601", "workflow": 5, "losnr": "202301", "form": { "general": { "spaufsucheaufnahmetruppkuerzel": null, "spaufsuchenichtbegehbarursacheid": null, "spaufsucheaufnahmetruppgnss": null }, "coordinates": { }, "stichprobenpunkt": { }, "baumplot1": { "baumplot1": [ ], "transectLocation": 0 }, "landmarken1": { "landmarken1": [ ] }, "baumplot2": { "baumplot2": [ ] }, "landmarken2": { "landmarken2": [ ] }, "transekt": { "protectiveMeasure": 0 }, "verjuengungstransekt": { "verjuengungstransekten": [ ], "transectLength": null }, "weiserpflanzen": { }, "transektinfo": { }, "bestandsbeschreibung": { }, "t_bestockung": { "t_bestockung": [ ] }, "t_bodenvegetation": { "t_bodenvegetation": [ ] }, "stoerung": { } }, "valid": null }, "geometry": { "type": "Point", "coordinates": [ 13.806381590559489, 52.816617541168263 ] } } ] }

[b-lack]

Danke @llissel das hilft schon ein bisschen. Wichtig wäre, wann QGIS abstürzt. z.B. Wenn du FIM öffnest, wenn du das Formular öffnest oder wenn du eine Eingabe machst.

Die "speichern"-Funktion ist glaube ich ausgeschaltet, da diese rechenintensiv ist. Ist ein Issue aber gewollt.

[llissel]

Oh sorry, wie zuvor stuerzt QGIS bei einer Nutzereingabe ab, oeffnen und schliessen laesst sich das Plugin. Edit: Habe noch einige Male versucht, das Plugin zu öffnen, es scheint schon dabei zu crashen und nicht erst bei der Nutzereingabe. Also Plugin wird geöffnet -> einige Sekunden keine Reaktion -> Fenster schaltet auf "keine Rückmeldung" -> QGIS crashed. Hatte bisher zu schnell versucht eine Eingabe zu tätigen und war deshalb fälschlicherweise davon ausgegangen, dass diese den Crash auslöst.

[b-lack]

Nach einigen Tests vermute ich, dass Performanceprobleme (nur unter Windows) auf Statusänderungen zur Laufzeit zurückzuführen sind. Hauptsächlich: Validierung der Eingaben, dynamische Erstellung des Formulars, Speichern von Daten (Zwischenspeichern) ...

Es betrifft also hauptsächlich die Usability und Scalability der Anwendung.

Info @twiebke: Ich baue das Formular nun komplett neu und statisch auf. Leider fallen hierdurch schöne, aber eben nicht "App-Breaking" Funktionen weg. Wenn es hierzu Gesprächsbedarf oder Vorschläge gibt, gerne melden.

Die Änderungen sind keine Garantie, dass es flüssig läuft aber die letzten Anstrengungen ohne die grundlegende Funktion anfassen zu müssen.

[twiebke]

Wie ist der Stand? Ich kann in den nächsten Tagen einmal testen.

[b-lack]

@twiebke Ist alles neu und performant. Leider gibt es einen neuen Bug "Nur unter Windows und nur von GPS und nur innerhalb des Plugins" stürzt Qgis ab. Das bedeutet, dass die Integration von GNAVS in FIM funktioniert, dort aber der GPSDetector zum Absturz führt.

wenn du also die Koordinaten manuell eingibst, kannst du alles testen.

[b-lack]

Ich habe nun eine potentielle Lösung gefunden. Die Umsetzung wird aber 1-2 Tage dauern.

Ich melde mich, wenn Testen möglich ist.

[b-lack]

FIM ist jetzt nicht mehr als Dialog sondern unten in qgis angedockt. Grund ist einfach, dass unter windows qgisGpsDetector nicht im Dialog funktioniert...weiß der Geier warum.

Wem das zu klein ist, der kann das angedockte Fenster lösen, dann funktioniert es auch:

d.h. es kann bitte getestet werden, das werde ich jetzt auch tun.

[b-lack]

Kann natürlich auch, je nach Auflösung verschoben werden:

[RicRat]

Hallo an alle, ich habe heute die neuste Version (1.0.14) auf dem FZ-G1 (Windows 10 Tablet) getestet. Den Absturz von Linus konnte ich reproduzieren, in dem ich das VWM Projekt vom letzten Jahr verwendet habe.

In einem neuen QGIS-Projekt, mit einer OSM-Hintergrundkarte und einem Punkte-Layer, konnte ich problemlos die Punkte in das FIM-Plugin importieren und diese darin bearbeiten.

Dabei sind mir folgende Punkte aufgefallen:

• Die Einmessung von 100 Punkten geht mit 12 Sekunden zu schnell.
• Bei der Einmessung sowie auch beim Button „Karte auf Punkt zentrieren“ springt die Karte zu den Koordinaten 0,0 (West-Afrika)
• Wenn ich bei der Bestandsbeschreibung „Einschichtig“ auswähle und anschließend bei Bestockung in der Schicht „Hauptbestand“ wähle, tritt der Fehler „Falsche Schichtenkombination“ auf.

LG Richard

[b-lack]

@RicRat was meinst du mit "geht mit 12 Sekunden zu schnell"? Ich habe bei verschiedenen Witterungsbedingungen auch unterschiedlich lang gebraucht um 100 Messungen zu machen. Ich nutze die 100 eingehenden Signale vom GNSS-Sensor.

[b-lack]

@RicRat ich habe mit den Punkten von Linus getestet, bei mir traten keine Fehler auf. Kannst du mir auch nochmal ein gezipptes Projekt per Mail senden, bei dem der Fehler Auftritt?

[twiebke]

@RicRat was meinst du mit "geht mit 12 Sekunden zu schnell"? Ich habe bei verschiedenen Witterungsbedingungen auch unterschiedlich lang gebraucht um 100 Messungen zu machen. Ich nutze die 100 eingehenden Signale vom GNSS-Sensor.

Die Zeit ist ja abhängig von der Konfiguration der GNSS-Geräte. Bei älteren oder schlecht konfigurierten Geräten kann das schon einmal 100 Sekunden (1Hz) dauern. Es sollte heutzutage selten länger dauern. Die Software sollte so gestrickt sein, dass man mit anderen Aufnahmen fortführen kann während die Messung stattfindet.

[b-lack]

@twiebke FIM kann weiter bedient werden...wenn es der Rechner hergibt. Das ist aber unabhängig von GNAVS/FIM.

[RicRat]

@RicRat was meinst du mit "geht mit 12 Sekunden zu schnell"? Ich habe bei verschiedenen Witterungsbedingungen auch unterschiedlich lang gebraucht um 100 Messungen zu machen. Ich nutze die 100 eingehenden Signale vom GNSS-Sensor.

Mit einem GNSS-Empfänger, der mit 1 Hz arbeitet, sollte die Messung der 100 Punkte eigentlich 100 Sekunden oder länger dauern. Mit dem externe Empfänger (PPM 10xx) der mit bis zu 20 Hz arbeitet haben die Messungen länger gedauert (ca. 30s).

Ich habe dazu auch ein neues Issue erstellt.

Gibt es eine Möglichkeit, ein Log ausgeben zu lassen, um genau zu sehen, mit welchen Messungen das Tool arbeitet?

[b-lack]

Gibt es eine Möglichkeit, ein Log ausgeben zu lassen, um genau zu sehen, mit welchen Messungen das Tool arbeitet?

@RicRat Wenn du im GNAVS Plugin eine Punktaufnahme beendest und "ADD TO MAP" drückst, siehst du alle eingehenden Koordinaten + Timestamp

[b-lack]

@RicRat @twiebke Ich möchte das Thema GNSS in das entsprechende Plugin umziehen: https://github.com/b-lack/qgis-gnavs-plugin/issues/27 und dort weiter diskutieren...

[b-lack]

@llissel @RicRat Ich konnte den Absturz jetzt zum ersten mal reproduzieren, wird in der kommenden v1.0.15 gefixed. Danke für Euer Feedback.

[b-lack]

@twiebke Qgis stürzt ab, wenn vwm4qgis20230427_prfg.qgz geöffnet wird. Wenn die Geopackages einzeln geladen werden, stürzt qgis nicht ab.

Ich nehme also an, dass ein Hintergrund-Service den Absturz verursacht. Wenn der "Fehler" behoben werden soll, müssen wir beide uns zusammensetzen, da du das Projekt besser kennst.

Alternativ werden die Daten in der kommenden Aufnahme eh anders ausgeliefert. Eine Fehlersuche ist somit vielleicht gar nicht nötig.

[twiebke]

Es werden ja nur die Rettungspunkte und -wege aus dem Layer angezeigt und es läuft ein wms zu osm. Ich könnte mir vorstellen, dass der wms abruf stört. Wir wollen ja mit fim die Daten über eine api abrufen. Den Aufnehmenden muss es aber möglich sein weitere layer hinzuzuladen. Ein WMS ist in Brandenburg eh quatsch. Das in dem genannten Projekt platzierte Formular könnte auch eine Ursache sein und ist ja mit fim auch nicht nötig.

[b-lack]

Problem wurde behoben.