500 errors (impossible to open nodes)

I can confirm this bug also happens on 5.x-1.4.

Any known workarounds / fixes?

Please provide more information. Unless I can reproduce this, I cannot do anything about it. Try checking if this is happening with older releases of Quote as well.

I can reproduce the problem with this setup:

• Drupal: 6.12
• Quote module: 6.x-1.1-beta2
• MySQL: 5.0.82
• Memory limit PHP: 32M
• PHP: 5.2.9
• Web server: Apache/2.2.11 (FreeBSD) mod_ssl/2.2.11 OpenSSL/0.9.8e DAV/2 SVN/1.6.2 PHP/5.2.9 with Suhosin-Patch
• Web browser: Firefox 3; also Wget.

This problem was not present before upgrading. The old setup was Drupal 6.5 and Quote 6.x-1.1-beta (1.2.2.2.2.1 2008/03/28)

I'll describe how I can reproduce it.

Let's call this piece of text 'D':

[quote]
01.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
02.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
03.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
04.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
05.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
06.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
07.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
08.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
09.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
10.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
11.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
12.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
13.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
14.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
15.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
16.......0.........0.........0.........0.........0.........0.........0.........0.........0.........0
17.......0.........0.........0.........0.........0.........0.........0.........0.........0abcd
[/quote]

If we remove the last 'd' character, let's call the resulting text piece 'C'.

So, C and D start and finish with the quote tags, and have 17 intermediate lines. 16 of them have 100 characters. C has another line with 93 characters, and D has instead a line with 94 characters. Of course there are also the carriage return characters.

I create a node and put the text D in the body. When trying to Preview the node, Apache crashes and shows this message:

[Sat Jun 13 22:37:00 2009] [notice] child pid 42018 exit signal Illegal instruction (4)

The user browser obviously shows a blank page, because the server crashed before returning the response. Instead of Preview, I can Save the node: once saved I can not View it (no matter what webbrowser), as the server crashes in the same way.

Other attempts:

• If body has text C, the server doesn't crash, so I can Preview, Save and View.
• If body has: some lines, then the text C, then other lines: no crash.
• If body has: some lines, text C, other lines, text C, more lines: no crash.
• I finally tried: some lines, C, C, C, C, more lines, C: no crash!

It seems the problem is only when the content of one Quote exceeds some limit. In my case it was:
(16 lines * 100 chars) + 93 chars --> 1693 + carriage returns.

The problem is 100% reproducible in my case (this is good :). I solved temporarily by disabling Quote. If you need more details or want me to test some proposed change or debug code, please tell me.

If you suspect the problem may not be in Quote, but in Drupal/PHP/Apache, you could tell me what other Drupal modules/PHP code I could test to see if they suffer the same problem than Quote.

PD: I don't remember seeing any problem running cron, either automatically or manually.

Dear Drupal friend

I am having exactly the same problem with latest
downloadbale Quote module and latest Drupal 6.12

The node does not show up after we put quote
of certain lengths like above. The node shows up
when quote filter is disabled.

Dear Badlop

I am trying a workaround.
Can you please test it and see if
it works?
Can anyone say whether it will
cause any crash or problem?

Step 1

Find this line in quote.module

$form['comment_filter']['comment']['#default_value'] = '[quote='. $author
make it
$form['comment_filter']['comment']['#default_value'] = '[quote='. $authors

Step 2

In comment.tpl.php

add just before print $content;

$content  = str_replace("[quote=]", "<img src=quote.gif>", $content);
$content  = str_replace("[/quote]", "<img src=quote.gif><br/>", $content);

Ronia,

I tried your proposed workaround. Unfortunately, in my case it doesn't provide any benefit: the blankpage and apache crash continue to appear when viewing a node with a Quote with large content.

PD: In a previous comment I wrongly said that Cron was running correctly for me. In fact, Cron doesn't run correctly when Quote is enabled.

Dear badlop

I forgot to tell you that while trying the above
you must disable the Quote filter
at Site configuration › Input format

However, if even cron is not working
and considering Quote is very
essential feature I wish
some developer acted really
fast on this.

Michelle says there is no such problem. See http://drupal.org/node/497838#comment-1727256

I still continue to have same problem as you Badlop.

No, Michelle said she uses Quote with no issues, but she does not use TinyMCE, she uses BUEeditor (as do I). Most likely the combination of TinyMCE and Quote is the issue (or some other module you may have installed).

Dear Keyz

I do not use TinyMCE, not even BUEeditor.
Nothing.
Just latest core Drupal + Latest Quote (and no other module)
gives the error as in http://drupal.org/node/422038#comment-1699438

It is always reproducible.
Kindly check it.

It is always reproducible.

Nope. I had no problems putting that text in a node: http://socnet.shellmultimedia.com/forums/test-quote

I also had no problems doing massive quoting of quoting of quoting: http://socnet.shellmultimedia.com/node-610-forum#comment-8802

I have never run into any problems with quote, outside of my users deleting the opening quote tag on a regular basis. ;)

Michelle

That is very useful info. Is it possible to know which versions of Quote
and Drupal Shellmultimedia is using ?
Apparently no problem with previous versions.

Drupal 6.12, Quote 6.x-1.1-beta2.

Michelle

I've run into this recently, and think it may be related to this PHP bug:

http://bugs.php.net/bug.php?id=48501

which was fixed in PHP 5.2.9 and 5.3.

Downgrading to beta 1, which removes the call to preg_replace_callback, fixes the issue on php 5.2.4.

Same problem.
module causes php falling down into segfault
downgrading to 5x-1.3

Please specify the version of PHP that you are running.

I am not seeing this with D6-dev, Quote 6.1-dev and PHP 5.3.2
or with
D5-dev, Quote 5.1-dev and PHP 5.1.6.

Regardless of the version, please update your PHP installation and try again.

Similar issue here:
Drupal: 6.17
PHP 5.2.9
development environment Win XP (XAMPP 1.7.1, Apache 2.2.11)

With the quote.module filter enabled pages containing [quote] tags crash apache. This is similar to another problem I was having with a regular expression. When enabling css optimization all pages would fail on my test environment, but run properly on my production server. This post discuses the issue and finally finds a solution after one year and 163 comment: http://drupal.org/node/444228

The resolution was to improve the regex in drupal_load_stylesheet_content() in common.inc. It was causing problems on certain setups.

Maybe the regex could us some improvement?

$text = preg_replace_callback('#\[(quote.*?)]((?>\[(?!/?quote[^[]*?])|[^[]|(?R))*)\[/quote]#is', '_quote_filter_process_callback', $text);

Is that a patched 5.2.9 or can you upgrade to the latest stable and recheck?

-K

It's what came with XAMPP, and I'm not too knowledgeable about XAMPP so I fear it. I spent part of yesterday and the day before just getting XDebug to work on Netbeans, so I'm not sure my constitution is up for trying to upgrade this finicky thing very soon.

However, I will be putting this up in a sub-folder on my production server soon, which has an undated version of php.

Update:
I uploaded this same setup to my production server, running php 5.2.3, and it runs that filter fine.

Is this bug similar to what is described here do you think? http://bugs.php.net/bug.php?id=48153

Same bug for me (php 5.2.13).

I have replaced
$text = preg_replace_callback('#\[(quote.*?)]((?>\[(?!/?quote[^[]*?])|[^[]|(?R))*)\[/quote]#is', '_quote_filter_process_callback', $text);
to
$text = preg_replace_callback('#\[(quote[^\]]*)](.*)\[/quote]#is', '_quote_filter_process_callback', $text);

in _quote_filter_process function and it works OK now. BTW, I don't understand actually why recursive regexp is needed here. Because of regexp greediness it will catch the outer quote without problem. In case of errors with quote tags - recursive regexp will not fix'em by itself anyways. ;-)

I ran into this with drupal 6.19, php 5.3.3-1ubuntu9 (standard ubuntu 10.10 server LAMP).

I have two test cases, one using drupal and one with just php:
Put any of the following in a php file in the root drupal directory and run it via the browser.
Then look in the apache error.log to see the segmentation fault.
You can also run the php test case from the php command line, since it doesn't use drupal.

It's clearly a php bug, but perhaps quote can bypass it by simplifying the way it filters quotes? A single problematic comment stops search indexing in its tracks.

---------------------------- drupal test case ---------------------------------------

include_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

function create_text()
{
  $text = '[quote=name]';
  for( $i = 0; $i < 50000; $i++) $text .= 'a'; // threshold seems to be around 24218
  $text .= "[/quote]";
  return $text;
}

$text = create_text();
_quote_filter_process($text);

echo 'ok';

---------------------------- php test case ---------------------------------------

function create_text()
{
  $text = '[quote=name]';
  for( $i = 0; $i < 50000; $i++) $text .= 'a'; // threshold seems to be around 24218
  $text .= "[/quote]";
  return $text;
}

$text = create_text();
// the following regex is so twisted, it doesn't even format correctly in the drupal.org comment preview.
// get your own from quote.module:

$text = preg_replace_callback('#\[(quote.*?)]((

\[(?!/?quote[^[]*?])|[^[]|(?R))*)\[/quote]#is', 'replace_callback', $text);

function replace_callback($matches) {
return 'x';
}

+1

Could users who are experiencing this bug please check if the regex fix in #24 helps ?

Facing the same issue here. On many pages with comments using quote tags Internal Server error is occurring. And it only happens when Quote filter is placed higher than BBCode filter. If I rearrange it below BBcode filter then all the pages open just ok, but quoted comments look ugly. When placed above BBcode filter some pages look correctly just as desired, however as said above some other pages give 500 Internal Server Error.

My environment is:

---
MySQL database 5.1.50
PHP 5.2.14
PHP memory limit 128M
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Update notifications Enabled
Web server Apache
---

Solution offered in #24 causes WSD.

Actually, apparently it has nothing with order of the filters - I have disabled first BBcode and then, with the same state of error, all other filters leaving the Quote filter active alone and still having 500 Internal Server Error. Disabling Filter module or filter makes the error gone, but since way too many nodes and comments on my site have been composed using the Quote module, I badly need it and I badly need this issue to be solved. So if the maintainer does not mind I put it back to active and mark priority as critical as it really is for the Drupal websites, which rely on this module.

Have you read thread above? Please, try and review patch from #24. Maybe it will be commited sooner...

skylord, in the finishing part of #28 I stated, that solution offered in #24 causes WSD. It does not help.

I am having same problem with 6.x-1.1. I don't think it is anything to do with any of the editors (I use FcKEditor) because the comment is created perfectly ok and exists in the database; the problem occurs when the node is displayed (and does not display properly).
Having looked at the content of the comment in the database, I could see nothing odd about it. There is some very basic formatting (HTML paragraph and bold or italic tags but that is about all I think). It was enough to remove the quote tags from the database entry for everything to display correctly. I have a lot of other comments using quotes in the system and have not come across this problem before.
Could it be something to do with the length of the quote?
I suspect that my users are putting in the quote tags by hand rather than using the "Quote" link but I don't see why this should make a difference.

By the way, this issue is not necessarily causes cron jobs to halt. My cron.php is running perfectly well, but activating quote module causes 500 errors on some pages.

The solution in #24 does only work if the comment has one quote, and does not handle nested quotes.

I rewrote the _quote_filter_process function to not use backtracking within regexp, as it seems to be limited (as said in #25 - it seems limited to 7366 chars on my machine).

The new function works with multiple quotes and handles nested quotes. Please review the patch attached.

@yngens:
Cron job is halted when the search module tries to index nodes with comments containing large quotes, at least with apachesolr installed.

Bingo, mauritsl! Your patch does the job, now everything looks correctly, all the 500 errors are gone. Thank you!

Same problems here.

; $Id: quote.info,v 1.2.2.2.2.1 2008/03/28 22:59:59 karthik Exp $
name = Quote
description = Allows users to quote posts or comments.
core = 6.x
dependencies[] = comment

; Information added by drupal.org packaging script on 2010-11-14
version = "6.x-1.2"
core = "6.x"
project = "quote"
datestamp = "1289729170"

Ubuntu 10.4, reverted to php 5.2 (first Canonical big fail)

Drupal 6, Apachesolr 1.9

The system hangs on cron, the only things i can see is this:

Dec 14 22:48:18 Ubuntu-1004-lucid-64-minimal kernel: [612978.578642] php[23141]: segfault at 7fff88f69ff8 ip 00007f9044e3da42 sp 00007fff88f6a000 error 6 in libpcre.so.3.12.1[7f9044e2d000+2d000]
Dec 14 22:48:23 Ubuntu-1004-lucid-64-minimal kernel: [612984.197021] php[23196]: segfault at 7fff6878deec ip 00007f45bb671a52 sp 00007fff6878de90 error 6 in libpcre.so.3.12.1[7f45bb661000+2d000]
Dec 14 22:50:53 Ubuntu-1004-lucid-64-minimal kernel: [613134.079479] php[23854]: segfault at 7fffc71d1e7c ip 00007f1a25055a52 sp 00007fffc71d1e20 error 6 in libpcre.so.3.12.1[7f1a25045000+2d000]

So the problem is "libpcre.so.3.12.1", so i installed " libpcre-dbg" and with gdb i have this result:

(gdb) run /home/deploy/drush/drush.php -l suse core-cron
Starting program: /usr/bin/php5 /home/deploy/drush/drush.php -l suse core-cron
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff14ac710 (LWP 25263)]
[Thread 0x7ffff14ac710 (LWP 25263) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6931a52 in match (
    eptr=0x4ac9327 "                \n        Kernel driver in use: pcieport-driver    &nbs"..., ecode=0x3e5ba24 "\035[Y",
    mstart=0x4ac4c6b "[quote]:~> /sbin/lspci -v\n00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)\n        Subsystem: Acer Incorporated [ALI]"..., offset_top=4, md=0x7fffffff14c0, ims=5,
    eptrb=0x7fffff5ff370, flags=0, rdepth=18106) at pcre_exec.c:431
431 pcre_exec.c: No such file or directory.
 in pcre_exec.c

So it's a library bug, seems that a lot of people are posting this kind of bugs with this library version that Canonical with Ubuntu 10.4 needs to support for 5 years....wonderful.

This is my bug report to Canonical:

https://bugs.launchpad.net/debian/+source/php5/+bug/407248?comments=all

Finally, i've found this patch and it works like a charm, thank you man, you rocks!

Another lesson learned, not use anymore Ubuntu server.

will a patch in #34 be committed?

The following are the three setups that I have tested quote on:

CentOS 4.8 + PHP 5.2.16 (with some backports from 5.3.x)
Ubuntu (lucid) + PHP 5.3.2 (stock)
Windows XP64 + PHP 5.2.14 (stock)

While testing, I have created nodes, quoted them. I have added comments and quoted them. I have tested multiple quotes, nested quotes and all have passed. I have executed cron jobs with the search module enabled.

I have thus far been unable to reproduce this error. Until I can, I am hesitant to commit anything. In the meantime, I will add a note on the project page pointing to this patch.

Thanks for all your efforts with this.
-K
P.S. leaving as RTBC.

Note that it's the amount of text which causes problems. The size at which problems occur differs per system (mentioned thresholds differs from 7366 to 24218 characters).

Ack.

I just spent some time tracing a cron segfault, and got to quote.module in the end.

As it turns out, I just imported a phpbb forum into a Drupal site - and some guy used to post complete news articles on that phpBB forum, which he puts between [quote] tags. The segfault occured for a 10kB quote.

After applying the patch, the problem is gone.

Got the same problem on nasty/large quotes with drupal 6.x
Patch #34 is working for me, testing it.

Patch #34
If there are multiple quotes, for example, first quote with author, second quote without, using Patch #34 it puts first author as author of next quote.

Good catch. I have attached a new patch to fix this problem.

Subscribing

The problem is most likely caused by PHP bug, that was already fixed. I have this problem on D5 site with old PHP version, and don't see it with a copy of the same site on more recent PHP version.
So the first step to deal with this problem is to upgrade to the latest PHP version (it's 5.2.17 for 5.2.x atm).

However, it's still important to deal with over-quoting, but I'm not sure if it should be dealt with in this issue or a separate one.

Unfortunately I do not think it has been fixed in PHP. (Unless you can point to documentation for the fix?...)

I just ran into this (very annoying to trace!) bug again. The live site is on PHP5.3.10 and produces this 500 error on one certain page, where a user had made a long post starting with a [quote] tag and not adding a closing tag anywhere. (Yeah, users do these things.)
After the patch, the page gets displayed correctly.

My dev machine is also on PHP5.3.10 and did not generate a 500 !? I don't know the difference. (Well, different operating system and probably some different settings. memory_limit is the same.)

---

2 other things:
* a casual review suggests that this also fixes a tiny issue in the 'nested level' handling for the D7 module: before the patch, it would not handle several nested quotes at the same level correctly? (e.g. 2 quotes pieces below each other, inside a bigger quote.) I didn't test that.

* There's a little behavior change: before the patch, the un-closed "[quote]" tag would be printed as-is. After the patch, it gone

...awww.... I guess I'm gonna do something about that. But that won't be for today.

Ah. I redid the code to not throw away any text when there were unmatched 'quote tags'.

As a side effect, the code

• never calls a preg() function on the same code twice anymore;
• does not recurse anymore.

So there are more lines of code (big if/else constructs) but I guess it's faster. And commented ok.

As a reference, here's the extreme example I tested with:

[quote=unmatched1] text 1
[quote=unmatched2] text 2
[quote=matched1]text 3
[quote=matched2]text 4
[/quote][/quote]

And one more:
[quote=unmatched3] text 5

There's a difference between the original code and my patch; see screenshots if you want. I think it's fine.
But the patch in #34/44/47 would output only:

text 5

No patch for D6 attached. It's easily portable -- but I'll only test it after people actually set RTBC / include in the D7 module.

@roderik: Would it be possible to supplement this patch with a pertinent (D7) Test along with details of your live and dev boxen? I'm not keen on refactoring this to fix a symptom and would prefer to nail it down right. Your mention of a missing closing tag is interesting.

Thanks,
-K

@Zen: what condition would such a Test test for? "PHP doesn't segfault"?

I remember many moons ago when I encountered this on D6, PHP segfaulted. See also #10.

Unfortunately, 'my live server that gives a 500' is not actually my server. (I'm usually subcontractor for other web companies, and this site runs on shared hosting at Byte.nl. These people are technically capable and responsive, but don't allow me to see everything on their server from my lowly SSH account. I haven't been able to get an entry in an Apache/PHP error_log either, for this '500' I'm getting.)

All I know is it runs Apache + PHP 5.3.10-1byte1 (CGI) (yeah, I know, self compiled PHP doesn't look too trustworthy in this case...)

My dev 'server' that doesn't give errors is a MacBook pro + MacPorts Apache / PHP 5.3.10 (FPM).

.... I can live with waiting until someone else finds this behavior on D7...

Test: It could be a test for "extra long, heavily nested quotes" as that appears to be the conditions necessary for the failure. If it's possible, perhaps you could run the test on the live server or on a dev site on the same server. If not, then others who are facing the same issue could perhaps do so.

I will look into backporting the tests to D6 if need be. They are very rudimentary at the moment in any event.

Cheers,
-K

#1: quotes do not need to be heavily nested, just extra long. I had this with a text that consisted of an opening quote + 8k of text (without closing quote).

-----
#2
I need to explain my first sentence in #50, in order to make sure I myself understand this.

You either mean "change your patch to test whether quotes are extra long, and if so, execute your code -- otherwise execute the current code".

...or you mean SimpleTest stuff.

In the last case:

A Test is essentially a PHP process running a certain action, and then afterwards testing whether its outcome is 'good' or 'bad'.

In this case, the PHP process would interpret a quoted string, and then afterwards any outcome is OK (i.e. PHP is still running) or the PHP process itself has died/segfaulted.

I'm assuming that the test bot maintainers won't be happy with you, if you are devising a test whose purpose is to kill PHP -- i.e. to break the test bot. Or am I wrong and is the test bot some setup which catches & reports child PHP processes dying? (I don't have experience with tests yet.)

Yes, a simpletest is what I mean. No, using the test bot to detect errors is what it's there for. Besides this appears to only affect people with particular configurations and the tests will very likely be run locally on their servers rather here.

Some users have mentioned nested quotes while others have mentioned extra long quotes. Separate tests might be the way to go with size and level of nesting perhaps being variable or decided by those who are experiencing these errors.

Cheers,
-K

No, using the test bot to detect errors is what it's there for.

Maybe I sound anal but I want to be sure about this, and your answer leaves room for interpretation.

You see the big difference between 'errors' and 'PHP segfaults' and you assert that the testbot is also there to detect the latter?

and the tests will very likely be run locally on their servers rather here

OK - I guess I just need to properly read up on all usages of Tests, to understand the background better.

The patch in #44 seems to have fixed the problem for D6. In my case, it was a longish (about 16,000 character) post being quoted that was causing the 500 error. But with the patch it didn't throw any error. Thanks!

Thanks, Roderik,
#48 fixed the problem (D7, quote 7.x-1.1-beta2).

I suspect that this issue is related to #1448504: Undefined index: de in _quote_get_quoted_data() or needs to be considered for merger into a single patch. They're both potentially related to the $language variable, and as noted in #18 of #1448504: Undefined index: de in _quote_get_quoted_data() this issue can persist after the #48 patch here.

The following patch merges the latest patches from #422038: 500 errors (impossible to open nodes) and #1448504: Undefined index: de in _quote_get_quoted_data(), producing the existing (working but not ideal, still causing unwanted paragraph tag wrapping in WYSIWYG editor) behavior on forum topic nodes, even if the node is an OG Group Content type with a group ID associated with it.

The patch applies to the original quote-7.x-1.1-beta2 quote.module file.

I am using 6.x-1.x-dev. The patch in #47 was really helpful. I had 5 nodes that were causing errors which were immediately cleared by applying the patch. I ran checks against the 8743 nodes that weren't causing errors to compare the output before and after applying the patch and I had 6 nodes where the output was different before and after. The patch I am supplying resolved the differences for those few nodes.

I can confirm that this bug was responsible for causing the re-indexing of my sites content to break as well as the problem nodes not being displayed.

Here is the snippet of code I used to run the comparisons before and after. You need to apply this patch and then copy the old functions to quote.module renaming them so they don't clash function names:

/**
 * Replace [quote] tags with markup for display.
 *
 * @param $text
 *   The text with the [quote] tags that need to be replaced with HTML tags.
 *
 * @return $text
 *   Filtered text.
 */
function _quote_filter_process_old($text) {
  if (stristr($text, '[quote')) {
    // Single regexp with callback allowing for theme calls and quote
    // nesting/recursion with regexp code from
    // http://de.php.net/manual/en/function.preg-replace-callback.php#85836
    $text = preg_replace_callback('#\[(quote.*?)]((?>\[(?!/?quote[^[]*?])|[^[]|(?R))*)\[/quote]#is', '_quote_filter_process_callback_old', $text);
  }

  return $text;
}

/**
 * Generate and return the quote theming for a quote occurence found by
 * _quote_filter_process.
 *
 * @param $matches
 *   The RegExp matches (for author and quote) found in _quote_filter_process.
 *
 * @return $output_quote
 *   Themed quote.
 */
function _quote_filter_process_callback_old($matches) {
  $quote_author = trim(substr($matches[1], 6));
  $quote_content = _quote_filter_process_old($matches[2]);

  $quote_output = theme('quote', $quote_content, $quote_author);

  return $quote_output;
}

Then enable the devel module and visit /devel/php and use the following code snippet to run your comparisons:

$offset = 0;
$limit = 1000;

// If you identify the nids which are erroring add them here.
$problem_nids = array();

$nids = array();
$result = db_query("SELECT n.nid, nr.body FROM {node_revisions} nr JOIN {node} n ON n.nid = nr.nid AND nr.vid = n.vid WHERE nr.body != ''" . (!empty($problem_nids) ? ' AND n.nid NOT IN (' . implode(',', $problem_nids) . ')' : '') . " ORDER BY n.nid ASC");

while ($row = db_fetch_object($result)) {
  $nids[$row->nid] = $row->body;
}

dpm('Total: ' . count($nids));

if ($limit > 0) {
  $nids = array_slice($nids, $offset, $limit, TRUE);
}

$success = array();
$fail = array();

foreach ($nids as $nid => $body) {
  $before = _quote_filter_process_old($body);
  $after = _quote_filter_process($body);
  if ($before == $after) {
    $success[$nid] = array($body, $after);
  }
  else {
    $fail[$nid] = array($body, $before, $after);
  }
}

dpm($success);
dpm($fail);

Adjust the offset to run for the next batch of nodes. And add problem node ids to the $problem_nids array as you identify them.

I've committed a different patch. Please test and reopen if needed.

-K

@Zen

I don't have time to review at the moment. I was in the middle of task when I undertook the testing last time round. Would it trouble you to explain what testing that you carried out in order to be confident that this could solve the problem? It's such a minor change that you made.