Is that the only page where the problem occur?

In general, 8 MB is a little bit short as a memory limit, but the changelog should not be that memory intensive.

It's the only page I've seen the error on so far.

It doesn't seem to happen when I'm viewing the page under the anonymous user account, only when I'm logged in under my account (haven't checked other user accounts) and only if I have All Projects selected.

This happens w/ the Official Mantis Bugtracker change log:
http://www.mantisbt.org/bugs/changelog_page.php

This will be fixed once 0001910 is deployed as part of 1.2.x. We can probably optimize the memory usage of some of the pages, however, with the fix for 0001910, I think it is a lower priority.

I also have a lot of issues (3500) and the change_log.php script cannot display them all, but I would really like to see change_log.php of past release. Something like a filter on N last releases or a multiple select would be useful.

I downsized my php memory_limit from 32Mb (giving a working changelog) to 16Mb and can definitely confirm the issue.

Since I'm learning how to use xdebug I'll try to see if there is an obvious offender; no promises though...

It seems that the main reason we are running out of memory (apart from loading the whole core/*_api.php set...) is that we cache all the bug's data while we compose the page.

Surely, reducing the scope of the changelog as proposed by plegall will help, but I'd prefer trying to improve the code so we don't break if someone has a large number of resolved issues in a single target version.

Victor, any idea?

Ideally our caches that are built into the core APIs should be limited to the last referenced N items (i.e. 50). Once we cache item 51, we should evict item 1 from the cache. Maybe its time to have some cache class that is re-used accross the different core APIs. This cache class should be useful with caching issues, issue notes, etc.

That's surely a good idea (another tick on the list of things to be revamped...)

in the meanwhile, I found out we can improve the situation (I can use again the changelog in 16MB) with the following:

diff --git a/core/custom_function_api.php b/core/custom_function_api.php

index e6b3784..9e26580 100644

--- a/core/custom_function_api.php

+++ b/core/custom_function_api.php

@@ -58,6 +58,7 @@

}

            echo ' - ', get_enum_element( 'status', $t_bug->status ), '.<br />';


bug_clear_cache( $p_issue_id );

}
# --------------------

Fixed by applying the proposed patch.

The same was applied to roadmap