Hi Oliver - I can't easily rebuild the musl binaries, so waiting for TL24 looks like the current state. And good luck with Gentoo.

I'm really glad you dug into this to find these hard-to-pin-down errors. Thanks again. Happy converting :).

Hi again Oliver - well, I couldn't discern any plausible way to initialize the htf_4hf array on the fly, so I just memset the whole array to zero after it is allocated. That is, after this line:

htf_4hf = m_alloc(struct htf_4hf_rec, 256);

I added (some comments and):
memset (htf_4hf, 0, 256 * sizeof (struct htf_4hf_rec));

and valgrind was blessedly silent afterwards. The HTML output on your sample file was unchanged. I didn't test anything else specifically.

It's been a while since I called memset by hand :), so please do let me know if you see problems. (Eitan never wrote a wrapper for calloc as he did for malloc, so this seemed the simplest way.)

I also committed the new source to TL, r68541.
https://tug.org/svn/texlive/trunk/Build/source/texk/tex4htk/tex4ht.c

And I also installed a new tex4ht binary for x86_64-linux (only) since, well, why not (r68542). I'm not sure if you are building from source or using our binaries. Let me know if I need to do more to propagate the fix so you'll get it.

Thanks again for doing all the real work here.

Hi Oliver - thanks again for all the debugging. Due to all your work, I think the fix for the invalid read is pretty simple:

&& cur_fnt >= 0

before the condition indexing font_tbl, to avoid the negative indexing. That is, change that line to be:

&& cur_fnt >= 0 && (default_font != font_tbl[cur_fnt].num) ){

Committed to the tex4ht repo in r1387. I'll update the TeX Live repo in a bit.

(The diff is obscured by thousands of unimportant #line changes, so not bothering to send that.)

cur_fnt is initialized to -1. So this happens when that test is made before any font (DVI fntdef command) has been seen, which is the case with your test dvi. It's not clear to me which of the many DVI specials (xxx opcodes) is being executed at the time of the test, but I think it doesn't matter. We can just protect against it.

After doing that, valgrind no longer complains about the invalid read (for me).

As long as I'm here, I'll look into the uninitialized values too, but thought I'd send this first.

Thanks again.

I've been haunted by "Illegal storage address" for large documents with many fonts for quite a while (coming and going with tex4ht releases and even changing depending on shell environment), and often, unrelated changes in the document (e.g. reducing fonts) fix it.

I believe I have finally hunted down the underlying issue to an invalid memory access in tex4ht — reproducible with an MWE (which does not crash), visible with valgrind / gdb.

Reporducer:

1) Create foo.tex with content:
-----
\documentclass{scrbook}

\begin{document}
\section{foo}
\subsection{bar}
Foo
\end{document}
------

2) Run:
make4ht --utf8 --output-dir html foo

3) Re-run the tex4ht step with valgrind:
valgrind tex4ht -cmozhtf -utf8 foo.dvi

This reveals:
-----
==4487== Conditional jump or move depends on uninitialised value(s)
==4487== at 0x10EE14: main (tex4ht.c:8099)
==4487==
==4487== (action on error) vgdb me ...
==4487== Continuing ...
==4487== Conditional jump or move depends on uninitialised value(s)
==4487== at 0x10EE16: main (tex4ht.c:8108)
==4487==
==4487== (action on error) vgdb me ...
==4487== Continuing ...
==4487== Invalid read of size 4
==4487== at 0x10E794: main (tex4ht.c:8741)
==4487== Address 0x8beb1f8 is 8 bytes before a block of size 2 alloc'd
==4487== at 0x48407C4: malloc (vg_replace_malloc.c:431)
==4487== by 0x11851B: malloc_chk (tex4ht.c:1481)
==4487== by 0x10EC30: main (tex4ht.c:7104)
==4487==
-----

The invalid read is most worrisome, it originates from the source lines:

8740 if( span_on && !in_span_ch && !ignore_chs && !in_accenting
8741 && (default_font != font_tbl[cur_fnt].num) ){

It is caused by the part:
(default_font != font_tbl[cur_fnt].num)
being evaluated, while the index cur_fmt is negative:

(gdb) p default_font
$12 = -1
(gdb) p cur_fnt
$13 = -1

This yields an invalid read. If the document has many (many!) fonts, the dynamically allocated and subsequently freed memory from opendir/closedir looking for the htf files ends up right before the font_tbl array, and depending on page boundaries, this read with negative index may yield an invalid read / SIGSEGV.

Since I don't understand the full logic of the code, I'm not fit to propose a (good) fix.

It seems this might be affecting other users, too, looking for reports of "Illegal storage address" on tex stackexchange which in some cases were "fixed" by unrelated document changes.

Nota bene:
The two "Conditional jump or move depends on uninitialised value(s)" are from the lines:
if( value == htf_4hf[mid].ch ){
and
} else if( value < htf_4hf[mid].ch ){
since htf_4hf seems to be used (in some cases) before being initialized. This does not lead to a crash, though, since it's not an invalid read.