## WeBWorK Main Forum

### parserFunction/parserAssignment memory issues

by Andras Balogh -
Number of replies: 4

LoyolaChicago/Precalc/Chap5Sec4/graph-scaling-23.pg

This one problem has brought down our WeBWorK server with 24 GB of memory several times already. Yesterday I was able to identify and kill the corresponding Apache processes, and I saw that they were using 5-6 GB each. I was also able to identify that the memory problem disappears if I remove the line
parser::Assignment->Allow;

I don't understand how that line works, but more importantly, I would like to know if there is a server setting that would limit the memory usage of a single process in order to avoid such problems in the future.

We are running ww_version: 2.16 | pg_version 2.16|

### Re: parserFunction/parserAssignment memory issues

by Glenn Rice -

I have tested this problem, and it is not causing any issues for me.  Although, I don't have any version 2.16 servers or instances to test with anymore.

I am not sure how having the line "parser::Assignment->Allow;" in the problem would cause this issue.

In any case, that problem certainly should not have that line or load the "parserAssignment.pl" macro.  It doesn't use the macro other than having that line in it, and there is nothing the problem does that needs assignment to be activated.

### Re: parserFunction/parserAssignment memory issues

by Alex Jordan -

The Runestone server is still 2.16 until around the winter break. I don't have time to do thorough testing, but Glenn you can PM me if you would like access to test there.

Earlier this semester, there were memory issues that I tracked to this exercise:
Library/FortLewis/DiffEq/1-First-order/05-Substitution-Bernoulli/Lebl-1-5-05.pg

which uses parserAssignment. There is an issue that I can repeat on that server but not in my own school's 2.17 server. So I chalked it up to something from version 2.16. In the case of that exercise, submitting an answer like:
y=3-x+tan(x+arctan(-3))
would be OK, but submitting:
y=3-x+tan(x+pi/3)
would lead to the page timing out. And a corresponding spike in memory usage.

I guess if we cannot repeat this issue in 2.17, I'm not sure what to do about it, if anything. One thing you might try is grabbing the current 2.17 version of parserAssignment.pl and putting it into your course's macros/ folder. See if you can repeat the issue that way or if it clears up. I'm not 100% sure that the 2.17 version of parserAssignment.pl does not rely on other 2.17 changes though. You could review the commits and associated pull requests for that file since 2.16 here:

https://github.com/openwebwork/pg/commits/main/macros/parserAssignment.pl

### Re: parserFunction/parserAssignment memory issues

by Glenn Rice -
That is not necessary.  I can always downgrade my local development version of webwork2.  Going back to 2.16 isn't to hard.

Although, as you said, if the issue is not present in 2.17 I am not sure there is much to do about it.  We can't backport past the latest release with our approach to releases.

There were some relevant changes to parserAssignment.pl in 2.17 that may have fixed this issue.

### Re: parserFunction/parserAssignment memory issues

by Alex Jordan -

This was hitting the Runestone server hard on some exercises that have recently been in use. I did a diff on the 2.16 and 2.17 versions of parserAssignment.pl, and there were two changes that I do not fully understand, but seem to me to be isolated in scope to just this one file. So I put the 2.17 version in place, and now that exercise is not causing trouble.

The diff is:

350c347,348
<   bless $f,$class if $f->type eq 'Assignment'; --- > return$f unless $f->type eq 'Assignment'; > bless$f, $class; 358a357 >$other = $other->Package("Formula")->new($self->context,$other) unless$other->isFormula;

Anyway it seems like 2.16 may have a significant issue with parserAssignment.pl. Or maybe it was hotfixed at some point. I hope this thread helps anyone get past the issue.