For the reason of http://drupal.org/project/issues/search/linkchecker?issue_tags=PHP%20eva... it may be a good idea to catch this type of errors and skip them. I'm not the friend of catching exceptions, but it's better than having this issues in the queue again and again.

Comments

dalin’s picture

dalin
he/him
Primary language English
Location 🇨🇦, 🇲🇽, 🌍
commented

Just saw this in passing so I'm not sure of how you're implementing this. But if you're using drupal_eval() to render PHP content
http://api.drupal.org/api/function/drupal_eval/6
Then any PHP errors should just be returned as an error string.

gpk’s picture

gpk commented

Related:
#361171: How to debug cron stoppage problems with bad PHP content
#286263: Make search indexing smart to handle nodes wth php redirects

hass’s picture

hass commented
Version: 6.x-2.x-dev » 7.x-1.x-dev

Well, this is both related and shows that the problem can also be seen in other modules.

@dalin: I'm loading all page content with input filters. It's not me who is calling the drupal_eval(). This are the core input filters and they fail if they render two PHP nodes with a duplicate function name. I guess this can happen in node listings, too.

It became sooo quiet regarding this type of issues... has something changed in core I may missed? I have not tested for very long time. As D7 is based on PHP5, core may be able to use http://php.net/manual/en/language.exceptions.php logics to catch these type of issues.

hass’s picture

hass commented
Status: Active » Closed (works as designed)

Looks not like a recoverable error. We cannot catch these errors. :-(