[tlbuild] Repeated Mac arm64 crashes of xdvi-xaw with "set_no_char: attempt to set character of unknown font, offset 42"

John Hawkinson jhawk at alum.mit.edu
Tue Jan 25 21:44:36 CET 2022


Jonathan Kew <jfkthame at gmail.com> wrote on Tue, 25 Jan 2022
at 14:09:49 EST in <8d02d6eb-2968-45f2-5f74-e729df82205c at gmail.com>:

> On 25/01/2022 14:07, Richard Koch wrote:

> > I'm beginning to understand John's frustration. When I reported
...

For what it's worth, I feel like Dick's bug is a different one, and at any rate a trickier one, at least because it's with a complicated document without quite as clear a reproduction case. Although I think we're still waiting for his .dvi file?


One thing I noticed today is when I compared xdvi -debug -1 on the working machine versus the old x86_64 Mac with TL2015, the latter did not appear to restart ghostscript when shift-R is pressed. I wonder if this is related to the problem.

> I've only been skimming this discussion, but it sounds to me like there's
> likely an inadvertent use of an uninitialized (or already-freed) value
> somewhere, such that the behavior ends up depending on the random contents
> of some bit of memory.

Yes, that's a big fear.

> Which leads me to wonder, can you build with the various clang "sanitizer"
> tools like ASAN and UBSAN to see if they flag any runtime errors? Or even
> try running under valgrind (although in my experience that can be painfully
> slow)?

I don't have any experience with these tools, but this sounds promising. I had briefly tried setting MallocGuardEdges=1 and MallocScribble=1 which enable some special features in Apple's stock malloc, but they didn't find anything.

Given that the xdvi crashes in the first few milliseconds (or at least as soon as you hit the keystroke), I hope speed won't be an issue.

Unfortunately, it appears valgrind doesn't yet support arm64 Macs:

jhawk at loud-room valgrind-3.18.1 % ./configure
...
checking build system type... arm-apple-darwin21.2.0
checking host system type... arm-apple-darwin21.2.0
checking for a supported CPU... no (arm)
configure: error: Unsupported host architecture. Sorry

The HEAD of the git repository gets a teeny little bit further:

...
checking build system type... aarch64-apple-darwin21.2.0
checking host system type... aarch64-apple-darwin21.2.0
checking for a supported CPU... ok (aarch64)
checking for a 64-bit only build... no
checking for a 32-bit only build... no
checking for a supported OS... ok (darwin21.2.0)
checking for the kernel version... unsupported (21.2.0)
configure: error: Valgrind works on Darwin 10.x, 11.x, 12.x, 13.x, 14.x, 15.x, 16.x and 17.x (Mac OS X 10.6/7/8/9/10/11 and macOS 10.12/13)

so maybe there's hope although it looks like a long slog. (That seems strange to not support MacOS later than 10.13; given that we're up to MacOS 12.1 (Darwin 21.2) and MacOS 10.13 (High Sierra) was released in 2017.

Does somebody running x86_64 linux (or anything, really) want to give valgrind a shot on xdvi with t2a.dvi file? It's quite plausible that valgrind will catch a problem on an architecture that doesn't happen to crash.

--
jhawk at alum.mit.edu
John Hawkinson


More information about the tlbuild mailing list.