Update of bug #64421 (project groff):
Category: Macro mom => Core
Severity: 3 - Normal => 4 - Important
Status: Unreproducible => In Progress
Assigned to: PTPi => gbranden
_______________________________________________________
Follow-up Comment #20:
That's some good sleuthing, Deri.
> So I suspect the different memory layout in the arch linux version is
exposing a wayward pointer memory corruption in troff, since I can't see any
patches in the git arch use which would cause this result.
I think you're right. I had though the issue was the position-independent
executable ("pie") property of the object, but my builds works fine and they
have that as well.
I unfortunately cannot run Arch's "bad troff" at all. There is an ABI change.
But that further reinforces your conjecture.
$ file troff.*
troff.bad: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=3edc265872c007e94d3ab3ac40526e894fe2cb9d, for GNU/Linux 4.4.0,
stripped
troff.good: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=c470f808a9aa475150d7411d2de7be7c48fc375d, for GNU/Linux 3.2.0,
stripped
troff.mine: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=2cc3b74a8768f3ceacad57abed700a3bf6a4fcfa, for GNU/Linux 3.2.0,
with debug_info, not stripped
$ ./troff.bad
./troff.bad: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30'
not found (required by ./troff.bad)
./troff.bad: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
(required by ./troff.bad)
The really crappy thing here is that this buffer read is not causing a crash,
just bad behavior.
But it's starting to smell to me a lot like bug #62813, where a really similar
problem occurred with a static buffer used for writing out diagnostic
messages. No out-of-bounds read or write ever occurred, just negligence to
properly clear a buffer that was being re-used.
This has simply *got* to be a formatter problem. Updating item group and
adopting item to chew on it for a bit. Can't promise I'll find the problem.
Kicking up to important because improper handling of memory is offensive to
me; also I can't see how this sort of thing can be worked around reliably,
just by stochastic measures.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64421>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
