Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Visvanath Ratnaweera -
Number of replies: 26
Picture of Particularly helpful Moodlers Picture of Translators

Hi all

We dist-upgraded Debian Stretch to Buster. PHP went from 7.0 to 7.4, Moodle from 3.5 to 3.9. STACK is 4.3.8 for Moodle 3.5+ 2020120600. I had to reinstall Maxima and Gnuplot which I got from the Debian repositories. Old STACK questions are still broken - with many errors similar to "The field ""Question text"" generated the following error: CASText failed validation. TIMEDOUT dumped)".

Here's the STACK healthcheck:

Check LaTeX is being converted correctly

Maths display method being used: MathJax.

STACK generates LaTeX on the fly, and enables teachers to write LaTeX in questions. It assumes that LaTeX will be converted by a moodle filter. Below are samples of displayed and inline expressions in LaTeX ...


Maxima configuration file


/* File generated on January 19, 2021, 8:03 pm */

/* Add the location to Maxima's search path */
file_search_maxima:append( [sconcat("/var/www/html/moodle/question/type/stack/stack/maxima/###.{mac,mc}")] , file_search_maxima)$
file_search_lisp:append( [sconcat("/var/www/html/moodle/question/type/stack/stack/maxima/###.{lisp}")] , file_search_lisp)$
file_search_maxima:append( [sconcat("/var/www/data/moodledata/stack/logs/###.{mac,mc}")] , file_search_maxima)$
file_search_lisp:append( [sconcat("/var/www/data/moodledata/stack/logs/###.{lisp}")] , file_search_lisp)$

STACK_SETUP(ex):=block(
    MAXIMA_VERSION_NUM_EXPECTED:43.2,
    MAXIMA_PLATFORM:"linux",
    maxima_tempdir:"/var/www/data/moodledata/stack/tmp/",
    IMAGE_DIR:"/var/www/data/moodledata/stack/plots/",
    PLOT_SIZE:[450,300],
    PLOT_TERMINAL:"svg",
    PLOT_TERM_OPT:"dynamic font \",11\" linewidth 1.2",
    DEL_CMD:"rm",
    GNUPLOT_CMD:"/usr/bin/gnuplot",
    MAXIMA_VERSION_EXPECTED:"5.43.2",
    URL_BASE:"!ploturl!",
    /* Define units available in STACK. */
    stack_unit_si_prefix_code:[y, z, a, f, p, n, u, m, c, d, da, h, k, M, G, T, P, E, Z, Y],
    stack_unit_si_prefix_multiplier:[10^-24, 10^-21, 10^-18, 10^-15, 10^-12, 10^-9, 10^-6, 10^-3, 10^-2, 10^-1, 10, 10^2, 10^3, 10^6, 10^9, 10^12, 10^15, 10^18, 10^21, 10^24],
    stack_unit_si_prefix_tex:["\\mathrm{y}", "\\mathrm{z}", "\\mathrm{a}", "\\mathrm{f}", "\\mathrm{p}", "\\mathrm{n}", "\\mu ", "\\mathrm{m}", "\\mathrm{c}", "\\mathrm{d}", "\\mathrm{da}", "\\mathrm{h}", "\\mathrm{k}", "\\mathrm{M}", "\\mathrm{G}", "\\mathrm{T}", "\\mathrm{P}", "\\mathrm{E}", "\\mathrm{Z}", "\\mathrm{Y}"],
    stack_unit_si_unit_code:[m, l, L, g, t, s, h, Hz, Bq, cd, N, Pa, cal, Cal, Btu, eV, J, W, A, ohm, C, V, F, S, Wb, T, H, Gy, rem, Sv, lx, lm, mol, M, kat, rad, sr, K, VA, eV, Ci],
    stack_unit_si_unit_conversions:[m, m^3/1000, m^3/1000, kg/1000, 1000*kg, s, s*3600, 1/s, 1/s, cd, (kg*m)/s^2, kg/(m*s^2), 4.2*J, 4200*J, 1055*J, 1.602177e-19*J, (kg*m^2)/s^2, (kg*m^2)/s^3, A, (kg*m^2)/(s^3*A^2), s*A, (kg*m^2)/(s^3*A), (s^4*A^2)/(kg*m^2), (s^3*A^2)/(kg*m^2), (kg*m^2)/(s^2*A), kg/(s^2*A), (kg*m^2)/(s^2*A^2), m^2/s^2, 0.01*Sv, m^2/s^2, cd/m^2, cd, mol, mol/(m^3/1000), mol/s, rad, sr, K, (kg*m^2)/(s^3), 1.602176634E-19*J, Ci],
    stack_unit_si_unit_tex:["\\mathrm{m}", "\\mathrm{l}", "\\mathrm{L}", "\\mathrm{g}", "\\mathrm{t}", "\\mathrm{s}", "\\mathrm{h}", "\\mathrm{Hz}", "\\mathrm{Bq}", "\\mathrm{cd}", "\\mathrm{N}", "\\mathrm{Pa}", "\\mathrm{cal}", "\\mathrm{cal}", "\\mathrm{Btu}", "\\mathrm{eV}", "\\mathrm{J}", "\\mathrm{W}", "\\mathrm{A}", "\\Omega", "\\mathrm{C}", "\\mathrm{V}", "\\mathrm{F}", "\\mathrm{S}", "\\mathrm{Wb}", "\\mathrm{T}", "\\mathrm{H}", "\\mathrm{Gy}", "\\mathrm{rem}", "\\mathrm{Sv}", "\\mathrm{lx}", "\\mathrm{lm}", "\\mathrm{mol}", "\\mathrm{M}", "\\mathrm{kat}", "\\mathrm{rad}", "\\mathrm{sr}", "\\mathrm{K}", "\\mathrm{VA}", "\\mathrm{eV}", "\\mathrm{Ci}"],
    stack_unit_other_unit_code:[min, amu, u, mmHg, bar, ha, cc, gal, mbar, atm, torr, rev, deg, rpm, au, Da, Np, B, dB, day, year, hp, in, ft, yd, mi, lb],
    stack_unit_other_unit_conversions:[s*60, amu, amu, 133.322387415*Pa, 10^5*Pa, 10^4*m^2, m^3*10^(-6), 3.785*l, 10^2*Pa, 101325*Pa, 101325/760*Pa, 2*pi*rad, pi*rad/180, pi*rad/(30*s), 149597870700*m, 1.660539040E-27*kg, Np, B, dB, 86400*s, 3.156e7*s, 746*W, in, 12*in, 36*in, 5280*12*in, 4.4482*N],
    stack_unit_other_unit_tex:["\\mathrm{min}", "\\mathrm{amu}", "\\mathrm{u}", "\\mathrm{mmHg}", "\\mathrm{bar}", "\\mathrm{ha}", "\\mathrm{cc}", "\\mathrm{gal}", "\\mathrm{mbar}", "\\mathrm{atm}", "\\mathrm{torr}", "\\mathrm{rev}", "\\mathrm{{}^{o}}", "\\mathrm{rpm}", "\\mathrm{au}", "\\mathrm{Da}", "\\mathrm{Np}", "\\mathrm{B}", "\\mathrm{dB}", "\\mathrm{day}", "\\mathrm{year}", "\\mathrm{hp}", "\\mathrm{in}", "\\mathrm{ft}", "\\mathrm{yd}", "\\mathrm{mi}", "\\mathrm{lb}"],
    true)$
/* Load the main libraries. */
load("stackmaxima.mac")$
print(sconcat("[ STACK-Maxima started, library version ", stackmaximaversion, " ]"))$

Uncached CAS call

Debug info
Context used

Platform: linux Maxima shell command: maxima --use-version=5.43.2 Maxima initial command: load("/var/www/data/moodledata/stack/maximalocal.mac"); Maxima timeout: 10

Maxima command

cab:block([],print("[STACKSTART Locals= [ 0=[ error= ["), cte("CASresult",errcatch(diff(x^

n,x))), print("1=[ error= ["), cte("STACKversion",errcatch(stackmaximaversion)), print("2=[ error= ["), cte("MAXIMAversion",errcatch(MAXIMA_VERSION_STR)), print("3=[ error= ["), cte("MAXIMAversionnum",errcatch(MAXIMA_VERSION_NUM)), print("4=[ error= ["), cte("externalformat",errcatch(adjust_external_format())), print("5=[ error= ["), cte("CAStime",errcatch(CAStime:"2021-01-19 20:03:51")), print("] ]"), return(true));

CAS process return value: 139

Timings

Start: 1611083031.5708, End: 1611083032.2135, Taken = 0.64268612861633

CAS result

Segmentation fault (core dumped)

unpack_raw_result: no STACKSTART returned. Data returned was: Segmentation fault (core dumped) ]]]]

Unpacked result as

Array ( )

I have maximaversion set to 5.43.2,  maximacommandopt set to /usr/bin/maxima. The remaining ones are default, I guess. /usr/bin/latex from texlive is installed, /usr/bin/convert too.

How do I dig further?

Average of ratings: Useful (1)
In reply to Visvanath Ratnaweera

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
So, Maxima is just not running. If you can log in to the server, you can test this yourself. Open a command line and type the command maxima. Maxima should start and offer you a (%i1) prompt, where you can type quit();

What the error above is saying is that when maxima is run from within Moodle, it just crashes (core dump). That is not really a Moodle proble. It is a problem with the Maxima install.
In reply to Tim Hunt

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Hi Tim

Thanks for the pointer. (Sorry for deleting the previous try. As I was writing I thought I found the error.)

Yes, core dump is bad. But the point is, Maxima itself is working. Here's a session:


Another thing: I haven't compiled an "optimized" Maxima, it was working without before the upgrade (in 3.5).

Here are some current settings for scrutiny:
- platform Linux
- maximaversion 5.43.2
- castimeout 10
- casresultscache Cache in the database
- maximacommand /usr/bin/maxima
- maximacommandopt (empty)
- maximacommandserver (empty)
- serveruserpass (empty)
- plotcommand /usr/bin/gnuplot
- maximalibraries (empty)
- casdebugging (unticked)
- parsercacheinputlength 50

In reply to Visvanath Ratnaweera

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Compiling an "optimized" Maxima is a massive performance boost. Worth looking into when you get the time.

If Maxima is working for you, but not for Apache/PHP, then one thing to look at on modern Linuxes is SELinux. A quick check is to turn it off completely and see if that 'fixes' it. If doing that shows that SELinux is the cause, then you can follow the process for finding which specific security rule is getting in the way (there is a log file that tells you) and selectively disabling just that.
In reply to Tim Hunt

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Thanks for the continuous support. This is Debian 10, there is no SELinux or similar restrictions active. STACK worked in the previous Debian 9 till I dist-upgraded.

I raised the debug level and went through all the scripts shown on the STACK settings page and managed to get this error running the question tests in bulk script (question/type/stack/bulktestindex.php) for some STACK question categories:

This category contains 1 STACK questions.
Can't find data record in database table qtype_stack_options.

More information about this error
×Debug info: SELECT * FROM {qtype_stack_options} WHERE questionid = ?
[array (
0 => '226217',
)]
Error code: invalidrecord
×Stack trace:
line 1599 of /lib/dml/moodle_database.php: dml_missing_record_exception thrown
line 1575 of /lib/dml/moodle_database.php: call to moodle_database->get_record_select()
line 388 of /question/type/stack/questiontype.php: call to moodle_database->get_record()
line 913 of /lib/questionlib.php: call to qtype_stack->get_question_options()
line 982 of /lib/questionlib.php: call to _tidy_question()
line 597 of /question/engine/bank.php: call to get_question_options()
line 444 of /cache/classes/loaders.php: call to question_finder->load_for_cache()
line 1572 of /cache/classes/loaders.php: call to cache->get()
line 478 of /question/engine/bank.php: call to cache_application->get()
line 255 of /question/engine/bank.php: call to question_finder->load_question_data()
line 273 of /question/engine/bank.php: call to question_bank::load_question_data()
line 143 of /question/type/stack/stack/bulktester.class.php: call to question_bank::load_question()
line 75 of /question/type/stack/bulktest.php: call to stack_bulk_tester->run_all_tests_for_context()

Probably there is no connection. This script seems to analyze the questions themselves without connecting to Maxima.

BTW, "Run all the question tests..." made the server non-responsive, I had to restart!
In reply to Visvanath Ratnaweera

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
That looks unrelated to why Maxima is seg faulting when run by apache.
In reply to Visvanath Ratnaweera

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Tom Smith -

I also am struggling to get STACK/Maxima working again (it previously worked fine, but a package change

about 6 months ago appeared to break it.) Last night we upgraded the STACK plugin version to the latest available

as well as updating the server packages (Ubuntu 20.04). Maxima works fine from the command line; I've set the

correct version in the STACK config [5.43.2]  via Moodle and its path [/usr/bin/maxima].

Any help would be appreciated.


Here's the health script output:


Debug info

Context used

Platform: linux
Maxima shell command: /usr/bin/maxima
Maxima initial command: load("/srv/moodledata/stack/maximalocal.mac");


Maxima timeout: 10

Maxima command

cab:block([],print("[STACKSTART Locals= [ 0=[ error= ["), cte("CASresult",errcatch(diff(x^n,x))), print("1=[ error= ["), cte("STACKversion",errcatch(stackmaximaversion)), print("2=[ error= ["), cte("MAXIMAversion",errcatch(MAXIMA_VERSION_STR)), print("3=[ error= ["), cte("MAXIMAversionnum",errcatch(MAXIMA_VERSION_NUM)), print("4=[ error= ["), cte("externalformat",errcatch(adjust_external_format())), print("5=[ error= ["), cte("CAStime",errcatch(CAStime:"2021-01-27 08:33:05")), print("] ]"), return(true));

CAS process return value: 134

Timings

Start: 1611736385.5097, End: 1611736387.3044, Taken = 1.7946619987488

CAS result

Maxima 5.43.2 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
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) define: warning: redefining the built-in function intervalp
warning: variable simp (declared type boolean) assigned type any.
execvp failure when executing '/usr/bin/gcc -c -g -fdebug-prefix-map=/build/gcl-GO84Zx/gcl-2.6.12=. -fstack-protector-strong -Wformat -Werror=format-security -fsigned-char -pipe -fno-builtin-malloc -fno-builtin-free -fno-PIE -fno-pie -fno-PIC -fno-pic -Wall -Wno-empty-body -Wno-unused-but-set-variable -Wno-misleading-indentation -Wdate-time -D_FORTIFY_SOURCE=2  -I/usr/lib/gcl-2.6.12/unixport/../h  -O2  -c /tmp/gazonk_33990_0.c -o /tmp/gazonk_33990_0.o ': No such file or directory
Maxima encountered a Lisp error:

 SIMPLE-ERROR: (SYSTEM "/usr/bin/gcc -c -g -fdebug-prefix-map=/build/gcl-GO84Zx/gcl-2.6.12=. -fstack-protector-strong -Wformat -Werror=format-security -fsigned-char -pipe -fno-builtin-malloc -fno-builtin-free -fno-PIE -fno-pie -fno-PIC -fno-pic -Wall -Wno-empty-body -Wno-unused-but-set-variable -Wno-misleading-indentation -Wdate-time -D_FORTIFY_SOURCE=2  -I/usr/lib/gcl-2.6.12/unixport/../h  -O2  -c /tmp/gazonk_33990_0.c -o /tmp/gazonk_33990_0.o ") returned a non-zero value 130 0.

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%i1) 
[STACKSTART Locals= [ 0=[ error= [ 
], key = [ 
CASresult 
] 
, value = [ 
n*x^(n-1) 
], dispvalue = [ 
n*x^(n-1) 
], display = [ 
stack_disp(n*x^(n-1),"") 
] 
],  
1=[ error= [ 
], key = [ 
STACKversion 
] 
, value = [ 
stackmaximaversion 
], dispvalue = [ 
stackmaximaversion 
], display = [ 
stack_disp(stackmaximaversion,"") 
] 
],  
2=[ error= [ 
], key = [ 
MAXIMAversion 
] 
, value = [ 
"5.43.2" 
], dispvalue = [ 
"5.43.2" 
], display = [ 
stack_disp("5.43.2","") 
] 
],  
3=[ error= [ 
], key = [ 
MAXIMAversionnum 
] 
, value = [ 
43.2 
], dispvalue = [ 
43.2 
], display = [ 
stack_disp(43.2,"") 
] 
],  
4=[ error= [ 
There is no settable external format.
], key = [ 
externalformat 
] 
, value = [ 
false 
], dispvalue = [ 
false 
], display = [ 
stack_disp(false,"") 
] 
],  
5=[ error= [ 
], key = [ 
CAStime 
] 
, value = [ 
"2021-01-27 08:33:05" 
], dispvalue = [ 

Unrecoverable error: Segmentation violation..
Aborted (core dumped)

Unpacked result as

Array
(
    [0] => Array
        (
            [key] => CASresult
            [value] => n*x^(n-1)
            [dispvalue] => n*x^(n-1)
            [display] => stack_disp(n*x^(n-1),"")
            [error] => 
        )

    [1] => Array
        (
            [key] => STACKversion
            [value] => stackmaximaversion
            [dispvalue] => stackmaximaversion
            [display] => stack_disp(stackmaximaversion,"")
            [error] => 
        )

    [2] => Array
        (
            [key] => MAXIMAversion
            [value] => "5.43.2"
            [dispvalue] => "5.43.2"
            [display] => stack_disp("5.43.2","")
            [error] => 
        )

    [3] => Array
        (
            [key] => MAXIMAversionnum
            [value] => 43.2
            [dispvalue] => 43.2
            [display] => stack_disp(43.2,"")
            [error] => 
        )

    [4] => Array
        (
            [error] => There is no settable external format.
            [key] => externalformat
            [value] => false
            [dispvalue] => false
            [display] => stack_disp(false,"")
        )

    [5] => Array
        (
            [key] => CAStime
            [value] => "2021-01-27 08:33:05"
            [dispvalue] => Unrecoverable error: Segmentation violation..Aborted (core dumped)
            [error] => 
        )

)

Trying to connect to the CAS

We are trying to evaluate the following CAS text:

The derivative of {@ x^4/(1+x^4) @} is \[ \frac{d}{dx} \frac{x^4}{1+x^4} = {@ diff(x^4/(1+x^4),x) @}. \]  Confirm if unicode is supported: \(\forall\) should be displayed {@unicode(8704)@}.

The derivative of x^4/(1+x^4) is ddxx41+x4=diff(x4/(1+x4),x).

Confirm if unicode is supported:

should be displayed unicode(8704).

Errors

CASText failed validation. (%i2) length: argument cannot be a symbol; found %ERR -- an error. (%i3)

Debug info

(%i2) length: argument cannot be a symbol; found %ERR -- an error. (%i3)

Automatically create an optimised Maxima image

For best performance we need to optimize maxima on a linux machine. Use the plugin "healthcheck" page and see the documentation on this issue.

Maxima image created at: timeout --kill-after=10s 10s /srv/moodledata/stack/maxima_opt_auto -eval '(cl-user::run)'

Debug info

Context used

Platform: linux
Maxima shell command: /usr/bin/maxima
Maxima initial command: load("/srv/moodledata/stack/maximalocal.mac");


Maxima timeout: 10

Maxima command

:lisp (si::save-system "/srv/moodledata/stack/maxima_opt_auto")
quit();

CAS process return value: 0

Timings

Start: 1611736388.8441, End: 1611736390.5599, Taken = 1.7158231735229

CAS result

Maxima 5.43.2 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
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) define: warning: redefining the built-in function intervalp
warning: variable simp (declared type boolean) assigned type any.
execvp failure when executing '/usr/bin/gcc -c -g -fdebug-prefix-map=/build/gcl-GO84Zx/gcl-2.6.12=. -fstack-protector-strong -Wformat -Werror=format-security -fsigned-char -pipe -fno-builtin-malloc -fno-builtin-free -fno-PIE -fno-pie -fno-PIC -fno-pic -Wall -Wno-empty-body -Wno-unused-but-set-variable -Wno-misleading-indentation -Wdate-time -D_FORTIFY_SOURCE=2  -I/usr/lib/gcl-2.6.12/unixport/../h  -O2  -c /tmp/gazonk_34048_0.c -o /tmp/gazonk_34048_0.o ': No such file or directory
Maxima encountered a Lisp error:

 SIMPLE-ERROR: (SYSTEM "/usr/bin/gcc -c -g -fdebug-prefix-map=/build/gcl-GO84Zx/gcl-2.6.12=. -fstack-protector-strong -Wformat -Werror=format-security -fsigned-char -pipe -fno-builtin-malloc -fno-builtin-free -fno-PIE -fno-pie -fno-PIC -fno-pic -Wall -Wno-empty-body -Wno-unused-but-set-variable -Wno-misleading-indentation -Wdate-time -D_FORTIFY_SOURCE=2  -I/usr/lib/gcl-2.6.12/unixport/../h  -O2  -c /tmp/gazonk_34048_0.c -o /tmp/gazonk_34048_0.o ") returned a non-zero value 130 0.

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%i1) 
unpack_raw_result: no STACKSTART returned. Data returned was: 
Maxima 5.43.2 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
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) define: warning: redefining the built-in function intervalp
warning: variable simp (declared type boolean) assigned type any.
execvp failure when executing '/usr/bin/gcc -c -g -fdebug-prefix-map=/build/gcl-GO84Zx/gcl-2.6.12=. -fstack-protector-strong -Wformat -Werror=format-security -fsigned-char -pipe -fno-builtin-malloc -fno-builtin-free -fno-PIE -fno-pie -fno-PIC -fno-pic -Wall -Wno-empty-body -Wno-unused-but-set-variable -Wno-misleading-indentation -Wdate-time -D_FORTIFY_SOURCE=2  -I/usr/lib/gcl-2.6.12/unixport/../h  -O2  -c /tmp/gazonk_34048_0.c -o /tmp/gazonk_34048_0.o ': No such file or directory
Maxima encountered a Lisp error:

 SIMPLE-ERROR: (SYSTEM "/usr/bin/gcc -c -g -fdebug-prefix-map=/build/gcl-GO84Zx/gcl-2.6.12=. -fstack-protector-strong -Wformat -Werror=format-security -fsigned-char -pipe -fno-builtin-malloc -fno-builtin-free -fno-PIE -fno-pie -fno-PIC -fno-pic -Wall -Wno-empty-body -Wno-unused-but-set-variable -Wno-misleading-indentation -Wdate-time -D_FORTIFY_SOURCE=2  -I/usr/lib/gcl-2.6.12/unixport/../h  -O2  -c /tmp/gazonk_34048_0.c -o /tmp/gazonk_34048_0.o ") returned a non-zero value 130 0.

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%i1) ]]]]

Unpacked result as

Array
(
)

Maxima version

The version of the STACK-Maxima libraries being used (stackmaximaversion) does not match what is expected (2020120600) by this version of the STACK question type. It is not really clear how that happened. You will need to debug this problem yourself. Start by clearing the CAS cache.

Graph plotting

There should be two different plots. If two identical plots are seen then this is an error in naming the plot files. If no errors are returned, but a plot is not displayed then one of the following may help. (i) check read permissions on the two temporary directories. (ii) change the options used by GNUPlot to create the plot. Currently there is no web interface to these options.

Two example plots below.  {@plot([x^4/(1+x^4),diff(x^4/(1+x^4),x)],[x,-3,3])@} {@plot([sin(x),x,x^2,x^3],[x,-3,3],[y,-3,3],grid2d)@}  A third, smaller, plot may be displayed here with traditional axes.  (Newer versions of Maxima only.) {@plot([sin(x),x,x^2,x^3],[x,-3,3],[y,-3,3],[box, false],[yx_ratio, 1],[axes, solid],[xtics, -3, 1, 3],[ytics, -3, 1, 3],[size,250,250])@}

Two example plots below. plot([x^4/(1+x^4),diff(x^4/(1+x^4),x)],[x,-3,3]) plot([sin(x),x,x^2,x^3],[x,-3,3],[y,-3,3],grid2d) A third, smaller, plot may be displayed here with traditional axes. (Newer versions of Maxima only.) plot([sin(x),x,x^2,x^3],[x,-3,3],[y,-3,3],[box, false],[yx_ratio, 1],[axes, solid],[xtics, -3, 1, 3],[ytics, -3, 1, 3],[size,250,250])

Errors

CASText failed validation. (%i2) length: argument cannot be a symbol; found %ERR -- an error. (%i3)

Debug info

(%i2) length: argument cannot be a symbol; found %ERR -- an error. (%i3)

CAS result caching

CAS results are being cached in the database.

The cache currently contains 1 entries.


linux
OKCAS returned data as expected. You have a live connection to the CAS.
OKMaxima image created at: timeout --kill-after=10s 10s /srv/moodledata/stack/maxima_opt_auto -eval '(cl-user::run)'
FAILEDThe version of the STACK-Maxima libraries being used (stackmaximaversion) does not match what is expected (2020120600) by this version of the STACK question type. It is not really clear how that happened. You will need to debug this problem yourself. Start by clearing the CAS cache.
Load optional Maxima libraries: stats,distrib,descriptive,simplex
CAS results are being cached in the database.

Average of ratings: Useful (2)
In reply to Tom Smith

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Susan Mangan -
Hi, we are running Moodle v3.9 and experiencing the same problem. Has anyone had any luck figuring this one out?
In reply to Susan Mangan

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Thorsten Bartel -
Picture of Core developers
Hi Susan,
hi Tom,

the error message at the very end implies the usage of an optimized maxima image that has been compiled with an earlier version of STACK.
To resolve this issue, please delete the old optimized maxima image and instead set "qtype_stack | platform" to "Linux". Please ensure that the correct maxima version is selected in "qtype_stack | maximaversion" and that "qtype_stack | maximacommand" has the correct value (in most cases STACK will guess correctly if left empty).

Upon running the Healthcheck-Script, you should find an option to automatically create a new optimized image at the very bottom. I have observed newer versions of STACK performing this task automatically during the plugin upgrade process.

If these steps fail to solve your problem, please provide more information.

Cheers
In reply to Thorsten Bartel

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Tom Smith -
Hmm, I checked the "qtype_stack | platform" ... "Linux" (it was) and "qtype_stack | maximaversion" as 5.43.2; command line maxima reports as 5.43.2-3 so this seems like the best option. The healthcheck script fails with similar errors and when I tried to run the 'create optimised image', I got:

STACK healthcheck
Automatically create an optimised Maxima image

stack_ast_container: tried to get the value from of an unevaluated casstring.

More information about this error
In reply to Tom Smith

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Thorsten Bartel -
Picture of Core developers
Well, creating an optimized image is pretty much expected to fail if the healthcheck itself fails.
If Maxima is running on a system level, you could always try to create the optimized image yourself:
https://github.com/maths/moodle-qtype_stack/blob/master/doc/en/CAS/Optimising_Maxima.md
(Look for the chapter titled "Create Maxima Image by hand".)

You might at the very least get more detailed error output during this process.
If this fails, too, you can also set up another machine with an older version of Maxima (typically Ubuntu 18.04 LTS with Maxima 5.41.0), copy the STACK libraries to that system, create the optimised image there, then copy the finished image to your Moodle server. You'll obviously have to specify the older Maxima version in the question type settings and most likely you'll have to ensure that compatible Lisp versions / libraries are in use on both machines.
In reply to Thorsten Bartel

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Susan Mangan -
 
This is way above my paygrade - lol. I am getting the exact same errors Tom Smith reported.
 
In response to:
 
To resolve this issue, please delete the old optimized maxima image and instead set "qtype_stack | platform" to "Linux". Please ensure that the correct maxima version is selected in "qtype_stack | maximaversion" and that "qtype_stack | maximacommand" has the correct value (in most cases STACK will guess correctly if left empty).
 
Settings are as follows:
qtype_stack | platform = Linux
qtype_stack | maximaversion = 5.44

Upon running the Healthcheck-Script, you should find an option to automatically create a new optimized image at the very bottom. I have observed newer versions of STACK performing this task automatically during the plugin upgrade process.
 
I have cleared the cache and clicked on the button Create Maxima Image which returns: stack_ast_container: tried to get the value from of an unevaluated casstring.

If these steps fail to solve your problem, please provide more information.
 
I'm not sure what other information I can provide? We did have this working previously - I believe it was before the upgrade to 3.9.
 
 
In reply to Susan Mangan

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Thorsten Bartel -
Picture of Core developers
I can see how you might be overwhelmed by this issue if administration of server-level applications is not what you're usually doing.
The "easiest" way to circumvent your problem is most likely to install an older version of Maxima and/or build the Maxima image manually as described above.
You could also check using a different lisp implementation: Tom's error message suggests he's using GCL - if this is also the case for you, a switch to CLISP might be worth a try.

As you're running Maxima 5.44 on Linux, I'm assuming you're using a distribution I'm not intimately familiar with. Also, if this is something you're having troubles resolving by yourself, you should involve the person administrating your servers and check whether you can run tests with downgrading Maxima / manually building an image under their guidance / with their assistance.

The steps to troubleshoot this problem beyond the advice I provided here are much too small to be feasibly made without hands-on assistance and direct access to the server environment.

Wish you the best with overcoming this problem!
Cheers
In reply to Thorsten Bartel

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Susan Mangan -
Thank you very much for your reply. That is what we were trying to do (myself and our web systems administrator) but downgrading does not seem to be an easy task as each time he tried there was another dependency which kept leading him down a rabbit hole.

We running RH8 - I wonder if anyone who reads this has a working solution with either 5.44 or 5.41 could they confirm what distro they used?
In reply to Susan Mangan

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Thorsten Bartel -
Picture of Core developers
That's an easy one: We're running Ubuntu 18.04 LTS and 20.04 LTS (different servers). Both had no issues with Maxima 5.41.
In reply to Visvanath Ratnaweera

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Nadav Kavalerchik -
Picture of Core developers Picture of Plugin developers Picture of Testers Picture of Translators
I am also experiencing this issue with latest STACK and Maxima 5.43.2 on Ubuntu 20.04.2 LTS (maxima was installed from APT repos)
I found this: https://sourceforge.net/p/maxima/bugs/3527/ (which did not help me, but might help others?)

BTW, all other Moodle servers I am managing uses RedHat 7 with Maxima 5.41.0 and latest STACK plugin, that works fine.
Average of ratings: Useful (1)
In reply to Visvanath Ratnaweera

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Madhu Avasarala -
I am having the exact same issue. While searching, I found this post in Stack Overflow that seems to suggest that it is the type of Apache2 user:
https://stackoverflow.com/questions/65056494/maxima-segmentation-fault-php-exec-on-ubuntu-20-04
Now I don't know how to make the Apache2 user different from www-data. But is this useful for the experts here to guide us in a fruitful direction?
In reply to Madhu Avasarala

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Madhu Avasarala -
Also, I tried to run maxima from command line as a normal user and there was no problem. However, when I ran Maxima as user www-data from the command line, I did get a segmentation fault. So this must be the root cause - www-data apache2 user is unable to run maxima for some unknown reason.
To run as www-data I did the following:
sudo su -l www-data -s /bin/bash
maxima
(response is: Segmentation fault)
In reply to Madhu Avasarala

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Madhu Avasarala -
*SOLVED*
It seems that when STACK does the healthcheck script it requires the directory of www-data to be writable. I don't fully understand, this. When I executed sudo su -l www-data -s /bin/bash it logged me in as user www-data and put me in the directory /var/www which was the root of apache2. So I typed in exit to get out and become my own normal user and executed healthcheck and it still created segmentation fault. I then changed the owner of /var/www to user www-data and lo and behold, the STACK healthcheck script started working. I created the image and then cached it and changed the permissions of /var/www back to root and reran the healthcheckscript and this time it did not give me an error!
Average of ratings: Useful (4)
In reply to Madhu Avasarala

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Connie K. Me -

Hi everyone on this thread and out there,

I am also facing the same issues (Maxima 5.43.2 on Ubuntu 20.04.2 LTS, maxima installed from APT repos, running fine from the command line).

At first I had the initially reported error 139 with exactly the same output as Visvanath which I was able to fix thanks to Madhu's final response. 

But now I get error 134 exactly like Tom's health script output.

Has anyone found a way to solve the problem? Or is it meanwhile agreed upon that STACK only works smoothly with Maxima 5.41?

Any help would be much appreciated. 

BTW: Mine is a new install not an upgrade.

In reply to Connie K. Me

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
In the Moodle admin settings there is a setting for which version of Maxima you are using. Is that setting right?
In reply to Tim Hunt

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Connie K. Me -
Thanks a lot for taking time for my issue. If you mean the settings within the plugin it is as the same as Tom reported above: "qtype_stack | maximaversion" is set to point to "5.43.2" while the ubuntu command line reports maxima version as "5.43.2-3". I don't know if the variation in the last digit counts as a discrepancy.
In reply to Connie K. Me

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I think those two version numbers are close enough that this is not the problem.

And, nothing specific about that version at https://github.com/maths/moodle-qtype_stack/blob/master/doc/en/Installation/index.md#2-install-gnuplot-and-maxima.

I don't think your specific problem is necessarily caused by the Maxima version. I think you will have to try to debug what is going wrong.
In reply to Tim Hunt

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
To try to be a bit more helpful about how to debug this: you need to try to find the acutal command that the STACK code is trying to run. I think you can do this by turning on 'CAS debugging' in the settings, then going to the healthcheck page, and going all the technical output.

Then, open a comman-line on the server, and try the same comman - as the Apache user. So, something like

sudo -u www-data ... comand ...

Or, alternatively, knock up a simple PHP script like the on in https://stackoverflow.com/questions/65056494/maxima-segmentation-fault-php-exec-on-ubuntu-20-04, and load go to view that script in your browser.

Basically, you want ot replicate what the STACK code is doing internally, as closely as possible, and in a way that lets you see what happens.
Average of ratings: Useful (2)
In reply to Tim Hunt

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Connie K. Me -
I really appreciate your adding this as I feel a bit overwhelmed like Susan above.

I verified at the command prompt that the Apache user www-data can access maxima and execute all types of maxima commands (e.g. diff(x^4/(1+x^4),x);). 

So I tried the same in the CAS chat script linked in the plugin settings of STACK. Typing in any command (e.g. the above diff(x^4/(1+x^4),x)) in the CAS text box doesn't evaluate the expression but just yields an exact copy as the output: diff(x^4/(1+x^4),x).

Additionally any question variable defined in the question variables field leads to the CAS execution reporting the mentioned error message: CASText failed validation. (%i2) length: argument cannot be a symbol; found %ERR -- an error. (%i3)

Does that give any hint for a further diagnosis or is it just replicating the same symptoms?
In reply to Visvanath Ratnaweera

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Christopher Sangwin -
Picture of Particularly helpful Moodlers Picture of Plugin developers
Dear all,

I'm sorry you are having such problems in upgrading. This is difficult because we have to try to support between versions of Linux/LISP/Maxima/PHP/Moodle and the STACK plugin itself!

I've written a new section "Troubleshooting an upgrade" in the docs here.
https://docs.stack-assessment.org/en/Installation/Testing_installation/
The order in which you do some things matters, and you may need to clear out old settings to upgrade. So if you are having problems please go back to the basic Linux connection setting and start again.

That is the upgrade process.

Newer versions of STACK have started to do much stricter checking of what teachers type in. In the past we condoned some things but we can't do this any more (for good reasons we need a stricter syntax checking). Sorry, but some older questions will need to be edited if they didn't use fully correct Maxima. The bulk testing script is designed to find these before students do.

If this does not help, let me know and I'll see what can be done. If maxima "segmentation fault" is the problem, there are limits to how I can help!
Average of ratings: Useful (2)
In reply to Christopher Sangwin

Re: Major upgrade broke STACK, now getting "CASText failed validation. TIMEDOUT dumped"

by Connie K. Me -
Thank you so much to both of you (and whoever else) for inventing the whole thing in the first place and providing such a quick, kind and helpful support! This is so valuable as more and more newbies like me are stretching out their hands toward this great tool.

Maybe there is some undetected issue with version 5.43. I have now resorted to using the recommended Maxima version 5.41.0 and compiling it from source. This way the health check now runs to success and the handling of the question variables is without error messages. I'm still working on fixing non-appearing graphs and the system being very slow. But I'm also just halfway through the new troubleshooting page.

Again lots of thanks and keep up the good work!
Average of ratings: Useful (1)