Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
The function in question comment_load can return an object or FALSE. link checker does not see if the comment was loaded correctly, thus when clone gets ran against the Boolean FALSE clone fails.
@mikey: Do you have an idea how I can repro that comment_load() returns FALSE? I see it in the code, but I don't understand how it's possible to run into this except I'm loading invalid cids...? But how should this happen?
My guess is some sort of bulk operation that didn't invoke hook_comment_delete. The other option is the database got disconnected at the right time; something strange happened with an entity field cache. The error backtrace looks fairly odd in the report so I'm guessing that something unexpected happened on the server.
Re #6: I can support this hypothesis. While tracking down several unexpected and seemingly unrelated fatal PDO Exceptions on the primary key front, I found that the Feeds module -- and now I am speaking technically -- had "gone haywire". For reasons unknown to me it had been stepping all over the {node} and other related DB tables by inserting rows totally unrelated to actual site content. I used Feeds a while ago to import some D6 data, but don't need it now. Now that Feeds has been uninstalled and the DB cleaned up to remove its unwanted handywork, the PDO Exceptions problem as well as the issue reported here has gone away, AFAIK.
Comments
Comment #1
mikeytown2 commentedMoving this to the link checker module as the trigger point is inside of it
http://drupalcode.org/project/linkchecker.git/blob/695417fe05f7d01f5266f...
The function in question comment_load can return an object or FALSE. link checker does not see if the comment was loaded correctly, thus when clone gets ran against the Boolean FALSE clone fails.
Comment #2
Anonymous (not verified) commentedPertains to Link Checker 7.x-1.0.
Comment #3
hass commentedSame could happen in:
Comment #4
hass commentedComment #5
hass commented@mikey: Do you have an idea how I can repro that comment_load() returns FALSE? I see it in the code, but I don't understand how it's possible to run into this except I'm loading invalid cids...? But how should this happen?
Comment #6
mikeytown2 commentedMy guess is some sort of bulk operation that didn't invoke hook_comment_delete. The other option is the database got disconnected at the right time; something strange happened with an entity field cache. The error backtrace looks fairly odd in the report so I'm guessing that something unexpected happened on the server.
Comment #7
Anonymous (not verified) commentedRe #6: I can support this hypothesis. While tracking down several unexpected and seemingly unrelated fatal PDO Exceptions on the primary key front, I found that the Feeds module -- and now I am speaking technically -- had "gone haywire". For reasons unknown to me it had been stepping all over the {node} and other related DB tables by inserting rows totally unrelated to actual site content. I used Feeds a while ago to import some D6 data, but don't need it now. Now that Feeds has been uninstalled and the DB cleaned up to remove its unwanted handywork, the PDO Exceptions problem as well as the issue reported here has gone away, AFAIK.
Comment #8
hass commentedPatch attached.
Comment #10
hass commentedFixed comments
Comment #12
hass commentedComment #14
hass commentedHeck... file name troubles? Reattaching with changed file name.
Comment #15
hass commentedComment #17
hass commentedThis applies all cleanly. Broken bot.
Comment #18
hass commentedNew patch
Comment #19
hass commentedD7: http://drupalcode.org/project/linkchecker.git/commit/91502fb
Comment #20
hass commentedComment #21
hass commentedPatch attached
Comment #23
hass commentedComment #24
hass commentedhttp://drupalcode.org/project/linkchecker.git/commit/983ba26