[bug #68552] [not our problem?] null pointer dereference in `write_any_trailer_and_exit()` using Clang on Termux

--8323329-1714636915-1784852144=:3051184
Content-Type: TEXT/plain; CHARSET=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: inline

URL:=0A  <https://savannah.gnu.org/bugs/?68552>=0A=0A                 Summa=
ry: [not our problem?] null pointer dereference in=0A`write_any_trailer_and=
_exit()` using Clang on Termux=0A                   Group: GNU roff=0A     =
          Submitter: gbranden=0A               Submitted: Fri 24 Jul 2026 1=
2:15:39 AM UTC=0A                Category: None=0A                Severity:=
 2 - Minor=0A              Item Group: Crash/Unresponsive=0A               =
   Status: Need Info=0A                 Privacy: Public=0A             Assi=
gned to: None=0A             Open/Closed: Open=0A         Discussion Lock: =
Unlocked=0A         Planned Release: None=0A=0A=0A    _____________________=
__________________________________=0A=0AFollow-up Comments:=0A=0A=0A-------=
------------------------------------------------=0ADate: Fri 24 Jul 2026 12=
:15:39 AM UTC By: G. Branden Robinson <gbranden>=0AHere's a weird one.=0A=
=0AI was researching the divergent behaviors of various troffs' `rr` and `r=
m`=0Arequest handlers (documentary detail forthcoming in my next push), whe=
n to my=0Aimmense surprise I provoked a GNU _troff_ SEGV on my tablet runni=
ng Termux.=0A=0ALooking cursorily at the backtrace, I raced to the first fu=
nction of ours in=0Athe call stack, `write_any_trailer_and_exit()`.=0A=0ATh=
e problem was "address not mapped to object".  If I'd bothered to read past=
=0Athat, I'd have noticed that the address was not zero.=0A=0APanicked over=
 a crasher that seemed new and that threatened my release=0Aschedule for 1.=
25.0 and my dignity as a release manager,[1] I saw that=0A`topdiv`, a point=
er, was followed without a null pointer check.=0A=0AHurriedly fixing that, =
I rushed the fix back to the Termux device and tried=0Aagain.=0A=0ANo chang=
e.=0A=0AI then spent more time investigating.=0A=0AThe "address not mapped =
to object" corresponds to the standard C library=0Afunction _exit_(3), and =
there is an actual address there.=0A=0ANo clue how that went wrong.  It see=
ms virtually impossible that it's our=0Afault.=0A=0A_Maybe_ Gnulib's, if Gn=
ulib replaces `exit()`.  If not, then it's gotta be=0ALLVM's fault.  Or the=
 Termux guys hosed something.=0A=0ABaffled, for now I'm logging this as cra=
sher bug of minor severity(!) because=0Aevidence suggests that it's not rea=
lly our bug at all.=0A=0ABarring further data, I'm ignoring this for the 1.=
25.0 release cycle.  I'm=0Aplanning to add unit tests for the `rr` and `rm`=
 requests in my local=0Acheckout's post-1.25 branch, and expect to land tho=
se back on the master=0Abranch after release.  They should provoke the prob=
lem on any platform that=0Ahas it.  You have to invoke these macros with an=
 invalid argument.[2]  But on=0Aa GNU/Linux system using a GCC _or_ Clang-c=
ompiled GNU troff, the problem does=0A*not* manifest!=0A=0AWeird stuff.  An=
yone who wants to help root-cause this will have even more of=0Amy gratitud=
e than usual!=0A=0A[1] I begin to think that there _is_ no dignity in relea=
se management--just=0AToynbee's "one damned thing after another".=0A=0A[2] =
Example:=0A=0A=0A$ printf '.rr \\a\n' | ./build/test-groff=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=0A    _______________________________________________________=
=0A=0AReply to this item at:=0A=0A  <https://savannah.gnu.org/bugs/?68552>=
=0A=0A_______________________________________________=0AMessage sent via Sa=
vannah=0Ahttps://savannah.gnu.org/=0A
--8323329-1714636915-1784852144=:3051184
Content-Type: APPLICATION/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCamKusAAKCRCqLAuaBUf3
TglkAP9sZL2JFXsQVV4KHjInUn2iixinPTrlm2j6ZU7hg1RKZQD/akikik0ojcrK
ra6PeVldfjF5gZp8mOmYiItAgfI13QU=
=vlCJ
-----END PGP SIGNATURE-----

--8323329-1714636915-1784852144=:3051184--