Thanks for looking into this, Arash. I ran exactly the test you described:
emacs -Q & and in the scratch buffer: (progn (package-initialize t) (package-activate 'auctex) (setq preview-pdf-color-adjust-method 'compatible) (setq preview-auto-cache-preamble nil)) then opened the same 8-equation repro.tex from my original report and ran C-c C-p C-b. Result: I cannot reproduce the crash either, under these exact conditions. All 8 equations previewed successfully -- Ghostscript produced all 8 output images (pr1-1.png through pr1-8.png) with no /typecheck or any other error, and the Ghostscript process exited cleanly. I repeated this several times (fresh `emacs -Q` each time) and got the same clean result every time. Versions are unchanged from my original report: AUCTeX 14.1.2, Emacs 29.3, Ghostscript 10.02.1, Ubuntu 24.04.4. I then also tried it in my actual day-to-day Emacs session instead of a fresh `emacs -Q` -- long-running, dark theme (gruvbox-dark-soft), AUCTeX/LSP/company etc. all already loaded -- to test the "warmed session" hypothesis below. Same result: no crash there either, with either 'compatible or the default t. So where that leaves things: both of us now fail to reproduce the crash from a fresh `emacs -Q` session with the minimal 8-equation file, even though the crash was very much real and repeatable in my original (non-`-Q`) session. That's consistent with what I flagged in my "CORRECTION" follow-up -- I was also unable to reproduce it in a standalone Ghostscript script using the real recovered preview.dsc/ region.pdf from a crashed session, even with the exact byte-for-byte PostScript that crashed live. So the trigger doesn't seem to be the minimal repro file or these two settings in isolation; something about the state of a longer-running AUCTeX/Ghostscript session (repeated previewing, a warmed persistent Ghostscript process via preview-gs-outstanding/preview-gs-queue, or something in the full ~30-page real document that the 8-equation file doesn't capture) is a necessary ingredient. Separately, while testing in my real dark-theme session I got a concrete data point on the "Related observation" I mentioned in my original report (previews being illegible against a non-default theme). With `preview-pdf-color-adjust-method' set to t (the default, and the documented correct choice for gs > 9.27), the generated PNGs are still plain black text on a plain white background -- I checked the raw pixel data (identify/convert histogram: dominant color #FFFFFF, text #000000) and confirmed visually with a screenshot of the buffer. This is despite Emacs correctly reporting my theme's colors (foreground #ebdbb2, background #32302f via face-attribute on `default'). So on Ghostscript 10.02.1, the DELAYBIND-based `/initgraphics' patch in `preview-pdf-color-string' silently has no effect at all -- not "wrong colors", just no color transfer whatsoever, for either t or 'compatible. That lines up with the comment already in preview.el next to that code, flagging DELAYBIND as a Ghostscript feature that might get removed in future versions (associated with past security holes) -- 10.02.1 looks like it may be past that point. Worth noting this only ever patches the foreground (text) color in that code path regardless; there's no separate mechanism patching a background to match the theme. This is really a separate defect from the /typecheck crash this report is about, so let me know if you'd rather I file it as its own bug report instead of carrying it in this thread. If it's useful, I can try to reproduce the crash again by (a) previewing the same buffer multiple times in one session rather than once from a fresh start, and/or (b) using the real ~30-page document instead of the minimal repro, and report back. Let me know which you'd find more useful, or if you'd like me to try something else specific. Best, Mauricio
_______________________________________________ bug-auctex mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-auctex
