[Branch: openmath] Crash with array and \mathxx and malformed brackets

[jokteur]

Hi,

When having this example code,

\begin{array}{l}
  \mathbf{
\end{array}

or

\begin{array}{l}
  \mathit{
\end{array}

or whatever \mathxx{, microtex on the openbranch makes a segmentation fault.
In particular, in atom_font.cpp, my debugger says that:

sptr<Box> FontStyleAtom::createBox(Env& env) {
  if (_nested) {
    _mathMode ? env.addMathFontStyle(_style) : env.addTextFontStyle(_style);
    auto box = _atom->createBox(env);
    _mathMode ? env.removeMathFontStyle(_style) : env.removeTextFontStyle(_style);
    return box;
  }
  return env.withFontStyle(_style, _mathMode, [&](Env& e) { return _atom->createBox(e); }); // _atom is nullptr
}

_atom is nullptr. This happens will all fonts, XITS, Latin Modern, Fira and Gyre DejaVu. This really only happens in array mode, and this bug doesn't happen in the master branch.

[sp1ritCS]

Add a check if _atom is null and if it is replace it with sptrOf<EmptyAtom>().

See 2d06b1b

There are quite a lot of issues exactly like this in the codebase. See #154

[NanoMichael]

@sp1ritCS is right, It requires further testing in scenarios like this, @sp1ritCS has already written the AFL++ Fuzzer test, please see #154.
P.S. I currently don't have much time to matain this project (I was actually laid off 😿, I'm preparing for a job interview, it would be great if someone could offer me a job opportunity).

[sp1ritCS]

P.S. I currently don't have much time to matain this project (I was actually laid off 😿, I'm preparing for a job interview, it would be great if someone could offer me a job opportunity).

That sucks 😦. I obv. have little to no idea how the job market is in mainland China, but I wish you best of luck in finding something stable :).
Does this that the initial MicroTeX release is postponed for an indefinite amount of time, or do you have the time to do an initial release of it in its current state (maybe with the docs from #129 added)?

[jokteur]

I don't have an enormous amount of time, if I can take the time to get familiar with the codebase, I could happily help squashing some of the bugs in the openmath branch.

[sp1ritCS]

I don't have an enormous amount of time, if I can take the time to get familiar with the codebase, I could happily help squashing some of the bugs in the openmath branch.

The very large majority of bugs are nullptr derefs that occur due to the parser reading trashy input, like the one you've found here. As I've said, practically all of them can be fixed by replacing the nullptr with a sptrOf<EmptyAtom>(), there are just quite a lot of them (see the archive I've posted in the fuzzer PR). In this case, adding something like

_atom = _atom == nullptr ? sptrOf<EmptyAtom>() : _atom;

or

if (_atom == nullptr)
	_atom = sptrOf<EmptyAtom>();

at the start of the function should fix this.

[jokteur]

Thanks, I will make a PR maybe in September when I have a bit the time.
This library is really useful, so I plan to give back however I can.

[NanoMichael]

Does this that the initial MicroTeX release is postponed for an indefinite amount of time, or do you have the time to do an initial release of it in its current state (maybe with the docs from #129 added)?

I'm not sure how much more time it will take, but releasing the final version in its current state seems too hasty. The main issue is the abundance of bugs and the lack of user documentation (at the very least, there should be a user guide).