UPDATE - Bug found (kinda)

Uncreative

Calendar

Back May '12
Mon Tue Wed Thu Fri Sat Sun
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Quicksearch

Archives

Categories



All categories

Get Jimdo!

Get a free website with professional content management features at Jimdo.com!

UPDATE - Bug found (kinda)

Monday, August 21. 2006

UPDATE, 2:42a.m. - found the issue, seems to be some referencing stuff. Updated information in the extended entry. Last night I blogged about my frustration with a bug in my ActiveRecord implementation that caused Apache to segfault after calling the save() method (which, strangely enough, never occured on the first request after a fresh Apache restart, but on all subsequent requests). I had already given up on being able to find the bug and was thinking about a workaround - and that workaround seems to have identified the bug for me. But there's a catch. After internally building the correct SQL for the desired operation, a method named _executeQuery() is called, which looks up if there already is a previously used prepared statement object for this particular query. If there is, the existing object would be grabbed and simply executed again with the new bindings. If not, a new statement is prepared and written to the statement cache array. In my simple case where only one INSERT query had to be performed, that cache functionality was never used - yet, it caused Apache to segfault. I have rewritten the method so that it does not use prepared statements at all anymore. Now the question is: Is this a PDO bug or is it something else? Read on for the details.

This is the original method (executes nicely, but Apache segfaults after PHP shuts down cleanly):
  1.     protected function _executeStatement($sql, $bindings, $connectionName='default')
  2.     {
  3.         $this->_queryHistory[] = $sql;
  4.         if (isset(self::$_statementCache[$sql])) {
  5.             error_log('Reusing existing statement');
  6.             $stmt = self::$_statementCache[$sql];
  7.         } else {
  8.             $pdo = self::getConnection($connectionName);
  9.             error_log('Preparing new statement');
  10.             $stmt = $pdo->prepare($sql);
  11.             self::$_statementCache[$sql] = $stmt;
  12.         }
  13.         error_log('Executing with bindings: '.print_r($bindings, true));
  14.         $stmt->execute($bindings);
  15.         return $stmt;
  16.     }
  17.  
Here's how I do it now, without using prepared statements at all:
  1.     protected function _executeStatement($sql, $bindings, $connectionName='default')
  2.     {
  3.         $this->_queryHistory[] = $sql;
  4.         $pdo = self::getConnection($connectionName);
  5.         foreach($bindings as $field => $value) {
  6.             $sql = str_replace($field, $pdo->quote($value), $sql);
  7.         }
  8.         error_log('Executing query: '.$sql);
  9.         $stmt = $pdo->query($sql);
  10.         return $stmt;
  11.     }
  12.  
The new version works flawlessly. It's just... I'd really like to use prepared statements if I can. So the question is - can anyone see a problem with the above code, maybe some weird internal referencing problem that I somehow triggered, or is it just a PDO bug? I was able to reproduce this on two systems so far:
  • Ubuntu Dapper, XAMPP 1.5.3a (PHP 5.1.4, MySQL 5.0.21. Apache 2.2.2)
  • Gentoo (Unstable Branch), PHP 5.1.4-pl6 (PDO 1.0.2, PDO-MySQL 1.0.1-pl1), MySQL 5.0.24, Apache 2.0.59
As for the prepared statement problems with PDO and MySQL: I know about the emulation mode to work around the known problems. This is how I'm setting it:

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
 
Anything wrong with that? (and yes, the PDO version on Gentoo is too old to know that constant, I've added a check for that) If there's nothing obviously wrong with this code, I guess I'll have to ask the powers that be (in this case, maybe Dr. Evil :-))... UPDATED INFORMATION: Seems that writing about bugs in detail helps better understanding them... my assumption that it might be some internal referencing problem seems to prove correct: When I comment out the line where I put the statement object into self::$_statementCache, all is well. Looks like it's not a good idea to put a statement object that was created at instance level into a static property - maybe it somehow messes up the reference table in a way that PHP makes a seemingly clean exit but leaves some seriously messed up memory behind so that Apache crashes.... well, I dunno. Pure speculation, as I have no clue whatsoever about PHP and/or Apache internals. But at least now I know what not to do, so I can safely use pepared statements again - hooray! :-D
Posted by Markus in PHP, Programming at 01:21 | Comments (6) | Trackbacks (0)

Trackbacks
Trackback specific URI for this entry

No Trackbacks

Comments
Display comments as (Linear | Threaded)

Hello, Can you report a bug? Try to make a smaller script (CWAC-lite ;), it should help to figure the cause of this crash. One has been fixed recently in 5.2.0, related to a similar problems (wrong refcount).
#1 Pierre on 2006-08-21 03:22 (Reply)
that is a known bug introduced in pdo_mysql in 5.1.4 it should work fine both in 5.1.2 and 5.1.5
#2 Alexey Zakhlestin (Homepage) on 2006-08-21 13:21 (Reply)
For the other readers, Alexey meant this bug: http://bugs.php.net/bug.php?id=37445 Further investigation has shown, though, that my situation does not seem to trigger that same bug. I've now found out that this is actually something that only happens with APC activated. Turning it off yields no more segfaults. I'll file a bug for both APC and PDO, dunno which one is the culprit.
#2.1 Markus (Homepage) on 2006-08-21 17:43 (Reply)
Most probably the PDO one. At least that's the only segv I've got out of it so far.
#2.1.1 t3rmin4t0r (Homepage) on 2006-08-22 00:07 (Reply)
Hi Markus, Sounds like the same bug I blogged about on planet-php back in June. PDOStatements get destroyed in the wrong order - and in the wrong place - and (not surprisingly) they're not expecting this to be the case. http://blog.stuartherbert.com/gentoo.php/2006/06/29/investigating_a_pdo_segfault Best regards, Stu
#3 Stuart Herbert (Homepage) on 2006-08-21 16:41 (Reply)
I have now filed this as a bug for APC: http://pecl.php.net/bugs/bug.php?id=8526
#4 Markus (Homepage) on 2006-08-21 18:11 (Reply)

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA
 
 

Competition entry by David Cummins powered by Serendipity v1.0

Recent Comments

Dave Hall about Finding a date for the next Unconference
Thu, 12.02.2009 13:12
I am not sure I will be able t o make it on either weekend. Go for either weekend and I wi ll see if I am in the ar [...]
Ralfs Zend Framework und PHP Blog about A pragmatic approach to rights management
Tue, 20.01.2009 18:32
In den letzten Wochen sind in diversen englischsprachigen Bl ogs sehr interessante und teil weise recht ausfhrliche [...]
Lukas about A pragmatic approach to rights management
Tue, 13.01.2009 13:40
Well I am mostly at fault for the "complexity". I actually u sed pretty much all the advanc ed features in real worl [...]
Daniel O'Connor about A pragmatic approach to rights management
Mon, 05.01.2009 10:24
I agree completely: KISS. S ince rights management can be complicated, I find it works b est when you push it dow [...]
Hodicska Gergely about See you at the International PHP Conference 2008
Mon, 03.11.2008 23:58
Hi! Are you planing to share t he slides of your talk? TIA!
Ralfs Zend Framework und PHP Blog about See you at the International PHP Conference 2008
Sat, 25.10.2008 10:13
Am nchsten Montag (27.10.) beg innt die 14. Internationale PH P Konferenz in Mainz und luft bis zum Freitag (31.10.) [...]

Entry's Links

Referring links

Syndicate This Blog

Content license

Creative Commons License - Some Rights Reserved
Original content in this work is licensed under a Creative Commons License

Powered by

Serendipity PHP Weblog