Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf

de-users
#1

Bezug 1: https://listarchives.libreoffice.org/de/users/msg21463.html
Bezug 2: https://listarchives.libreoffice.org/de/users/msg21448.html

Hallo Oliver,

ich habe jetzt mal ganz ausführlich getestet (s.u. TESTREIHE):

[1] Es ist unerheblich, ob man den extern Makro-Aufruf via "WindowsBatch" oder "Perl" durchführt. Sollte also auch mit einem (vergleichbaren) Linux-BASH-Aufruf funktionieren.

[2] Mit der LO-Dateiauswahl (com.sun.star.ui.dialogs.OfficeFolderPicker) funktioniert das Makro IMMER FEHLERFREI.

[3] Mit der Betriebssystem-Dateiauswahl (com.sun.star.ui.dialogs.FolderPicker) funktioniert das Makro ab "LO 6.2.1.2" NICHT MEHR.

[3.1] Das Makro bleibt hängen, wenn man via angezeigter Dateiauswahl ein Verzeichnis ausgewählt hat und danach die Dateiauswahl wieder (automatisch) ausgeblendet wurde.
[3.2] Der WindowsTaskManager zeigt an, dass die Prozesse "soffice.bin" und "soffice.exe" existieren, aber keinerlei CPU-Last erzeugen.

[4] Startet man in der Hängenbleiben-Situation [3.1] zusätzlich manuell "soffice.exe" nochmals, läuft das Makro dann fehlerfrei weiter.

[4.1] Entgegen meiner früheren Aussage, muss man (beispielsweise) nicht eine neue CALC manuell öffnen, es reicht "soffice.exe" manuell (nachzu) starten.

Wie das jetzt alles zusammenhängt ( Warum läuft das Makro weiter, wenn man "soffice.exe" manuell nachstartet ?) kann ich nicht erklären, da ich zu wenig über die LO-internen Abläufe weiß.

Grüße
Hans-Werner

TESTREIHE

(A) LO 5.3.7.2 (x64) - Installation PARALLEL

"com.sun.star.ui.dialogs.FolderPicker" => OKAY
"com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY

(B) LO 6.1.5.2 (x64) - Installation PARALLEL

"com.sun.star.ui.dialogs.FolderPicker" => OKAY
"com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY

(C) LO 6.2.1.2 (x64) - Installation PARALLEL

"com.sun.star.ui.dialogs.FolderPicker" => ERROR
+ Makro bleibt hängen.
+ Startet man in dieser Situation "...\LibreOffice\program\soffice.exe" zusätzlich manuell nach, läuft das Makro fehlerfrei weiter.

"com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY

(D) LO 6.2.2.2 (x64) - Installation STANDARD

"com.sun.star.ui.dialogs.FolderPicker" => ERROR
+ Makro bleibt hängen.
+ Startet man in dieser Situation "...\LibreOffice\program\soffice.exe" zusätzlich manuell nach, läuft das Makro fehlerfrei weiter.

"com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY

#2

Hallo Hans-Werner,

also ich hab das Makro extern via Batch gestartet - mit und ohne aktiven Schnellstarter.
Bei mir läuft das durch, hab es mehrfach versucht.

Gruß
Oliver

#3

Hallo Oliver,

da fällt mir jetzt nichts mehr dazu ein, außer:

Hast Du das Makro mit "LO 6.2.1.2 (x64)" oder neuer getestet ? Der Fehler tritt erst ab "LO 6.2.x.x" auf !

Aus Deinem BugReport geht hervor, dass Dein Betriebssystem "Windows 10" ist, meines ist "Windows 7 Home Premium 64-bit". So könnte das Ganze auch eine "Windows 7"-spezifisches Problem sein, wenn Du das Makro mit "LO 6.2.1.2 (x64)" oder neuer getestet hast.

Grüße
Hans-Werner

------ Originalnachricht ------

#4

Hallo,

vielen Dank für Eure vielfältigen Ratschläge, Tests und Eure Zeit.

Auch ich war in der Zwischenzeit nicht untätig.
Mein Betreibssystem ist Win 10 Pro (x64) 1809 Build (17763.379)

Habe nach wie vor Probleme mit den Abstürzen, wenn ich die abschließende
Messagebox aktiviere.
Auch Verzögerungen durch Wait haben nichts gebracht.
Das Makro habe ich nun umgeschrieben und zwei Labels oberhalb der
Schaltflächen eingefügt,
welche nun den jeweiligen Status farblich und mit Meldungen versehen
anzeigen.
Dies funktioniert ohne Absturz.

Zum Absturz, bzw. Einfrieren habe ich die Windows-Prozesse, bzw. die
Libreoffice-Prozesse
im Augenblick des Einfrieren genauer unter die Lupe genommen.
Zur Analyse von Prozessen habe ich mir vor längerer Zeit das Tool
"ProcMon.Exe 3.5" heruntergeladen.
Download unter:
https://live.sysinternals.com/

Mit dem Tool habe ich mir zum Zeitpunkt des Einfrierens
eine CSV-Datei mit alle aktiven Prozesses schreiben lassen.
Dann habe ich die LibO-Prozesse mittels Calc herausfiltern lassen.
Im Anschluß die Duplikate der Spalte "Results" herausgefiltert.
Dabei kamen diese Results heraus:

SUCCESS
REPARSE
NAME NOT FOUND
FILE LOCKED WITH ONLY READERS
NO MORE ENTRIES
BUFFER OVERFLOW
ACCESS DENIED
NO SUCH FILE
NAME COLLISION
NO MORE FILES
PATH NOT FOUND
END OF FILE
INVALID PARAMETER
NOT A DIRECTORY
SHARING VIOLATION
0xC00004AE
FILE LOCKED WITH WRITERS
BUFFER TOO SMALL
IS DIRECTORY
NOT REPARSE POINT
FS DRIVER REQUIRED
OBJECT PATH INVALID

Zu den einzelnen Results, gibt es in der Spalte Path Hinweise zum
Ursprung der Meldung.

Bei meinen weiteren Überlegungen hatte ich auch meine Firewall und den
Virenscanner in Verdacht.
Denn zum Zeitpunkt des Absturzes schnellt bekanntlich die CPU-Last auf
25-28% hoch und
außerdem wird ein sehr hoher Stromverbrauch gemessen. Da lag die
Vermutung nahe,
dass die Firewall einen Angriff vermutet. Das hat sich nicht bewahrheitet.
Hatte Virenscanner und Firewall abgeschaltet und einen Crash provoziert.

Die nächste Überlegung geht in Richtung Betriebssytem.
Da ich nach der Erstellung meines ursprüglichen Makros ein
WIN-Update von 1803 auf 1809 durchgeführt hatte.
Ggf. gibt ist in 1809 irgendwelche neuen Sicherheitsfunktionen,
welche Programme mit sehr hohem Stromverbraucxh blocken.
Diese ist aber auch nur eine Vermutung. Möchte auch nicht an meinem
störungsfrei laufenden Betriebsystem herumbasteln.

Die Frage welche sich abschließend stellt, warum kommt es zu einem
BUFFER OVERFLOW, BUFFER TOO SMALL, etc. wenn eine Messagebox aufpoppt?
Und warum wird ein so hoher Stromverbrauch gemessen?

Ach ja, warum dies: NAME COLLISION?
Dieses Result wird mir durchgängig bei Prozess soffice.bin in Verbindung
mit meinem Windows-User-Pfad bishin zum LibO\4\User angezeigt.
Mein Name ohne Umlaut geschrieben: Juergen

Nochmals Dank für Alles und an Alle!

Viele Grüße

Jürgen

#5

Hallo Jürgen, Hans-Werner, Oliver,

ich habe nun das Problem ziemlich eingrenzen können, kann aber keine Erklärung für das Verhalten finden.

Aber im Detail:
Ich habe Jürgens Programm reduziert, bis ich zu dem folgenden Rumpf gekommen bin:

Sub StartKopfzeile

DialogLibraries.LoadLibrary("Standard")    'auch ein fester Dialog bringt keine Änderung
    oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
    oDlg.execute

End Sub

REM Aktion Pseudo-Kopfzeilen eintragen und formatieren
Sub btnStart_actionPerformed(oEvent2)

sUrl = converttoUrl("C:\Users\zwi\Musterdateien_02\Kopfzeilen_Texte.ods")
    Dim zFileProperties() As New com.sun.star.beans.PropertyValue
        ' Datei im Hintergrund öffnen
        oDocC = StarDesktop.loadComponentFromURL(sURL, "_blank", 0, zFileProperties())
Xray oDocC

End Sub

Ich habe einen festen Dialog verwendet und auch den Dateinamen fest eingegeben und das Hidden weggelassen, es war ja sowieso nicht aktiv, dadurch fällt sehr viel im Code weg.

Das Verhalten ändert sich dadurch nicht, nach dem Xray bleibt LibO hängen; das scheint bei jeder Art von Dialog zu passieren.
_*Das Wichtige aber:*_ startet man StartKopfzeile statt über die Schaltfläche direkt aus der Basic-IDE, dann läuft das Programm durch! Das ist möglicherweise auch der Grund, warum es bei Olivers Test im Batch geklappt hat.

Ich habe dafür keine Erklärung.
Ich habe dann ein neues Writer-Dokument erzeugt, habe die Schaltfläche, den Dialog und den Makro-Code kopiert und eingefügt. Dieses Dokument liefert nun aber keinen Fehler, so dass ich annehmen möchte, dass irgend etwas im Dokument von Jürgen faul ist.

Das gleiche Vorgehen würde ich Jürgen empfehlen, ob sich jemand findet, der den wirklichen Grund rauskriegt, halte ich doch für fraglich.

Frage noch an Jürgen: Warum wird der Dialog erst zur Laufzeit erzeugt, gibt es da einen Grund in dem wahrscheinlich komplizierteren Originaldokument? Ein vorab definierter Dialog ist viel bequemer, man muss sich nicht mit den Listenern befassen.

Gruß

Gerhard

#6

Hallo Gerhard,

Frage noch an Jürgen: Warum wird der Dialog erst zur Laufzeit erzeugt,
gibt es da einen Grund in dem wahrscheinlich komplizierteren
Originaldokument? Ein vorab definierter Dialog ist viel bequemer, man
muss sich nicht mit den Listenern befassen.

Das Makro habe ich nicht für mich geschrieben, sondern für eine älteren
Herrn (>80 J.).
Es lief einwandfrei und er hatte es mehrfach in Gebrauch.
Dieser hatte schon bei diversen einfacheren Makros Probleme mit der
Verwaltung von Makros.
Eigene Biblitheken anlegen, was sind Module, etc.
Deshalb habe ich alles in einem Modul abgelegt.
Ein gezeichnetes Dialogfenster hätte für ihn alles zu sehr verkompliziert.

Nun ich hatte auch schon die Listener in Verdacht, zumal ich die
Schaltfläche
auf dem Dialog per Code geklont habe. Bevor ich das erstemal hier
gepostet habe, hatte ich den Code so umgeschrieben,
dass nur eine Schaltfläche und ein LIstener aktiv war. Aber auch hier
blieb das Programm hängen.

Viele Grüße

Jürgen

#7

Hallo Gerhard,

Ich habe dafür keine Erklärung.
Ich habe dann ein neues Writer-Dokument erzeugt, habe die
Schaltfläche, den Dialog und den Makro-Code kopiert und eingefügt.
Dieses Dokument liefert nun aber keinen Fehler, so dass ich annehmen
möchte, dass irgend etwas im Dokument von Jürgen faul ist.

Zum Dokument berichte ich wie folgt:
Das Originaldokument, des besagten Herrn, für das diese Makro konzipiert
ist, ist ein Buch mit ca. 250 Seiten.
Das Makro lief einwandfrei.
Zu Testzwecken hatte ich zuvor ein leeres Dokument mit mehr als 240
Seiten erstellt.
Auch hier gab es anfänglich keinerlei Probleme.
Erst nach besagtem LibO-Update und einem Win-Update wurde fror LibO ein.
1. Maßnahme ein gänzlich neue Dokument erstellt und den Code hineinkopiert.
Ergebnis LibO friert ein, AOO nicht.
2. LibO Benutzerverzeichnis umbenannt
Ergebnis LibO friert ein, AOO nicht.
und vieles mehr...

Bei einer meiner Tests in den letzten Tagen ist mir dieses aufgefallen:
a)  Writer mit dem Dokument öffnen
b)  Basic-IDE öffnen
c) Das Programm mit aktivierter abschließender Messagebox starten (egal
ob aus dem Dokument oder aus der IDE)
d) LibO friert ein
e) Taskmanger öffnen ( CPU-Last ca. 25% und sehr hoher Stromverbauch)
f) Im Prozesse LibO nur die Basic-IDE killen, in diesem Moment schaltet
die Ansicht im TM um auf "Warten auf Benutzer"

Dieses hat für mich den Anschein, dass LibO nicht eingefroren ist,
sondern die Messagebox den Fokus verloren hat,
aber nicht mehr mit Mausklick reaktivierbar ist.

Viele Grüße

Jürgen