Help needed with pdfroff and suppression nodes

[G. Branden Robinson]

Hi all--and especially Keith Marshall! :)

Maybe Werner or Gaius, or anyone who understands the \O suppression
escapes, could assist as well.

I just pushed the following commit--I've got a problem I'm having a
devil of a time figuring it out.

As noted below, I caused a regression a couple of days ago, but one that
was hard to see since it didn't break the build.  The table of contents
was not getting relocated in pdfmark.pdf.  The only evidence of this (if
you didn't so something crazy like view the file) was a stray line in
the build:

pdfroff-option:set toc_relocation=enabled

This is emitted by spdf.tmac, and normally, apparently, something eats
it.  So if you see it, it indicates the TOC relocation failed--at least
it did in this case.

Now that the error condition is caught and troff doesn't exit
unexpectedly, the regression is fixed.  (Should pdfroff be checking
groff's exit status?)

But the wheels turning here mystify me.  What is causing the
`image_filename` (formerly `last_image_filename`) to go uninitialized,
why only in very specific circumstances?

commit 01a65469b56f7284041365b0b179b6b4b9153b9c
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Jul 29 19:15:40 2021 +1000

    [troff]: Add sanity check to prevent SEGV.

    * src/roff/troff/node.cpp (suppress_node::tprint): If emitting
      bounding box limits for an image filename, ensure that
      `image_filename` is not a null pointer (and furthermore that it's not
      a zero-length string even if the pointer is valid).  Emit an error
      diagnostic and skip further processing of the node if they are.  This
      problem implies nonsensical input (so we should guard against it), but
      I cannot reproduce the problem _except_ with pdfroff during a build of
      the groff tree, which has been reliably failing to relocate the table
      of contents in pdfmark.pdf since commit
      e876d4bfd193abb9a7d1fb6e76519349bded482a, 27 July.  If I extract the
      groff and troff commands that pdfroff is running and execute them in
      the build directory, they complete successfully, which suggests to me
      an environment problems or a race condition.

    This commit produces nonstandard indentation in the `else` brace block;
    I did that to keep the logic and scope of the change clear.

I'm attaching a patch that gets the state of the build examinable as far
as I've been able to manage.  You can also change the `abort()` in
node.cpp to a `sleep(60)` or so to leave the process alive long enough
to attach a debugger to it.

I'd really appreciate some guidance here--I'm stumped.

Regards,
Branden

heisenbug.diff
Description: Text Data

signature.asc
Description: PGP signature