Allowed memory size exhausted

This could be due to the insufficient memory limit allocated for the script.
Every script needs some memory for it to run and the limit is defined in "php.ini" file.
The attriburte name is "memory_limit" -
How to set?
Manually - Open the php.ini file - set as --> memory_limit = 128M (try restarting Apache server)
Script: ini_set('memory_limit','128M');

Php.ini will be available in the installation path of php binaries.
Hope that helps,
Thanks,
Kamu

I am changing the referring version.

@vacilando: Are you using a module that changes the Drupal cache to be kept in memory?
Is this the case for somebody who has the same issue?

I am just trying to understand what could cause the memory to become exhausted. That could have been one possibility, but it's more probable that the problem is caused from the call to drupal_page_footer().

Thanks again for your reply.

I did a rewrite of the xmlsitemap module that hopefully resolves this bug.
The idea: using drupal_page_footer() to cache is not ideal. Here is why:
1. Because of this bug
2. Mysql has a setting (smth like max_packet_size) that does not let you send a packed that is bigged than it. So caching the whole sitemap page in DB is not really good.
3. After the sitemaps have been generated, it should serve them faster than the current implementation.

The patch is against the the latest dev version of xmlsitemap from 2009-Jan-02.
It is not yet finished.
It needs some testing and reviewing before i/we can continue with this idea in it.

TODO:
Every TODO that is commented in the code

WARNING: please do not test this on a live site :)
I'll wait for your reviewing.
@vacilando: maybe you can test this on your host to see if you still get the error ? (of course not on the live DB)

I attached the patch and also an archive with the module rewritten.
Thanks.

Oops I left, by mistake the xmlsitemap_rebuild TRUE by default...
Reattached the correct (hopefully) patch + archive

Bleah... Sorry, I attached a wrong "fix".

I implemented 'xmlsitemap_rebuild_interval' setting so that you can fine tune how often the sitemap gets rebuilt. It defaults to 86400 (1 day).
Maybe someone can give it a spin :)

Cheers

Edit: forgot to specify that now xmlsitemap_log_access should work (manual call module_invoke_all('exit') from xmlsitemap_output).

There are the following errors in the patch:

• The final call to module_invoke() is not necessary, as file_transfer() calls exit(); therefore, after calling file_transfer() the module has already terminated its execution.
• _xmlsitemap_recursive_delete() wrongly calls _imagecache_recursive_delete().
• The patch should also work on multi-site, multi-language sites. For sure it doesn't work on multi-language sites, as the patch always use the same file name for the file it creates, but the site map could be created for different languages, which then would have different content.

Well, the version from the 2.01.2009 doesn't work on multi-language sites either... But that is not the point of this patch...
The point of this patch is to demonstrate that you can make it work for more people (that don't have access to setting 'memory_limit' in php.ini or to my.cnf) and with less system load (even if you get mysql to cache sitemap into the cache_page table, it should be faster to dump the contents of a file directly from it than to dump it from DB, and also you need to have big mem_limit because it is a single big row of data that gets load into ram first).

I was expecting you to look over/test the main idea of this patch: don't use drupal_page_footer, but cache the sitemaps as files.
I saw that in the repository you started working on the multilanguage issue: I'm sure that you/we can merge this patch into that too. But only of course if you take a look at the patch and see that maybe it has a point.

About module_invoke() in the xmlsitemap_output func: I didn't notice that file_transfer calls exit at the end. We need the invoke exit for the logging facility. So maybe put it before file_transfer call ??

I fixed _xmlsitemap_recursive_delete().

Thanks.

It would have been better if you kept to reply on the other report about how to optimize the code, rather to start replying to this report.

To review an idea is enough the idea gets explained in detail; a patch made for code that is already being changed is a way much useless.

Like I said, the module is being changed to work on multi-language sites, so the patch you attached here still would need to be changed when 6.x-2.x-dev will be made public.

The way your code caches the content of the site map can be adopted in the branch I am developing. If you will to cooperate in making this project code better, you could write a function that creates the file name used to contain the output of the site map, which takes in consideration the language currently used by Drupal, and the domain to which the page request has been submitted (in this way the function would be compatible with multi-site Drupal installations).
Simply write the function code and attach the comment to the other report, not this one.
-- Kiam
Kiam la luno renkontas la sunon

I put the patch here because it is about this bug and in CVS HEAD it is not solved either. Do you solve it in 6.x-2.x-dev release ? If not then this idea is still available (from my point of view).

And I'll try to do that function.

Cheers

But it's also a patch for a better xmlsitemap performance, that is the topic of the other report.
If you keep to add comments here, then I will set the other report like a duplicate.

I don't usually commit code to CVS HEAD.

Yup, I also think that post should be closed. You explained me thoroughly in there about those stuff and i thank you.

Why don't you commit to HEAD ? I mean, if you would, maybe there would be more ppl trying to help you. You are not alone in here... We all need this module (by submitting a bug/patch means that we had to use the module in the first place). So we should help in developing it. So by submitting a patch (or in this case more of an idea) means that I want to help.

I think that maybe tomorrow I'll have some time to look at that function you need.

I don't commit in HEAD because when the code is specific for a Drupal version it is required to create a branch.
In this case I cannot commit to HEAD because it has been created a version from HEAD code (6.x-0.x-dev).

The use of CVS HEAD is not necessary, then, to get contributions.

I didn't forget about the function that I promised to make, but lately I had absolutely 0 free time because of my exams.
I'll try to come back ASAP. I hope that by the end of next week I'll start to make myself some time for this.

There are no worries about that, andreiashu.
Already you gave a big help in this issue. Even if I have to adapt the patch you wrote for the code I am developing, your help is well appreciated, and I thank you for what you already did.

I fixed the division by zero issue for the DRUPAL-6--1 branch. The new tarball archive will be available between 12 hours.

I think that this solves a particular case, but the exhausted memory is in general caused by the site map being served from the cache Drupal uses for the pages; this means that the site map is loaded from a database table into memory, with the result that the memory becomes exhausted when the site map contains a large number of links.

Thanks, anyway, for pointing out this case.

I implemented a different way to cache the site map content, as suggested by andreiashu; it should resolve the memory issue too.

I am setting the report as fixed because it didn't get any feedback in more than 2 weeks. If the project modules are still causing memory allocation failures, feel free to re-open the issue.