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

[Jonathan Kew]

On 25/01/2022 14:07, Richard Koch wrote:
> Karl,
> 
>> On Jan 24, 2022, at 6:18 PM, Karl Berry <karl at freefriends.org> wrote:
>>
>>     XDvi 22.87.04 (Xaw toolkit): Failed assertion:
>>     ../../../texk/xdvik/dvi-draw.c:2187: "color_bot_size > 0":
>>     color_bot_size mustn't become negative! Aborting now. Please report this
>>     as a bug to: https://urldefense.com/v3/__http://sourceforge.net/tracker/?group_id=23164&atid=377580__;!!C5qS4YX3!TIkEmIlMHA6lfca4TrgLZRgQC7EC_MmXhVTyyR5_-hz2AjvR8aElw10QzxS-LHA$
>>
>> A different failure, perhaps with the same underlying cause, whatever it
>> is.  Can you post your .dvi, Dick?  It does not really matter that it is
>> not minimal. What's important for debugging, at least at first blush, is
>> to be able to reproduce the crash. (Maybe you could use dviselect to
>> extract out a few pages and see if the crash still happens, though.)
>>
>> Per Mojca's suggestion, does anyone have FreeBSD that can try it? -k
>>
> 
> 
> I'm beginning to understand John's frustration. When I reported this bug, it happened consistently. I could quit and restart XQuartz and open my document, and it would consistently crash. Just a few motions in the page number list would cause it.
> 
> Today, nothing. I can move around the document at will, sweep down the number list, type R over and over. Solid as a rock.
> Go figure.


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.

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)?

JK