CORRECTION to my earlier report -- the proposed one-line patch was wrong, please disregard it. Apologies for the noise; sending this immediately after discovering the error rather than waiting.
What I got wrong: I incorrectly assumed each per-page PostScript line independently re-fetches the shared file reference via ".preview-ST" before its "dup". It does not -- the real mechanism relies entirely on a residual stack item carried over, uninterrupted, from one preview-do call to the next, with no name-based re-fetch in between. I verified this directly by advising process-send-string in a live Emacs session and capturing the literal byte stream sent to Ghostscript. The actual per-page lines look like this (positions descending -- see below): dup 1024 setfileposition 53()/SubFileDecode filter cvx<<>>preview-do dup 971 setfileposition 53()/SubFileDecode filter cvx<<>>preview-do ... No ".preview-ST" prefix at all. Given that, the "dup" that begins preview-gs-dsc-cvx's own output and the extra "dup " I saw prepended in preview-gs-transact are BOTH required: one to preserve a copy of the residual for the *next* call in the chain, one to consume for the *current* call's own setfileposition/SubFileDecode work. My "fix" removed the second one, which breaks this chaining after exactly one call (verified: after my patch, the real crash changes from the originally-reported "/typecheck in --setfileposition--" to a *new* "/stackunderflow in --dup--" on the second preview-do call in the batch -- confirmed both via a live Emacs session and a standalone Ghostscript reproduction using the real preview.dsc/region.pdf pulled from that same crashed session). I have reverted the patch locally. One more relevant fact I hadn't mentioned: the trace also showed the queued snippets are processed in *descending* file-position order (page 8, 7, 6, ... 1), not ascending. I don't yet know if this is significant to the original bug or incidental (it's consistent with preview-gs-queue being processed as a simple list/stack). Where this leaves the original bug report: the "/typecheck in --setfileposition--" crash on multi-snippet batches (original report, unpatched code) is REAL and still unexplained -- I have NOT been able to reproduce it in a standalone Ghostscript script, even when using the exact real preview.dsc and region.pdf recovered from a live crashed session, with the original (correct) double-dup code, in the same descending page order. That standalone reproduction succeeds cleanly every time. So something about how AUCTeX's live, long-running Ghostscript process differs from a fresh one-shot standalone gs invocation on the identical PostScript is still the open question. My current best remaining lead, untested: the preamble also redefines graphicsbeginpage inside a modified GS_PDF_ProcSet copy (to inject custom RGB color-setting during page rendering) -- I could not get that redefinition to succeed in any standalone script (it errors with "/undefined in GS_PDF_ProcSet" outside of a fully "warmed" gs PDF interpreter context), so I have not been able to test whether that redefinition, once it actually takes effect, changes dopdfpages' behavior in a way relevant to the crash. Sorry again for the incorrect patch in my previous message.
_______________________________________________ bug-auctex mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-auctex
