wxMaxima does not establish a connection with Maxima

[perryprog]

I do not believe this happened on version 3.0.4 of wxWidgets (March, 2018), but it definitely does with at least version 3.1.3 (Late October, 2018).

Anyway: what happens (on version 3.1.3 hereafter) is that wxMaxima will open, preform fine in terms of UI, but seems to never move past the Maxima started. Waiting for connection.... This also means I can't run any commands.

The problem specifically seems to be with launching the maxima binary: if I run maxima -s 4010 from the terminal everything goes fine.

Debug log:

10:18:28: wxMaxima version 19.12.1
10:18:28: Running on Mac OS
10:18:28: Translations are read from /Applications/wxMaxima.app/Contents/Resources/locale.
10:18:28: Reading the config from the default location.
10:18:28: Maxima not found as /Applications/Maxima.app
10:18:28: Maxima not found as /Applications/maxima.app
10:18:28: Starting server on port 4010
10:18:28: Server started
10:18:28: Maxima not found as /Applications/Maxima.app
10:18:28: Maxima not found as /Applications/maxima.app
10:18:28: Running maxima as: "/usr/local/bin/maxima"  -s 4010 
10:18:29: Maxima started. Waiting for connection...
10:18:29: Welcome to wxMaxima

[gunterkoenigsmann]

If it doesn't happen every time to every user and it isn't likely yo be a memory-layout-dependent problem I guess this one to depend on timing, somehow. Will look into it tomorrow.

[perryprog]

Yeah. That, or macOS only. Since I have a workaround there's no rush.

[gunterkoenigsmann]

Hope we will find out. What I've already found is a code path in which wxMaxima refuses a connection because it didn't start a maxima before, but didn't send a log message to the debug messages window about that. But I don't see a way this code path could be entered...

[perryprog]

The new log message is not triggered at all.

[gunterkoenigsmann]

Perhaps I found the timing issue. If I didn't let's hope at least one of the new debug messages tells us what is going on.

[perryprog]

Exactly the same output as before. 😄

[gunterkoenigsmann]

In theory if the connection doesn't happen wxMaxima should now start a new maxima every 8 seconds and say so... ...and if this doesn't help, neither, the problem is sure not to be timing-related. ...and could originate in a security function of MacOs preventing wxMaxima's child process from talking to its parent. Or something similar...

[gunterkoenigsmann]

Seems like I broke the timers. They should work again, now.

[perryprog]

There we go.

15:09:36: wxMaxima version 19.12.1
15:09:36: Running on Mac OS
15:09:36: Translations are read from /Applications/wxMaxima.app/Contents/Resources/locale.
15:09:36: Reading the config from the default location.
15:09:36: Maxima not found as /Applications/Maxima.app
15:09:36: Maxima not found as /Applications/maxima.app
15:09:36: Starting server on port 4010
15:09:36: Server started
15:09:36: Maxima not found as /Applications/Maxima.app
15:09:36: Maxima not found as /Applications/maxima.app
15:09:36: Running maxima as: "/usr/local/bin/maxima"  -s 4010 
15:09:36: Maxima started. Waiting for connection...
15:09:36: Welcome to wxMaxima
15:09:44: Maxima didn't connect within the timeout
15:09:44: Trying to restart Maxima

However, there is something curious about this: I just tried switching back from devel wxWidgets (3.1.3) to stable (3.0.4) and wxMaxima connects to Maxima with no problems. Hopefully this helps. (Note that master of wxWidgets is no good either. I'm sticking with devel since it's somewhat more stable than master.)

[gunterkoenigsmann]

I still don't understand why maxma does connect to wxMaxima when started from the command line, but not when wxMaxima starts it. But I think I have found a bug: wxMaxima instructed the network socket to send all events to the main window, not to the main window's event handler - which IMHO should have never worked...

[gunterkoenigsmann]

What your observations show, though, is, that the problem doesn't seem to be timing, after all...

[perryprog]

Debug log is the same as last pasted.

What I'm real confuddled about (more surprise than confusion I suppose) is why this issue would even depend on wxWidgets' version.

(p.s. mate, get some sleep!)

[gunterkoenigsmann]

Good advice ;-)

Today I will do mainly non-software related things:

I still don't understand why it works if maxima is started by hand. If that weren't the case I would believe https://trac.wxwidgets.org/ticket/11030 to be back - which would no thing one can work around: If wxWidgets forgets to inform me that maxima connects I have no good way of finding out that it does.

If you would be willing to investigate that: wxWidgets comes with a few sample programs. If the socket sample doesn't work the problem is very likely to be in wxWidgets - and if they have a way to reproduce a problem using one of their samples they normally fix it quite fast. If the socket sample works it is instead likely to be me who has to find the solution.

[gunterkoenigsmann]

Had an idea for an ugly workaround - that only does help if the problem is in signalling that maxima wants to connect...

[perryprog]

Sorry for the late response.

Sadly this does not seem to change anything. I don't know if this is intentional, but I no longer get the "Maxima didn't connect within the timeout" spew.

If I get some time on my hands I can (try) to take a look around with lldb to see if I can find anything of interest.

[gunterkoenigsmann]

The loss of the timeout wasn't intentional but perhaps the timeout doesn't make any sense, anyway: Either maxima connects or it doesn't. What I still don't get is: Why can you start maxima from the command-line and it connects while if wxMaxima does the same it doesn't?

[gunterkoenigsmann]

Either I reproducibly don't see where the problem lies (even if the probability for this is low as communication code isn't too complicated) or the bug lies within wxWidgets - which means if you are willing to look if their socket sample works (and if it doesn't if you are willing to report a bug with them) I would be grateful - but not owning a mac asking others to test this is about what I can do.

[richardgobeli]

I had this happen today. I had a few WxMaxima windows open and 1 hung up on a fault and would not restart Maxima. I could not start a new math window that would get a connection. I went to the task manager and I saw 4 sbcl.exe tasks running. They were not a thread of wxmaxima like below. After I deleted them all the WxMaxima would start and connect.

I thought maybe this issue was the reason. The first time after installing, when the lapack is compiled the program hangs up. It looks like it is done, but WxMaxima is spinning in task manager for many minutes. sbcl is using no time. If I kill the window and open wxmaxima again it loads lapack very quickly like it was already complied from the first time. I just now deleted the compiled binaries in my user folder and tried loading lapack. I does the same thing it hangs up and is spinning. see below: Before starting again, I checked the binary files for lapack. The files are all there. starting a load(lapack) now takes only seconds. This did not cause the task sbcl to get orphaned from wxmaxima.

It is possible a fault starts the debugger and if I can't get it to restart that the sbcl gets orphaned.

[gunterkoenigsmann]

That looks very similar but I expect this to be a whole different set of problem:

• SBCL is fast. But its memory management is - let's say subobtimal.
• MS Windows overcommits memory and therefore can (in case more applications than expected actually use the memory they allocate) run out of memory in completely unexpected places so bad that there is no memory left for example for sending wxMaxima a signal that maxima just has been killed.
• MS Windows' console management (which message arrives in which stream) is fairly complex
• and officially there doesn't seem to be a way for one application to kill processes from another. - so wxMaxima has a hard time to kill maxima processes if maxima no more respond.

That the out of memory generates orphaned maxima processes looks strange to me, though. Perhaps I am entirely wrong. But I guess I have an idea...

[richardgobeli]

I agree this is not the orphaned sbcl issue.

I just tried adding 4000 MB to the memory and it still hangs up wxmaxima at the end when sbcl stops using cpu time. It has before compiled with 8096 MB. I have it now at below: Can it be that while sbcl is compiling that wxmaxima thinks it lost connection and your new routine starts trying to reconnect and screws up the ending of the compile. The next time I try it sbcl responds quickly and it is all good. I think it takes almost 20 to 30 seconds to compile lapack.

[gunterkoenigsmann]

In theory wxMaxima doesn't ask maxima to respond (which as maxima is single-process would, as you guessed, not happen during compilation). Instead it asks the operating system if the process still exists. What really happens if it does do this I can only guess, though.

[richardgobeli]

I tested the load(lapack) again and it actually does complete. It takes almost 10 minutes and it generates a large amount of output. It usually only takes 10 to 20 seconds. Something got really slow in the parsing of the compiler output. From the task manager, I see it took 1,215 MB of memory to generate the larger output. Normally it does only 5 or 6 warnings.

[richardgobeli]

I can no longer start more than 1 WxMaxima window. If I click on the new document in a running WxMaxima. The new window is made, but the window can not make a connection to Maxima. This has been this way for about as long as this bug report has been open.

Here are the processes in the task manager.

[gunterkoenigsmann]

I didn't find any errors in the code that connects maxima with wxMaxima. But in the last few days I re-wrote big parts of it hoping that this somehow magically will resolve any timing/memory layout/harmless-looking-but-broken-command issue. Don't know if that has happened, though...

[perryprog]

Yeah, all the same for macOS still. Unrelated, but note that the toolbar icons are now a tad large.

[KubaO]

There is still a problem with dangling sbcl.exe on Windows, but it doesn't always happen. I'm deferring this after the upcoming release, and it needs to be further investigated.

[ptpare]

I have just downloaded maxima and wxmaxima for the first time on a Windows 7 machine. I can run maxima from the command line but wxMaxima will not start Maxima. I get the error message:

"Can not start maxima. The most probable cause is that maxima isn’t installed (it can be downloaded from http://maxima.sourceforge.net) or in wxMaxima’s config dialogue the setting for maxima’s location is wrong."

In the config dialogue the path is correct and I added C:\maxima-5.44.0\bin path to the windows 7 environmental path variable. In the bottom right had corner of wxMaxima there is a message "Not connected to maxima"

I then tried installing maxima and wxmaxima on an Ubuntu 16.04 LTS system. maxima works from the command prompt but when I try and run wxmaxima I get the error message "wxMaxima could not start the server. Please check you have network support enabled and try again."

What is the best way forward to get wxMaxima working on either Windows 7 or on Ubuntu 16.04 LTS?

[perryprog]

With school back again, it's time for me to start using wxMaxima again!

This issue is no longer happening for me on a fresh computer and wxMaxima installation. The comment above does not seem to be the same issue, so I'm closing this.

[rubiklee-py]

i found a way to leave the problem away. When i start the wmmaxima, it shows Maxima exited... in the input window and show not connected to Maxima in the right bottom. Then i click the new document icon on the toolbar and start a new file, and it works fine this time.

[jborme]

I have this problem, or a similar one on linux (gentoo). Starting wxmaxima -> error "Cannot start Maxima. The most probable cause is that Maxima isn't installed".

The trick (by user @rubiklee-py just above) to click on a new window does not work. Some people on the web suggested to delete the profiles (~/.maxima, ~/.wxMaxima) due to a recent incompatible upgrade, it also did not work.

Let me know if there is anything I can do to produce usable debug traces.

[gunterkoenigsmann]

wxMaxima tries to output all pieces of relevant information into the "debug messages" sidebar. If you attach the messages from there as a text file here -perhaps I'll find something that might indicate what goes wrong.

What has helped for one user, once, was to tell wxMaxima in its configuration dialogue where to find maxima...

[gunterkoenigsmann]

...and which version of maxima do you use? Not that I have broken something for exactly the maxima version you are using...

[gunterkoenigsmann]

...from the comments above it strongly looks like this might be a timing problem. But I don't see where we can have a race condition...

[jborme]

wxMaxima 21.05.2. Note that I upgraded from 20.12.2 in hope it would solve the problem. maxima is in /usr/bin, the first thing I tried was to specify that in the preferences, but both the default value and the "/usr/bin/maxima" option give the same. Also, the message says it has a PID so it was launched. Also, I can launch maxima from command line and insert commands there.

Contents of the Debug sidebar:

20:50:59: OS: Linux 5.15.2-gentoo-x86_64 x86_64 Version 5.15
20:50:59: wxWidgets 3.0.4
20:50:59: wxWidgets is using GTK 3
20:50:59: Translations are read from /usr/share/locale.
20:50:59: Reading the config from the default location.
20:50:59: Gnuplot found at: /usr/bin/gnuplot
20:50:59: Selected language: fr_FR (80)
20:50:59: LANG=fr_FR.utf8
20:50:59: Trying to start the socket a maxima on the local machine can connect to on port 49152
20:50:59: Serveur démarré
20:50:59: Running maxima as: "maxima"  -s 49152 
20:50:59: Maxima process (pid 20866) has terminated with exit code 0.
20:50:59: Last message from maxima's stdout: Connecting Maxima to server on port 49152

20:50:59: Maxima process terminated unexpectedly.
20:50:59: Can not start Maxima. The most probable cause is that Maxima isn't installed (it can be downloaded from https://maxima.sourceforge.io) or in wxMaxima's config dialogue the setting for Maxima's location is wrong.
20:50:59: Maxima  a démarré. Attente de la connection…
20:50:59: Bienvenue dans wxMaxima
20:51:02: FontCache Raw Miss:  4,00pt  BI-- "Arial" fam:70 enc:0
20:51:02: FontCache Resolved:  4,00pt  BI-- "Arial" fam:70 enc:43
20:51:02: FontCache Raw Miss: 12,00pt  ---- "Arial" fam:70 enc:0
20:51:02: FontCache Resolved: 12,00pt  ---- "Arial" fam:70 enc:43
20:51:02: Not connected to Maxima

The blank line before "terminated unexpectedly" was there originally.

[jborme]

in the command line

Maxima 5.45.1 https://maxima.sourceforge.io
using Lisp SBCL 1.4.9
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) 1+1;
(%o1)                                  2
(%i2) 

[jborme]

I added --verbose to the additional parameters in wxMaxima's parameters. Here is the output:

22:47:17: Maxima process (pid 2947) has terminated with exit code 0.
22:47:17: Last message from maxima's stdout: Connecting Maxima to server on port 49152

22:47:17: Last message from maxima's stderr: + '[' sbcl = clisp ']'
+ '[' sbcl = cmucl ']'
+ '[' sbcl = scl ']'
+ '[' sbcl = gcl ']'
+ '[' sbcl = acl ']'
+ '[' sbcl = openmcl ']'
+ '[' sbcl = ccl64 ']'
+ '[' sbcl = ecl ']'
+ '[' sbcl = abcl ']'
+ '[' sbcl = sbcl ']'
+ '[' -x /usr/lib64/maxima/5.45.1/binary-sbcl/maxima ']'
+ exec sbcl --core /usr/lib64/maxima/5.45.1/binary-sbcl/maxima.core --noinform --end-runtime-options --no-sysinit --no-userinit --eval '(cl-user::run)' --end-toplevel-options -v -s 49152