Mustang-Absturz mit Windows-Java unter Wine auf Linux

[Matthias Hanft]

Hallo,

ich habe ein ungewöhnliches und seltsames Problem, aber vielleicht hat
ja trotzdem jemand einen Tipp:

Ich verwende Mustang-CLI aus einem Windows-Programm heraus. Dazu rufe
ich aus dem Windows-Programm heraus (mit CreateProcess) "java.exe -jar
Mustang..." auf (mit Java aus dem OpenJDK-Paket). Das klappt auch ganz
wunderbar.

Nun hätte ich allerdings gerne, dass mein Windows-Programm (im Prinzip
ohne Änderungen) auch unter Wine auf Linux läuft. Das tut es im großen
und ganzen auch (sogar das Windows-Java und Windows-Ghostscript laufen
unter Wine), und auch "mustang validate" und "mustang extract" funktio-
nieren damit.

Nur "mustang combine" nicht :-(

Da wird ein 753 Zeilen langer Absturzbericht erzeugt, aus dem ich hier
mal die wesentlichen Zeilen poste:

--- schnipp ---

# A fatal error has been detected by the Java Runtime Environment:
# Internal Error (0xc06d007f), pid=508, tid=524
# JRE version: OpenJDK Runtime Environment (22.0.1+8) (build 22.0.1+8-16)
# Java VM: OpenJDK 64-Bit Server VM (22.0.1+8-16, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C [kernelbase.dll+0x13c47]
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
--------------- T H R E A D ---------------
Current thread (0x00007fffff1347c0): JavaThread "main" [_thread_in_native, id=524, stack(0x00007fffff440000,0x00007fffff540000) (1024K)]
Stack: [0x00007fffff440000,0x00007fffff540000], sp=0x00007fffff53dca0, free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [kernelbase.dll+0x13c47] (no source info available)
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.net.NetworkInterface.getAll()[Ljava/net/NetworkInterface;+0 java...@22.0.1
j java.net.NetworkInterface.getNetworkInterfaces()Ljava/util/Enumeration;+0 java...@22.0.1
j sun.security.provider.SeedGenerator.addNetworkAdapterInfo(Ljava/security/MessageDigest;)V+0 java...@22.0.1
j sun.security.provider.SeedGenerator$1.run()Ljava/lang/Void;+66 java...@22.0.1
j sun.security.provider.SeedGenerator$1.run()Ljava/lang/Object;+1 java...@22.0.1
J 979 c1 java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object; java...@22.0.1 (9 bytes) @ 0x000071dbb0b856ec [0x000071dbb0b85580+0x000000000000016c]
j sun.security.provider.SeedGenerator.getSystemEntropy()[B+40 java...@22.0.1
j sun.security.provider.AbstractDrbg$SeederHolder.<clinit>()V+28 java...@22.0.1
v ~StubRoutines::call_stub 0x000071dbb7f3100d
j sun.security.provider.AbstractDrbg.getEntropyInput(IIIZ)[B+87 java...@22.0.1
j sun.security.provider.AbstractDrbg.getEntropyInput(Z)[B+14 java...@22.0.1
j sun.security.provider.AbstractDrbg.instantiateIfNecessary([B)V+16 java...@22.0.1
j sun.security.provider.AbstractDrbg.engineNextBytes([BLjava/security/SecureRandomParameters;)V+157 java...@22.0.1
j sun.security.provider.AbstractDrbg.engineNextBytes([B)V+11 java...@22.0.1
j sun.security.provider.DRBG.engineNextBytes([B)V+5 java...@22.0.1
j java.security.SecureRandom.nextBytes([B)V+17 java...@22.0.1
j java.security.SecureRandom.next(I)I+17 java...@22.0.1
j java.util.Random.nextLong()J+3 java...@22.0.1
j java.io.File$TempDirectory.generateFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/File;)Ljava/io/File;+3 java...@22.0.1
j java.io.File.createTempFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/File;)Ljava/io/File;+70 java...@22.0.1
j java.io.File.createTempFile(Ljava/lang/String;Ljava/lang/String;)Ljava/io/File;+3 java...@22.0.1
j org.mustangproject.ZUGFeRD.PreflightParserHelper.createTmpFile(Ljava/io/InputStream;)Ljava/io/File;+6
j org.mustangproject.ZUGFeRD.PreflightParserHelper.createPreflightParser(Ljakarta/activation/DataSource;)Lorg/apache/pdfbox/preflight/parser/PreflightParser;+10
j org.mustangproject.ZUGFeRD.ZUGFeRDExporterFromA1.isValidA1(Ljakarta/activation/DataSource;)Z+1
j org.mustangproject.ZUGFeRD.ZUGFeRDExporterFromA1.ensurePDFIsValid(Ljakarta/activation/DataSource;)Z+8
j org.mustangproject.ZUGFeRD.ZUGFeRDExporterFromA3.load(Ljava/lang/String;)Lorg/mustangproject/ZUGFeRD/ZUGFeRDExporterFromA3;+9
j org.mustangproject.ZUGFeRD.ZUGFeRDExporterFromA1.load(Ljava/lang/String;)Lorg/mustangproject/ZUGFeRD/ZUGFeRDExporterFromA1;+2
j org.mustangproject.ZUGFeRD.ZUGFeRDExporterFromA1.load(Ljava/lang/String;)Lorg/mustangproject/ZUGFeRD/IZUGFeRDExporter;+2
j org.mustangproject.ZUGFeRD.ZUGFeRDExporterFromPDFA.load(Ljava/lang/String;)Lorg/mustangproject/ZUGFeRD/IZUGFeRDExporter;+18
j
org.mustangproject.commandline.Main.performCombine(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/Boolean;[Ljava/lang/String;Ljava/util/ArrayList;Ljava/lang/Boolean;)V+1144
j org.mustangproject.commandline.Main.main([Ljava/lang/String;)V+758
v ~StubRoutines::call_stub 0x000071dbb7f3100d
siginfo: EXCEPTION_?? (0xc06d007f), ExceptionInformation=0x00007fffff53dd90

--- schnapp ---

Mir (als absolutem Java-Laien) sagt das alles nix. Und nachdem ich das
fertige .jar verwende, kann ich ja auch nix dran ändern - vermutlich
könnte ich lediglich irgendwelche Java-Einstellungen modifizieren (mehr
Stack oder so).

Alternativ könnte ich auch aus einem Windows-Wine-Programm heraus sogar
das originale Linux-Java aufrufen (mit "start /unix /bin/bash -c /usr/bin/java
-jar Mustang..." oder so), aber das zieht wieder einen ganzen Rattenschwanz
nach sich (Windows-Dateinamen in Linux-Dateinamen umwandeln, WaitForSingleObject
geht nicht, Returncode kriegt man nicht, und Stdout-/Stderr-Redirection
ist furchtbar komplex und derlei mehr). Würde wohl im Prinzip funktionieren,
aber nicht besonders gut und auch nicht besonders stabil (und alles nur
wegen "combine" - alles andere geht ja).

Hm. Jetzt weiß ich nicht so recht, ob ich mir die Mühe machen soll, oder
akzeptieren "Combine geht unter Wine nicht" (und vielleicht auf ein
Mustang 3.0 hoffen, wo es funktioniert)?

Oder übersehe ich was? Danke schon mal für alle Tipps,

Gruß Matthias.

[jochen...@gmail.com]

Hi,

Das sieht für mich nach einem Problem mit der JRE aus, da kann ich leider nicht helfen, sorry, der Gedanke unter Linux ein Linux-Java zu verwenden erscheint mir naheliegender.

ciao

Jochen

[Matthias Hanft]

jochen...@gmail.com schrieb:

> Das sieht für mich nach einem Problem mit der JRE aus, da kann ich leider nicht helfen, sorry, der Gedanke unter Linux ein Linux-Java zu verwenden erscheint mir naheliegender.

Ja, das ist mir inzwischen auch gelungen. Es gibt dort lediglich das
Problem, dass Wine nach dem Start eines Linux-Prozesses die Kontrolle
darüber verliert, d.h. WaitForSingleObject kehrt sofort (erfolgreich)
zurück. Ich muss aber warten, bis Mustang fertig ist. Als Notbehelf
habe ich mir dafür ausgedacht "ich warte, bis N Sekunden lang nix mehr
nach stdout geschrieben wird, dann wird's schon fertig sein". Ist zwar
nicht so ganz sauber, funktioniert aber (und N muss man halt je nach
Rechnergeschwindigkeit justieren). Evtl. könnte man dauernd sowas wie
"start /unix /usr/bin/ps" aufrufen und in stdout nach "java" suchen
oder so, aber das wäre ja auch recht umständlich...

Apropos stdout/stderr: Ich bin da nicht ganz sicher, was den Exit Code
anbelangt (betrifft auch natives Windows): Wenn "validate" das Ergebnis
"invalid" hat, kriege ich den Exit Code -1 (oder so, jedenfalls nicht 0).

Wenn bei "extract" aber gar kein XML im PDF gefunden wird, kriege ich
Exit Code 0 (also eigentlich ja "Ok"), und lediglich in stderr steht
"NO ZUGFERD XML FOUND IN PDF FILE". Oder bei "combine", wenn das PDF
nicht /A-1 ist, auch wieder Exit Code 0 und nur in stderr "PDF-A VERSION
NOT SUPPORTED". Das betrifft auch manch andere Funktionen, so dass ich
(neben den obigen beiden Fällen) inzwischen dazu übergegangen bin, stderr
nach dem Wort "ERROR" zu durchsuchen (auch wenn der Exit Code anscheinend
0 ist).

Verliere ich da irgendwo unterwegs den Exit Code, oder kann es sein,
dass der auch bei diversen Fehlern 0 ist? Wie lässt sich ein Fehler
dann am besten erkennen? Dass irgendwo "ERROR" in stderr steht? Oder
dass überhaupt irgendwas in stderr steht (wobei man [warn] und [info]
dann wohl ignorieren müsste)?

Danke & Guten Rutsch,

Gruß Matthias.

[jochen...@gmail.com]

Hallo,

der Exit Code ist für Dinge wie ein Gitlab Runner oder eine Github Action gedacht, der funktioniert wahrscheinlich nur bei validate (gerne PR) und 0 bedeutet gültiges dokument, i.e. summary valid, alles andere ungültig oder Fehler. Ich glaube außer 0 gebe ich nur 1 oder -1 zurück, mehr Bedeutung ist auf der ebene ja nicht definiert und details stehen ja in stdout/stderr.