Error on sitemap generation: "An AJAX HTTP request terminated abnormally."

Same here

Similar issue here with the new version:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /batch?id=163&op=do StatusText: Service unavailable (with message) ResponseText: XMLSitemapGenerationException: Generated s3://xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM/2.xml resulted in an empty file. in XMLSitemapWriter->endDocument() (line 156 of /drupal/sites/all/modules/contrib/xmlsitemap/xmlsitemap.xmlsitemap.inc).

With version 7.x-2.0 I'm seeing the exact error given in #3 when I manually "update cached files" from admin/config/search/xmlsitemap. When I revert to 7.x-2.0-rc2 it works correctly again without any error.

I have only one sitemap defined and with the good version it generates only a 1.xml file. With the bad version it generates an empty 2.xml file as well and then throws an exception because the file is empty.

If I comment out the lines in xmlsitemap.xmlsitemap.inc that test for filesize() and throw the exception, it works fine again, resulting in only the 1.xml file.

I notice that xmlsitemap_regenerate_batch_generate() has code to "cleanup the 'extra' empty file", deleting the empty "2.xml" file in my case.

So one part of the code expects to generate an empty file and then remove it, and another part panics when it generates an empty file. SNAFU.

The last update has bug. Basing on the logic, the xml file cannot be generated at all.

To me, I just comment out one line to make it work. Hope next release will fix it.

File name: xmlsitemap.xmlsitemap.inc
Line: 156

if (!filesize($this->uri)) {
//throw new XMLSitemapGenerationException(t('Generated @file resulted in an empty file.', array('@file' => $this->uri)));
}

Just ignore (do not throw) the error. There is some logic to remove the empty file.

Even though the sitemap doesn't have any records, it shouldn't return an empty filesize() because it should have written XML headers, etc. I don't understand why this is causing an issue. Is everyone using Amazon S3? Maybe it doesn't return filesize() properly?

I am getting the same error. Everything was working fine until the latest update to the latest full release.

I can confirm that commenting out line 156 (as suggested in #6) corrects the problem and the xml file can be generated via the batch command and via general cron run.

Upgrading from 7.0-rc2 to 7.0, I got the same error.

@Dave Reid I'm not using Amazon S3.

I can confirm that #6 suggestion corrects the problem.

It works fine in my local test environment. Fails on the production site, which is on a shared host (Rackspace Sites).

Well, I'm running 7.x-2.0 and there's no line 156 anymore … but the AJAX HTTP error keeps my site from generating sitemap.xml files.
Reverting the release to rc helped the case, cron completes and xml is generated successfully …
Any hints how to fix this in 2.0?

TIA

subscribe, i have the same error with XML Sitemap 2.0 release!

Hi,
same problem here with 7.x-2.0.
I can confirm that the workaround suggested in #6 solved the problem.

Sitemaps get created again.

GoDaddy Hosting

PHP 5.3.24

#6 is a great workaround for the time being.

@David Reid I *am* using S3.

confirming the #6 worked for me as well.

also confirming; #6 is working nice.
drupal 7.12, on shared host php 5.2.5 msyql 5.0.19

#6 solved it for me as well. After three hours of trouble shooting this was a great find. Thank you!

Same here, #6 solved the issue.

Since this bug is not immediately noticeable (I discovered it because my cron stopped running some days ago), it could be really hard for the admin to find the "guilty" module.

What about raising bug priority and/or quickly release an update with just this temporary fix (#6)?

#6 solved the issue for me.
Thanks kamanwu.

Same issue here. Remove the exception solves the problem, but I'm not sure why "filesize()" fails. I'm running on php 5.3.28.

I have a same problem. Drupal 7.26 with list of popular contrib modules, PHP 5.2.17

I noticed the same issue (PHP 5.3.3) and tried running cron via Drush, which threw a similar error, but also included additional info: "zend_mm_heap corrupted" which might be addressed by increasing output buffering in your PHP settings, or upgrading to PHP 5.4+. So I wonder if it's some combination of somewhat older PHP versions, the output buffer settings, and the way the sitemap is generated. I'm going to try increasing the buffer size to see if it goes away. Anyone else tried this?

Edit: before I did anything to PHP I reverted to the 2.0-rc2, which solved the issue. Agreed the bug appears to have been introduced in 7.x-2.0. On another site with PHP 5.4.27, 2.0 works fine. Suggests the combination of v.2.0 and older PHP can cause this error.

The issue pointed out in #6 is caused because the XMLWriter's output buffer has not been flushed and written to the actual file yet, so filesize will always return 0, thus throwing the exception. This can be fixed by calling the parent flush() method before calling filesize().

A patch is attached.

#24 worked on my side, great!
The missing "buffer flush" explains why this issue doesn't happen on all systems (like my development machine).

Good work, thanks!

#24 works great!!

#24 is the solution, please commit to dev!

#24 works great for me.

#24 works great for me too!!!

#24 works great for me too!!!

Thanks for patch in #24, works like a charm!

#24 patch worked for me. Thanks!

Worked for us too. +1 for commit.

Worked for me as well. Please commit

10 users confirmed #24 is the right fix.

Hope it will be committed and released soon, because sometimes this could be a showstopper (think about cron runs).

#24 work also on 6.x-2.0 (manually patched of course)

#24 works for me too. I think it should be committed.

As indicated in #2292717: XMLSitemapWriter::endDocument() calls filesize() prematurely. I agree this isn't actually the proper fix. We should remove the checks to filesize instead since it's caused too many errors.

Hello all! I'm the author of the S3 File System module, and I dug deep into this problem when my users ran into the exact same error that bkonetzny referred to in #3.

The immediate problem is that XMLSitemapWriter::endDocument() should not be calling filesize($this->uri), because the file is not completely finished being written to the filesystem until after the XMLSitemapWriter object is destroyed. The reason it's been working without issue for most people is because of an implementation detail in local filesystems: writing the first chunk of data to a file results in the file being created on the disk, and subsequent chunks of data are also written directly to the disk (baring certain write caching mechanisms). This means the file begins to exist before the file handle is closed.

However, when using a remote filesystem like my module S3 File System, writing data to the file just caches it in memory. The file isn't written to S3 until the stream is flushed.

Unfortunately, the XMLWriter class from PHP, which XMLSitemapWriter derives from, doesn't flush the stream until the object's destructor method is called. Even calling the XMLWriter::flush() method doesn't actually flush the stream; it just pushes any leftover data into the write cache (or onto disk, if using a local filesystem).

What this all means is that when using S3 File System, or most other remote filesystems, calling the filesize() function before the XMLSitemapWriter object is destroyed will result in an error, because the file doesn't actually exist on S3 yet. And that's what results in the XMLSitemapGenerationException being thrown from XMLSitemapWriter::endDocument().

Normally, this would be mostly innocuous, because PHP is supposed to destroy an object when an uncaught exception is thrown from within one of that object's methods. But that isn't happening for some reason; so the XMLSitemapWriter object goes undestroyed, and the sitemap file is never written to S3 at all.

The solution from #24 didn't work for me, so I'm surprised that it did work for so many others. Perhaps newer versions of PHP change the XMLWriter::flush() function to make it actually flush the stream?

I've attached an alternate patch, which solves this problem by changing the location in which the filesize() function is called. It's now called after the manual destruction of the XMLSitemapWriter object, rather than from within XMLSitemapWriter::endDocument().

I can confirm that #40 patch solves this issue for me

worked well for me (#24)

#24 worked for me as well. Thank you!

#24 patch worked for me.

Do you include this patch in the next version of the module?

Thanks!

#24 works for me too on PHP 5.3.28

Both #24 or #40 worked for me on Drupal 7.28 / PHP 5.3.3

Re #40: xmlsitemap_generate_index() also needs to be changed, since it also calls endDocument().
I don't think changing the api like that is the correct way of handling this issue either.
Maybe the check for an empty file can simply be removed altogether?

xmlsitemap_generate_index() also needs to be changed, since it also calls endDocument().

Thanks for pointing that out. Not sure how I missed that... Anyway, here's an updated patch.

I also wish the filesize check could just be removed, but I figured that I didn't have the authority to do so. I don't really know why it's there, so it's entirely possible that it's very important.

hmm... it seems to me Dave said the filesize check could should be removed.

Here is a simple patch with the filesize check removed for both D6 and D7.

The patch in #24 stopped working for me - I had to use the one in #40....

I'm ok with #50.

#50 works for me.

#50 is working for me too.... on dozens of our clients' live sites.

#50 working for me as well. This has been RTBC for nearly a month now, would be nice to see it rolled into a dev release, at least.

#50 worked for me on Rackspace Cloud Sites, should anyone else be using that and having this problem.

Since:

a) this breaks generation of a sitemap, the basic function of this module, and
b) a solution has been RTBC ready to go for more than a month

I'm going to bump this to critical. If the maintainers need help, please let your community know! We want to support you, but some folks have done some work here and it would be nice to see it at least reviewed, if not committed, by maintainers.

I agree, and another point:

c) it breaks cron execution if the map is generated during a cron run

+1 for commit #50

Confirming that #50 resolves the issue for me as well.

Committed to all three branches, 6.x-2.x, 7.x-2.x, and 8.x-1.x.

Awesome, thank you!

Just tested and works, thanks.
Now I'll wait for a release.

I update the module on our live site with the -dev module from last week, but I still get the following error when I rebuild links:

An AJAX HTTP request terminated abnormally. Debugging information follows. Path: /batch?render=overlay&id=568&op=do StatusText: error ResponseText: ReadyState: 0

Reverting back to rc2 solved the problem.

I had the same issue - tried 7.x-2.0 and 7.x-2.x-dev on my site - resulted in the same empty file error, however the file was "1.xml" and it was indeed empty, even after a few minutes.

Reverting to 7.x-2.0-rc2 worked.

My site is on a cloud-based shared hosting (uses a clustered filesystem), running PHP 5.5.16, MySQL 5.6.20.

Re, my post #69: patch #24 worked perfectly on my setup.

I received a "fixed" alert from Drupal, and I haven't noticed that it was not really fixed but only marked as such because of inactivity. So I overwritten it with an old (not working) dev and cron broke again.

Patch #24 is the working solution on my side, +1 for committing it.

September 12, 2014 - 17:38: Latest 7.x-2.x-dev release.
September 12, 2014 - 17:42: Fix for this issue committed to 7.x-2.x.

Looks like Dave created a new dev release first and committed the fix after that. So unfortunately the fix is not in the latest dev release.

Latest dev release is 1 month old.
I think it's time for an updated one...

My xmlsitemap cron run forever, but the sitemap is actually generated in AmazonS3, also it do not update the local database that the sitemap is done.

Any idea ?

Many thanks
Keith

Can confirm that #24 patch solves the problem in Drupal 7.32 install. +1 for committing!

Just applied the patch in #24 to Drupal 7.32 with the latest -dev release of the module and it resolved the issue for me. Thanks.

#24 works. Drupal 7.32, XML sitemap 7x-2.0.

Looks like #73 is correct - this is not applied to the latest 7.x dev yet…
@Dave Reid - can we get a new release that includes the commit you already made?
Also this seems worthy of releasing an official 7.x-2.1 considering the module is really quite broken in it's current state.
Thanks to everyone who helped troubleshoot this.

Latest dev release already includes this. New release shortly anyway.

tried all patches in this thread and installed latest dev yesterday 23.01.2015 but the error still persists...

EDIT - turns out my issue was that I had migrated the site and the base URL in the Advanced Settings of XML Sitemap was still that of the previous site. I have seen this in other threads as a separate issue but just in case anyone else can't figure it out... I just had to update that to the new URL.