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

[John Hawkinson]

I could use some help with some of these sanitizer reports, some of this code is...difficult for me to understand.

luigi scarso <luigi.scarso at gmail.com> wrote on Wed, 26 Jan 2022
at 04:40:54 EST in <CAG5iGsD6MLzGNHJHDnwuUpkqEWdbZqx8tnM36tVNWRoFRsbKTg at mail.gmail.com>:


> > And here is the UBSAN:
> >
> > jhawk at loud-room xdvik % TEXMFROOT=/usr/local/texlive/2021
> > TEXMFCNF=$TEXMFROOT/texmf-dist/web2c  ./xdvi-ubsan   t2a
> > ../../../texk/xdvik/dvi-draw.c:458:9: runtime error: left shift of negative value -3

Resolved with

--- a/texk/xdvik/dvi-draw.c
+++ b/texk/xdvik/dvi-draw.c
@@ -436,16 +436,16 @@ static unsigned long
 static long
 xsnum(FILE *fp, ubyte size)
 {
-    long x;
+    unsigned long x;
 
 #if	__STDC__
     x = (signed char)xone(fp);
 #else
     x = xone(fp);
     if (x & 0x80)
 	x -= 0x100;
 #endif
     while (--size)
 	x = (x << 8) | xone(fp);
     return x;
 }

(I'm not suggesting this patch is proper, only that it shuts up the sanitizer)


> > /Users/jhawk/src/xdvik-22.87.05/libs/freetype2/freetype-src/src/base/ftgloadr.c:149:40:
> > runtime error: applying zero offset to null pointer

Oops, a workflow error resulted in my working with a build that was only sanitizing xdvi, so I forgot about these issues in freetype and haven't looked into them. Probably I should.

> > ../../../texk/xdvik/ft.c:184:35: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
> > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ./../../texk/xdvik/ft.c:184:35 in

I do not understand what this code in read_ft_char() is doing, could someone give me a hand, or confidence to ignore the sanitizer here?

161         if (slot->bitmap.width > 0) {
162             int                 i;
163             unsigned char       *p;
164             bmUnitT             *q;
165 
166             p = slot->bitmap.buffer;
167             q = (bmUnitT *) g->bitmap.bits;
168             for (i = g->bitmap.h; i > 0; --i) {
169 #if WORDS_BIGENDIAN
170                 memcpy(q, p, (slot->bitmap.width + 7) / 8);
171 #else
172                 unsigned char   *p1     = p;
173                 bmUnitT         *q1     = q;
174                 bmUnitT         data    = 0;
175                 int             shift   = 0;
176                 int             j;
177 
178                 for (j = (slot->bitmap.width + 7) / 8; j > 0; --j) {
179                     if (shift >= BMBITS) {
180                         *q1++ = data;
181                         data = 0;
182                         shift = 0;
183                     }
184                     data |= reverse_byte[*p1++] << shift;
185                     shift += 8;
186                 }
187                 *q1 = data;
188 #endif
189                 p += slot->bitmap.pitch;
190                 q += bmTypeT_wide;
191             }



> > xdvi-ubsan: set_no_char: attempt to set character of unknown font, offset
> > 42
> > xdvi-ubsan 22.87.05 (Xaw toolkit): ../../../texk/xdvik/dvi-draw.c:488:
> > Shouldn't happen: I'll abort now, to help you debugging this.
> >
> this  looks like  the NULL pointer  as in [tlbuild] dvi test on mac

i'm not sure which one you think fits with that, but I'm optimistic.

> I also built Valgrind on my older x86_64 Mac (which does *not* see the xdvi
> > crash) and it reports some concerns, but I think they are perhaps not
> > meaningful (I'm not experienced with valgrind). Output below:
> >
> > :
> :
> 
> > ==76741==
> > --76741:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK );
> > xdvi-bin: Warning: Could not find graphics file "l3backend-dvips.pro"
> >
> 
> weird, here I have
> kdebug:fopen(/opt/luatex/texlive/2021/texmf-dist/dvips/l3backend/
> l3backend-dvips.pro, r) => 0x3a13b00

Sorry, that's because the older machine is running TL2015 which doesn't have that .pro file (and also which does not crash).
I noted the error but didn't focus on it; I suspect it's not significant, as that xdvi doesn't crash, either with .dvi files produced on its own that don't have missing .pro files, nor with .dvi files produced elsewhere that do.

--
jhawk at alum.mit.edu
John Hawkinson