Stuart Herbert | Gentoo

I’ve been playing about with using PDO to work with mysql. Something’s not quite right in there, and it’s resulting in a segfault when I run some local unit tests.

I’m not all that hot on PHP’s internals; I only tend to go digging in there when work needs a runkit bug diagnosing and fixing. But I’m pretty sure that what I’m seeing needs some TLC.

PDO objects themselves are created and destroyed when I’d expect them to be, as the objects go out of scope. The problem is that the PDOStatement objects aren’t doing the same. According to gdb, PDOStatement objects are only getting cleaned up when php_request_shutdown() runs; never before.

Surely we should be seeing PDOStatement objects being destroyed before their corresponding PDO object? The segfault is happening because php_mysql_stmt_dtor() is calling mysql_more_results() after the PDO object has been destroyed. We’re passing garbage data into the mysql client library … which chokes and segfaults as a result.

I think there’s two bugs here. The first problem is that PDOStatement objects appear to be persisting even though they’ve gone out of scope. php_pdo_stmt_delref() only gets called during php_request_shutdown(), never before. That doesn’t seem right to me. Why aren’t PDOStatements being destroyed when they go out of scope?

The second problem is that PDO objects are being destroyed before their corresponding PDOStatement objects. I couldn’t find (or, most likely, I didn’t recognise it any code that handles reference counting between PDO and PDOStatement objects. Maybe I’ve got it wrong, but I’d expect PDOStatement objects to add/subtract the corresponding PDO object’s reference counter, to ensure that PDO objects don’t get destroyed until all of their PDOStatement objects have been destroyed.

Anyone else got an opinion on this?