URL: <https://savannah.gnu.org/bugs/?68552>
Summary: [not our problem?] null pointer dereference in
`write_any_trailer_and_exit()` using Clang on Termux
Group: GNU roff
Submitter: gbranden
Submitted: Fri 24 Jul 2026 12:15:39 AM UTC
Category: None
Severity: 2 - Minor
Item Group: Crash/Unresponsive
Status: Need Info
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Unlocked
Planned Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Fri 24 Jul 2026 12:15:39 AM UTC By: G. Branden Robinson <gbranden>
Here's a weird one.
I was researching the divergent behaviors of various troffs' `rr` and `rm`
request handlers (documentary detail forthcoming in my next push), when to my
immense surprise I provoked a GNU _troff_ SEGV on my tablet running Termux.
Looking cursorily at the backtrace, I raced to the first function of ours in
the call stack, `write_any_trailer_and_exit()`.
The problem was "address not mapped to object". If I'd bothered to read past
that, I'd have noticed that the address was not zero.
Panicked over a crasher that seemed new and that threatened my release
schedule for 1.25.0 and my dignity as a release manager,[1] I saw that
`topdiv`, a pointer, was followed without a null pointer check.
Hurriedly fixing that, I rushed the fix back to the Termux device and tried
again.
No change.
I then spent more time investigating.
The "address not mapped to object" corresponds to the standard C library
function _exit_(3), and there is an actual address there.
No clue how that went wrong. It seems virtually impossible that it's our
fault.
_Maybe_ Gnulib's, if Gnulib replaces `exit()`. If not, then it's gotta be
LLVM's fault. Or the Termux guys hosed something.
Baffled, for now I'm logging this as crasher bug of minor severity(!) because
evidence suggests that it's not really our bug at all.
Barring further data, I'm ignoring this for the 1.25.0 release cycle. I'm
planning to add unit tests for the `rr` and `rm` requests in my local
checkout's post-1.25 branch, and expect to land those back on the master
branch after release. They should provoke the problem on any platform that
has it. You have to invoke these macros with an invalid argument.[2] But on
a GNU/Linux system using a GCC _or_ Clang-compiled GNU troff, the problem does
*not* manifest!
Weird stuff. Anyone who wants to help root-cause this will have even more of
my gratitude than usual!
[1] I begin to think that there _is_ no dignity in release management--just
Toynbee's "one damned thing after another".
[2] Example:
$ printf '.rr \\a\n' | ./build/test-groff
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68552>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
