"x = \pi" leads to segmentation fault in demo

[lazingor]

Typing in x = \pi in the demo app leads to a segmentation fault. Curiously = \pi is fine, as is x = 2. Is it because there's a shared font between x and \pi? Here's the end of the debug log output:

FILE: /home/code/cLaTeXMath/src/fonts/fonts.cpp, LINE: 190, FUNCTION: getChar, MSG: { char: x, font id: 2, path: res/fonts/base/cmmi10.ttf }
FILE: /home/code/cLaTeXMath/src/fonts/fonts.cpp, LINE: 190, FUNCTION: getChar, MSG: { char: =, font id: 18, path: res/fonts/latin/cmr10.ttf }
FILE: /home/code/cLaTeXMath/src/fonts/fonts.cpp, LINE: 190, FUNCTION: getChar, MSG: { char: �, font id: 5, path: res/fonts/base/cmmi10.ttf }
res/fonts/base/cmmi10.ttf already loaded, skip
[BOX TREE]:
0    HorizontalBox
1    ├── CharBox
1    ├── GlueBox
1    ├── CharBox
1    ├── GlueBox
1    └── CharBox

FILE: /home/code/cLaTeXMath/src/fonts/fonts.cpp, LINE: 45, FUNCTION: ~DefaultTeXFont, MSG: DefaultTeXFont destruct
Segmentation fault (core dumped)

[lazingor]

I've done some more testing, but haven't yet got the understanding of how things fit together to find the exact issue. I think it has something to do with the message about the font being already loaded, skip. In the MSGs, a different font id is specified for the character "x" and "\pi", but the same font file is to be loaded.

Note that the following are fine individually:
x = y (same font id = 2, font cmmi10.ttf)
\pi = \gamma (same font id = 5, font cmmi10.ttf)
but any mix of x and \pi will fail.

In src/fonts/fonts.cpp, it might be the logic in the code

void Font_cairo::loadFont(const string& file) {
  auto it = _file_name_map.find(file);
  if (it != _file_name_map.end()) {
    // already loaded
    _family = _file_name_map[file];
#ifdef HAVE_LOG
    __log << file << " already loaded, skip\n";
#endif
    return;
  }

Do the different font ids need to be taken into account here, rather than just filename?

Commenting out the return; gets rid of the segmentation fault, but maybe leads to other issues?

[NanoMichael]

According to the log messages, this issue is caused by PR #11, the 54th line, I'll fix it later.