Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.
 

Fatal error seen; any hints?


#1

I was attempting to edit a test plan for a project with a fairly large number of suites. Test suites are not being displayed on the edit page for the plan and at the bottom of the page I see the following message.

Is there a server configuration that needs adjustment to correct this?

We’re using: 1.0.3.9693 Beta (up-to-date)

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 634881 bytes) in /var/www/testrail/system/libraries/Loader.php on line 702


#2

Thanks for reporting this issue. It would be great if you could provide us with some additional numbers such as the actual suite count and, more importantly, a rough number for the test cases you have in those suites so that we can reproduce this issue.

Yes, you can just increase the PHP memory limit in the php.ini configuration file. Depending on the operating system you use, this file can either usually be found under /etc/php or /etc/php5 (Unix/Linux) or in the PHP directory in “Program Files” or “Program Files (x86)” (Windows). The setting which increases the memory limit is named “memory_limit” and could be changed to the following, for example:

(your current value seems to be 16M)

Regards,
Tobias


#3

Forgot to add:

after changing this setting, you normally need to restart your web server, so that PHP can pick up the new configuration.

Regards,
Tobias


#4

[quote=tgurock]Thanks for reporting this issue. It would be great if you could provide us with some additional numbers such as the actual suite count and, more importantly, a rough number for the test cases you have in those suites so that we can reproduce this issue.

Tobias[/quote]

Thanks. The issue seems to be intermittent so I suspect that the situation causing the memory allocation being short is dynamic. The specific instance I ran into was with test plan edit that had 406 test cases in 16 “runs”… on the right side there are 45 suites to add from in that project. There are 1655 test cases at present in that project. Other pertinent data may be that there are 16 users currently but only about 5 or 6 are using the system at once. There are two other projects on the server at present; only two of the projects are currently active.


#5

Thanks for the additional information.

I created a test project with similar amounts of suites and test cases. The memory usage never got over a few MB though (3-4) and I couldn’t reproduce the issue here directly. The add/edit test plan page should be the most memory-intense page of the entire application (when dealing with lots of test cases) and while reviewing the code I saw a few places that can be optimized memory-wise.

That said, PHP’s and TestRail’s memory consumption may differ across the different PHP versions, operating systems and even the used database. Which PHP version, operating system and database do you use?

This shouldn’t make a difference in this case as the PHP memory limit is a limit for each request and usually not for all users/requests combined, but we will look into it, thank you.

Regards,
Tobias


#6

Doing a bit more testing this time with Windows, IIS and SQL Server (previous testing was with Linux, Apache and MySql) shows that the memory usage seems to be higher on Windows than on Linux. I’ve created the same project and editing a large test plan now consumed about 10-12 MB (was about 3 MB previously), so the memory problem with the 16M limit doesn’t seem unusual.

We will add some code to TestRail to automatically increase the memory limit to a certain minimum threshold (probably 32 or 64MB) in the next beta. After researching this a bit more, I’ve found that it’s very common nowadays to run at least with 32MB (this is also only for peaks, usual requests don’t consume that much memory).

Regards,
Tobias


#7

[quote=tgurock]Thanks for the additional information.

.
.
.

That said, PHP’s and TestRail’s memory consumption may differ across the different PHP versions, operating systems and even the used database. Which PHP version, operating system and database do you use?

.
.
.

Regards,
Tobias[/quote]

We changed our memory configuration and have not had a recurrence of the issue so far. For your reference, our environment hosting TestRail is:

PHP 5.2.4-2ubuntu5.7 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 21 2009 19:52:39)

Linux 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 GNU/Linux

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION=“Ubuntu 8.04.3 LTS”

mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline 5.2


#8

Thank you, we will test it with this configuration as well.