Liebe Kollegen,

immer wieder beobachte ich, dass InDesign beim Versuch, alle offenen Dokumente ohne Rückfrage und ohne speichern zu schließen, hängen bleibt bzw. abstürzt und mit dem Taskmanager abgeschossen werden muß.

Vereinfacht etwa mit folgendem Einzeiler:

Code

app.documents.everyItem().close(SaveOptions.NO); 

Eine Strategie, dem entgegenzuwirken, bestand für mich darin, nicht alle offenen Dokumente (z.B. 40 Stück) auf einmal zu schließen, sondern häppchenweise in 10er-Schritten.
Das ist schon wesentlich sicherer, aber es kommt schon auch mal vor, dass InDesign damit auch bei nur 8 offenen (ungesicherten) Dokumenten abstürzt.

Kann dieses Verhalten jemand bestätigen?
Mit welchen Strategien könnte man dem entgegenwirken?

Moin,

ich benutze eine Schleife statt app.documents.everyItem() und hatte bisher noch nie ein Problem damit.

Hallo Herr Perplies,

Dank für die Rückmeldung.

Ja, auch ich verwende eine Schleife.

Aber beim Kunden funktioniert das auf allen Arbeitsstationen nicht (mehr).

Das Problem taucht sehr massiv seit einem Wechsel jüngst von CC2021 auf CC2023 (Win) auf und die Benutzerinnen sind total frustriert.

Auch mit $.sleep() innerhalb der Schleife nach dem Schließen eines Dokuments ist dem nicht beizukommen.

Unter CC2021 konnten wir noch über die Häppchenstrategie eine Stabilität finden.

Es handelt sich um temporär, nur für einen oder mehrere PDF-Exporte generierte Dokumente.
Aber selbst eine Zwischensicherung in einem temporären Ordner bringt keine Lösung.

Auch ich beobachte seit InDesign 2023, dass das Programm offenbar ein massives Problem mit dem Speichermanagement hat.

Okay, darin war InDesign ja noch nie wirklich gut, vor allem nicht seit den 64-bit-Versionen, insbesondere etwa im Wieder-Freigeben von Speicher, aber seit 2023 ist es "klinisch" im Sinne von: Bei bis dato zuverlässig funktionierenden Tasks wie massenhaftem Exportieren von offenen Dateien als PDF oder deren Schließen ohne Speichern stürzt InDesign nicht nachvollziehbar immer wieder ab.

Dies sind alles empirische Befunde - ohne eine Debug-Version von InDesign wird man da nicht weiterkommen.

Beiträge wie "bei mir tut's immer" oder gar "nimm einen MAC" sind nicht hilfreich und können gerne weggelassen werden. Es wurden bereits -zig Arbeitsstunden auf Analyse und systematische Fehlersuche verwendet.

Liest hier ein/e Entwickler/in mit, die/der über eine solche Debug-Version verfügt, und hierzu etwas Sachdienliches beitragen kann?

Und: Hat irgendjemand einen entsprechenden _sinnvollen_ Kontakt zu Adobe (damit meine ich: nicht ins indische Nirwana), über den man dies eskalieren könnte?

Hallo Rudix,

hier liest mit höchster Wahrscheinlichkeit kein Adobe-Mitarbeiter mit. Auch in den Adobe-Foren ist es nicht garantiert.

Die zuverlässigste Art und Weise Fehler zu melden ist folgende Adresse:

https://indesign.uservoice.com

Wenn andere Anwender auch dasselbe Problem haben, je mehr desto besser, wird dem Problem nachgegangen.

""Beiträge wie "bei mir tut's immer" oder gar "nimm einen MAC" sind nicht hilfreich und können gerne weggelassen werden. Es wurden bereits -zig Arbeitsstunden auf Analyse und systematische Fehlersuche verwendet.""

(Ich kann hier zur Zeit in dem Editor keinerlei Auszeichnungen vornehmen)

Nimm einen Mac ist natürlich nicht hilfreich, aber „bei mir funktioniert es“ kann schon hilfreich sein, weil das Problem dann evtl. an der Hardware (z.B. Grafikkarte), Systemversion sowie installierten Hilfsprogrammen (z.B. Virenscanner) oder in InDesign installierte PlugIns liegen kann.

Viele Grüße Peter

Moin Rudix,

was willst Du denn mit einer Debug-Version erreichen?

Alle Informationen zum aufgetretenen Fehler findest Du doch im Fehlerbericht an Adobe.

Mehr liefert Dir die Debug-Version auch nicht, oder übersehe ich da etwas?

Nun, da InDesign in unserem Szenario i.d.R. einfach einfriert und es daher gar keinen Fehlerbericht gibt, scheidet diese Möglichkeit schonmal aus - zumal ich mir nicht sicher bin, ob aus dem Fehlerbericht tiefere Erkenntnisse gewonnen werden könnten - nach meiner Kenntnis reflektiert er schlicht den Status Quo zum Zeitpunkt des Absturzes, aber nicht die Entwicklung dorthin.

Ich würde mir von der Debug-Version die Erkenntnis erhoffen, welche Ereignisse "hinter den Kulissen" zu diesem Einfrieren führen.

Wie gesagt: Hier müssen wir die sachkundige Auskunft einer/s Entwickler/in abwarten, die/der sich a) hinter den Kulissen und b) demnach auch mit der Debug-Version auskennt und deren Informationen auszuwerten weiß.

Moin,

ich arbeite im Moment meistens am Mac und habe im Moment nicht die Zeit den Ablauf unter Windows zu überprüfen, der in etwa so abläuft:

1. InDesign hängt
2. Abbruch über das Betriebssystem (Programm beenden/Task-Manager)
3. nach kurzer Zeit kommen am Mac zwei Dialogfenster:
3.1 Meldung und Bericht an Apple
3.2 Meldung und Bericht an Adobe

Die enthaltenen Fehlerberichte, sind, soweit ich das beurteilen kann, im wahrsten Sinne des Wortes, erschöpfend!

Aber wie willst Du, und das gilt auch für Debug-Versionen, ohne zugehörige Sourcen, daraus brauchbare Informationen bekommen.

Probiere es einfach mal aus.

Werner:
> Mehr liefert Dir die Debug-Version auch nicht, oder übersehe ich da etwas?

Die Debug Version kann Unmengen von Protokollen ausgeben, damit lässt sich ggf. verfolgen was kurz vorher stattgefunden hat. Dazu noch Statistiken zum Speicherverbrauch. Man kann manche Extremsituationen gezielter auslösen (Sonderaktionen bei Speichermangel) usw.
Zum Vergleich - ich verwende eher ähnliche Ausgaben von einem eigenen Plugin, da kommen selbst bei kleinen Dokumenten locker Millionen Zeilen zusammen. Man muss also wissen wo man hinsehen will, und sich dem Problem ggf. programmierend nähern.

Ausserdem ist die Debug Version gespickt mit Abfragen für unwahrscheinliche Fehler (ASSERT) die nur bei fehlerhafter/unvollständiger Programmierung auftreten sollten. In der Release Version werden diese Abfragen ignoriert.
Der Programmcode ist weniger optimiert, dadurch besser auf Assembler Ebene lesbar - wenn man das kann.

Für manche* Debug und Release Versionen gibt es zusätzlich noch Symboldateien, damit bekommen die Aufrufketten (Stack) die Funktionsnamen zugeordnet, und man kann mit Glück sogar lokale Variable identifizieren. So lassen sich auch die Absturzberichte ähnlich aufarbeiten, aber der Blick im Debugger auf das noch nicht beendete Programm ist deutlich aufschlussreicher.
Beides klappt besser in der Debugversion weil weniger optimiert.
* Manche – bei der Flut von sukzessiven Versionen werden nicht jedes Mal die 4 GByte komprimierte Downloads bereitgestellt, aber so 2-3 mal im Jahr ...

Zum eigentlichen Problem:
Das Schliessen eines Dokuments ist ein Sonderfall, da wird ja nicht nur die Datei geschlossen, sondern alle Änderungen abgeschlossen, bzw. (bei SaveOptions.NO) zurückgenommen. Und danach geht der Spass erst los, da alle Strukturen im Speicher einzeln freigegeben werden, und Inkonsistenzen, die beim offenen Dokument nicht stören, gerade da erst zum Tragen kommen. Vielleicht hat man ja einen Treffer mit einem der Asserts …

Martin:
> $.sleep()
Das ist ein "busy-wait". Da dreht die CPU nur nutzlos ihre Schleifen. Wenn man dem Programm für Hintergrund-Arbeiten Zeit lassen will, wäre ein IdleTask die Wahl.

CC2021 => 2023
Welche 2023 denn? Mit 18.4 und 18.5 ist halt viel UXP neu dazugekommen. Kann aber genauso irgendwas mit Fonts sein, oder etwa neuen Grafiktreibern.

> eskalieren vs. indisches Nirwana
Gearbeitet wird halt in Indien, mit begrenzten Resourcen.
Und man hat bessere Chancen mit sauber eingegrenzten, neuen Bugs "Regression" solange der Programmierer sich noch an die Details erinnert.
Ansonsten ist Uservoice der richtige Weg - gibt es schon einen entsprechenden Eintrag?

> "nimm einen MAC" sind nicht hilfreich / "-zig Arbeitsstunden"
Ja, das ist ein Problem. Um eine ideale Arbeitsumgebung zusammenzustellen muss man exakt die richtige Betriebssystemversion ansteuern (mit passender Hardware), damit der zur Adobe Version passende Compiler überhaupt installiert werden kann. Diverse Nacharbeiten "Portierung", was oben geschildert wurde läuft auch nicht auf Knopfdruck. Das geht über mehrere Wochen, bevor man sich um die eigentlichen Änderungen kümmern kann. Da konzentriert man sich gerne auf die bequemere und günstigere Platform.

Moin Dirk,

danke für Deine ausführlichen Erläuterungen, die nähren aber meine Zweifel, ob ein Außenstehender damit etwas anfangen kann.

Doch zurück zum Ausgangsproblem.

Herr Fischer,

versuchen Sie doch einmal jede Datei vor den Schließen einmal mit "Sichern unter " zu speichern, dann die Datei zu schließen und anschließend die erzeugte Datei zu löschen.

Dauert natürlich viel länger, aber es wäre aus meiner Sicht einen Versuch wert.

@ Dirk
Auch von mir ein Dank für diese Ausführungen.
Allerdings verstehe ich bereits bei einem normalen Absturzbericht nur Bahnhof.

Mit dem $.sleep() hoffte ich, der Speicherfreigabe etwas Luft zu verschaffen. Aber vermutlich stehen damit lediglich kurz alle Räder still, ohne dass in diesem Moment irgendwas passieren kann.

By the way: Was könnte eine gute Anwendung von $.sleep() sein?

Mit IdleTasks habe ich noch nicht gearbeitet.


@ Herr Perplies
Das scheint mir ein vielversprechendes »Nickerchen« bzw. Intermezzo zwischen zwei Dateischließungen zu sein.
Das will ich gerne mal ausprobieren.

Vielen Dank für den Tipp!

Antwort auf:

By the way: Was könnte eine gute Anwendung von $.sleep() sein?

Wenn andere Prozesse parallel werkeln, könnte das ein probates Mittel sein, diese fertig werden zu lasse, bevors im vordergründigen Prozess weitergehen kann. (z.B. dem Spotlight Daemon 'mdutil' die Chance zu geben, eine soeben gespeicherte Datei in den Index aufzunehmen).

Hallo zusammen,

falls das im gegebenen Workflow machbar ist, würde ich vorschlagen:

Immer nur eine Datei öffnen, das Skript arbeiten lassen, dann die Datei wieder schließen (ohne zu speichern).
Damit bin ich immer bestens gefahren.

Habe diese Woche in einer Schleife mit 35 InDesign-Dateien eines Verzeichnisses und InDesign 2023 Version 18.5.1.79 auf einem iMac von 2017 unter macOS 12.7.2 (32 GB Arbeitsspeicher) mehrfach praktiziert: PDF-Export und Dateien verpacken. Die InDesign-Daten und die verknüpften Bilder liegen auf einem Server im lokalen Netzwerk. Das Server-Volume ist per SMB verbunden.

Hallo Uwe,
vielen Dank - leider nicht; die Anwenderschaft möchte alle Dateien gleichzeitig offen haben, bearbeitet bekommen (per Skript) und danach ausdrücklich offen halten, um evtl. diese nochmals bearbeitet zu bekommen. Erst danach sollen alle (auf einmal) geschlossen werden.

Hallo Uwe,

ja, so würde ich normalerweise auch vorgehen.

Aber in diesem Workflow ist das leider nicht möglich.

Die Benutzerinnen müssen/wollen eine größere Zahl an namenlosen aus INDT erzeugten Dateien offenhalten und parallel bearbeiten/verändern und nach jedem manuell in die Wege geleiteten Änderungsdurchgang (Katalogpreisbestückung) von allen Dokumenten eine PDF-Datei schreiben und nach mehreren Durchgängen alle Dokumente verlustig (ohne zu speichern) beenden.

Habe die Idee von H. Perplies mit dem temporären Zwischenspeichern aufgegriffen, umgesetzt und bislang nichts gehört, was ich als Bestätigung des Gelingens interpetiere.


Das temporäre Zwischenspeichern vor den PDF-Exporten war dort hilfreich (ohne dieses Zwischenspeichern wurden ohne erkennbare Regel mitunter 0 KB PDFs erzeugt), aber nicht mehr beim Schließen aller offenen Dokumente.