for those of us on older crusty versions of php:

igx@soy[!]: cat memuse.php
<?php
require_once( 'core.php' );

    $t_core_path = config_get( 'core_path' );

function memory_get_usage() {
$my_pid = getmypid();
return(ps -eo vsz,rss,pid | grep $my_pid);
}

    echo "Memory usage: ".memory_get_usage()."\n";

?>
igx@soy[!]: php memuse.php
X-Powered-By: PHP/4.0.6
Pragma: no-cache
Expires: Fri, 01 Jan 1999 00:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Content-type: text/html

Memory usage: 10560 9936 12440

igx@soy[!]:
usage is in KBytes...

Not sure if anything could be done since I think most of the memory is taken up by loading up the database interface. When running this without loading any mantis info, it takes up 3MB of resources... haven't bothered testing yet with making just a db connection.

The same server runs squirrelmail and we ran into the same issue with that software so we had to change the php.ini settings to allow 12MB.

edited on: 10-30-04 08:27

It's worth noting, too, that the performance is very slow. When I configure to tell me how long execution takes, I get times of about 1.7 seconds. Only about .1 or .2 seconds of that is spent on queries. This is on main_page.php, which isn't very intensive.

The server is not heavily loaded and should be able to handle this easily, so I'm wondering if this has something to do with the speed problem.

edited on: 10-30-04 09:22

Leo,

Are you able to run your test case was a copy of the latest version of xdebug (from http://www.xdebug.org), with a php binary compiled with --enable-memory-limit, and set it up to trace memory usage?

I've not used the latest version of xdebug yet myself, but:

"
xdebug.trace_format [integer] (default: 0) (Xdebug 2)
The format of the trace file. Value Description
0 shows a human readable indented trace file with: time index, memory usage, memory delta (if the setting xdebug.show_mem_delta is enabled), level, function name, function parameters (if the setting xdebug.collect_params is enabled, filename and line number.
"

Running xdebug with these settings, might identify exactly what is going on here.

If not, i'll probably try and take a look myself soon

I get around ~ 4MB used for that test case - the 'change' in memory usage between the two values below was with persistant db conns on vs off

X-Powered-By: PHP/4.3.7
Memory usage: 4314000

X-Powered-By: PHP/4.3.7
Memory usage: 4462776

somewhat lower then the value you are seeing for your test case.

ADODB lib takes ~ 800K to load into php. The way we load the API up, counts for the rest.

I'm not sure whether something is leaking memory, or rather, whether we just load up too much in one go.

(trace @ http://www2.quakenet.org/~quakenet/trace.3752631470.xt)

Sorry, I don't have access to that debugging tool. I would be glad to help if I did.

I just upgraded to 1.0.0.rc1 and started getting the following error:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 6556 bytes) in /var/www/dev/mantis1rc/htdocs/core/config_api.php on line 81

It happens when I load the "View Issues" page, and the filter returns more than a handfull of issues. I've gotten the error with as few as 76 issues. I have not looked at the code, but it seems very odd that a simple page would need 64MB.

This is the version of the config_api.php
$Id: config_api.php,v 1.33 2005/07/17 17:05:28 thraxisp Exp $

This is still an issue?

I see the same error in an 1.0.0rc4 installation on apache 2.0.52 / php 5.0.2. The error occurs when I try to exec "Print reports" or "CVS Export":

"Print reports":
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 47 bytes) in [ ... ]/core/bug_api.php on line 95

"CVS Export":
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 53 bytes) in [ ... ]/core/bug_api.php on line 95

I check the problem again and found that it depends on the number of bugs displayed.
If I have 98 bugs that are shown within view_all_bug_page.php I have no problems, if I have 206 and 617 bugs I get the memory problem, if I have 701 bugs no html is produced at all.

(I used the various "Hide Status" filters, therefore the odd numbers of bugs.)

BTW: I reproduced the problem on a mantis 1.0.1 installation

Maybe the problem is that print_all_bug_page.php and csv_export.php show the /complete/ list of (possibly filtered) items (while view_all_bug_page.php always shows a restricted list of 50 items).

I just stumbeled over 0006861 (memory leak in core/file_api).
Maybe the reason for the trouble is similar.

As tk i experience the problem with "print reports". i use 1.0.5 with linux/ubuntu 6.01, mysql 5.0.22. At the moment i have 179 bugs reported. if i use "print reports i get the following messagees:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 706 bytes) in /opt/release-1.05/core/custom_field_api.php on line 1234
OR
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 64 bytes) in /opt/release-1.05/core/config_api.php on line 38
I take it that this bug is still not solved. I use 8 custom fields and two of them are date fields, but reading the issues i think this has nothing to do with my customisation.

I am not able to reproduce the issue using MantisBT 1.2.11 and PHP 5.3.

Our own summary page needs 6,905 KB
Viewing 1000 issues needs 18,687 KB. Probably much better than the 67,108 KB for 79 issues mentioned at 0004798:0011136