fresh trunk aborts on start if .wxMaxima is present

[yurytch]

The program freshly built from today's trunk on linux breaks when it's trying to start talking with maxima instance. More precisely, it breaks in wxMaxima.cpp:2881:

for (; (it != data.end()); ++it)
      rest += *it;

when trying to deref it. The rest object at the moment of crash contains tens of thousands of \000 in its tailing part, which seems to be not right.

If there is NO ~/.wxMaxima, wxmaxima starts and creates one (and maybe works okay), but the next start after that crashes because there is ~/.wxMaxima present.

[gunterkoenigsmann]

But how is that even possible? And I am convinced not to have touched that end of the code....

[yurytch]

It starts okay (?) now, but fails when trying to process a cell.

There was an error in the XML Maxima has generated. BTW, this error text is unselectable.

My W. A. guess is some code dealing with talking to Maxima has been balancing on state of not working, like maybe making assumptions on how things 'usually' work. Something (new options?) just pushed it over. That several 10Ks run of \000 sort of suggests that point of view. That's program running away. And the code which first reserves a fixed number of positions, but then fills the space looking only for the end marker in the source, look suspicious to me.

Maybe this failure is caused/provoked by specific environment (forgot to mention, 23.05.1 works)

Here's what's in XML monitor (also unselectable in the normal manner, transferred via Xwindows clipboard):

SENT TO MAXIMA:

:lisp-quiet (setq $wxplot_usesvg nil)
:lisp-quiet (setq $wxplot_pngcairo t)
:lisp-quiet (setq $wxsubscripts 'all)
:lisp-quiet (setq wxUserConfDir "/home/ty/.maxima/")
:lisp-quiet (setq wxHelpDir "/d/home/ty/c/math/wxmaxima-main/0/share")
:lisp-quiet (setq $wxplot_size '((mlist simp) 1200 900))

―
a;

MAXIMA RESPONSE:

<math>
  <lbl altCopy="%o1">(%o1) </lbl>
  <mi lisp="*var-tag*">a</mi>
  </math>
<PROMPT>(%i2) </PROMPT>

[gunterkoenigsmann]

That might be possible. One thing I suspect is: What happens if a packet from maxima ends in the middle of a unicode char? Alternatively it could be that something somewhere in wxMaxima or even in an external library overwrites a byte that it shouldn't. On my computer everything works fine, on the CIs also => Might be exactly the kind of bug that is hard to find as it depends on having exactly the right memory layout and causes a part of the program to crash in a function that is completely unrelated to the bug. Or a bug that depends on maxima using exactly the right timing.

[gunterkoenigsmann]

As valgrind didn't find a problem I tried cppcheck. With a bit luck wxMaxima is now more stable than it was before. But will continue down that road in the next few days.

[yurytch]

Well, now that weird issue is gone. Quite a load of work going in these two days, wow! But unfortunately wxmaxima now crashes on me when I click 'Print'.

Quick look into gdb shows that in Printout::Printout this is done: Printout.cpp:47 m_configuration.SetWorkSheet(NULL); which goes to Configuration.cpp:206 m_worksheetDC = std::unique_ptr<wxClientDC>(new wxClientDC(NULL)); which crashes in #0 0x00007ffff7836834 in wxWindowBase::GetFont() const () at /usr/lib64/libwx_gtk3u_core-3.0.so.0

I have wxGTK3 3.0.5 installed. Maybe newer versions are more tolerant to such use?

[gunterkoenigsmann]

I always wonder is who the guys behind valgrind and c++check are as they allow me to find the causes of the very hard cases...

[yurytch]

Looks good so far. We can close it, I guess. As for those guys - well, some guys just like making tools more than making end-user programs. Your wxmaxima chores be the example to you ))