[bug #64421] [mom] the word "black" spuriously appears in output

[G. Branden Robinson]

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/