WxMaxima fails to communicate with Maxima process on OpenBSD

[jherning]

wxMaxima on OpenBSD starts a Maxima process but Maxima commands issued inside wxMaxima do nothing when issued, indicating a likely communication error with the Maxima process.

D. Dickman has diagnosed this as cause by commit 5d8dff1 with communication restored by reverting the commit.
https://marc.info/?l=openbsd-ports&m=175330630429297)

[jherning]

I think there is some problem with the usage of the wxSOCKET_WAITALL_WRITE flag. The commit (5d8dff1) looks to me like it changes the code to assume all data is written with Write(). The following changes restore communication with Maxima for me:

diff ../wxmaxima-Version-25.04.0/src/Maxima.cpp src/Maxima.cpp
78c78
<   m_socket->SetFlags(wxSOCKET_NOWAIT_READ);
---
>   m_socket->SetFlags(wxSOCKET_NOWAIT_READ | wxSOCKET_WAITALL_WRITE);
103c103
<       m_socket->SetFlags(wxSOCKET_WAITALL);
---
>       m_socket->SetFlags(wxSOCKET_WAITALL_WRITE);
diff ../wxmaxima-Version-25.04.0/src/wxMaxima.cpp src/wxMaxima.cpp
2535c2535
<                                               new wxSocketServer(addr, wxSOCKET_WAITALL_WRITE));
---
>                                               new wxSocketServer(addr, wxSOCKET_NONE));

The same result is obtained without the change to wxMaxima.cpp, but I think the code may have clobbered the WAITALL_WRITE flag there (perhaps it should stay there, though, and perhaps the only needed change is the first at line 78). Either way I get the following failed assertion. I'm not sure why, as I thought READ/WRITE should be independent.

./src/common/socket.cpp(1712): assert "!(flags & wxSOCKET_NOWAIT) || !(flags & (wxSOCKET_WAITALL | wxSOCKET_BLOCK))" failed in SetFlags(): Using wxSOCKET_WAITALL or wxSOCKET_BLOCK with wxSOCKET_NOWAIT doesn't make sense

Backtrace shows the assertion is triggered at line 78 in Maxima.cpp.

In any case, this is probably not the correct solution. I'm not familiar with the codebase and have not coded in a while, but I hope this helps.

[jherning]

Looking at wxWidgets, the assertion may be in error:
wxWidgets/wxWidgets#17114

So maybe this is a start?

diff ../wxmaxima-Version-25.04.0/src/Maxima.cpp src/Maxima.cpp
78c78
<   m_socket->SetFlags(wxSOCKET_NOWAIT_READ);
---
>   m_socket->SetFlags(wxSOCKET_NOWAIT_READ | wxSOCKET_WAITALL_WRITE);

[daute]

Thanks. The additional flag | wxSOCKET_WAITALL_WRITE seems to solve the issue in my (new) OpenBSD test-installation, but the (wrong) assert must be fixed (by the wxWidgets project), before we can use that.
Maybe setting the flag (either wxSOCKET_NOWAIT_READ OR wxSOCKET_WAITALL_WRITE (before if we are writing or reading) might be a solution. But I have to think more about that...

Why does it work on other Systems (Linux, Windows, MacOS, etc.)?

Best regards, Wolfgang

[jherning]

Thanks for looking into this! Yes, I don't know either whether changing the wxSockets flags on the fly is a good idea.

Unfortunately when I looked into the assert issue in the wxWidgets repo, the claim was made that the wxSockets code is essentially unmaintained. I submitted to pull request to simply remove the assertion. I'll let you know over here if that happens and it's still relevant.

Maybe the short-term solution is to revert commit 5d8dff1. Perhaps the original code worked around the limitation of wxSockets to set read and write to be blocking/non-blocking independently (this changed ~10 years ago)?

OpenBSD is not as performance-prioritizing as other operating systems. It's possible the code was working on Linux, Mac, Win, etc. only by luck, i.e. fast modern computers which almost always grabbed the entire message with a single non-blocking write(), at least into some sort of kernel buffer. It's possible such a system could have failed to do so occasionally or under heavy load or with an extra long message.

[jherning]

Wolfgang,

Is it possible for you to test this:
wxWidgets/wxWidgets@943e4fb
?

It would take some work/re-learning for me to set up testing a wxWidgets patch.

[Partmedia]

I'm on FreeBSD 14.3 and run into the same issue. Reverting 5d8dff1 also fixes it for me.