Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

<?php
    class test {
        public function __construct(array $values) {
            print_r($values);
        }

        public static function getInstance($db) {
            $result = $db->query("SELECT * from test");
            return new test($result->fetchArray(SQLITE3_ASSOC));
        }
    }

    $db = new SQLite3("test.sqlite", SQLITE3_OPEN_READWRITE | SQLITE3_OPEN_CREATE);
    $db->query("CREATE TABLE test (foo, bar)");

    test::getInstance($db);
    print "done";
?>

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

It's more helpful. I get the following messages in the Apache error log:
test/index.php(14) : Warning - SQLite3::query() [<a href='sqlite3.query'>sqlite3.query</a>]: table test already exists
test/index.php(3) : Catchable fatal error - Argument 1 passed to test::__construct() must be an array, boolean given, called in test/index.php on line 9 and defined
[Tue Mar 08 13:11:41 2011] [notice] child pid 26396 exit signal Segmentation fault (11)

Here's the stack trace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001015d0831 in zend_llist_del_element (l=0x10071c0f0, element=0x10208c258, compare=0x10109f549 <php_sqlite3_compare_stmt_free>) at /Users/bion/Downloads/php5.3-201103081730/Zend/zend_llist.c:97
97			next = current->next;

This is due the destructor order.

This bug is still reproducible, and in fact has regressed, since I no longer get a 
helpful console error message, but a generic crash report. What are the chances of 
getting this fixed?

I get a segfault whenever php-cgi exits even without using sqlite functions.

FreeBSD.  Latest Ports as of 1/12/2011

php5-5.3.8
php5-pdo_sqlite-5.3.8
php5-sqlite-5.3.8
php5-sqlite3-5.3.8
sqlite3-3.7.9


# /usr/local/bin/php-cgi -v
PHP 5.3.8 with Suhosin-Patch (cgi-fcgi) (built: Dec  1 2011 22:33:51)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
Segmentation fault
#

Editing extensions.ini to comment out sqlite3.so *and* pdo_sqlite.so  eliminates the Segmentation fault error.

With respect to: "This is due the destructor order."

I have tried many permutations of ordering in extensions.ini but found no case where enabling sqlite3.so or pdo_sqlite.so worked in any position.

Can not recompile with debug yet as this is a production machine... but will attempt to reproduce in test scenario and update.

Additional Info:  reducing extensions.ini to only sqlite3.so (no other modules loaded) also gave the Segmentation fault when executing /usr/local/bin/php-cgi -v

I was having the same problem.  Apparently it is due to the sqlite3 extension 
being threaded, but php not being compiled with the pthread library.  I was able 
to fix it in FreeBSD by recompiling php with the following option:

LINKTHR    Link thread lib (for threaded extensions)

This continues to haunt me

The issue is that ext/sqlite3 has circular references between
SQLite3 and SQLite3Stmt objects, and in case of "unclean shutdown"
(as caused by a catchable fatal error, in this case) the free
handlers are called in order of object construction in PHP 5.
Therefore the SQLite3 object is destroyed, but shortly thereafter
the SQLite3Stmt object tries to access it, which can result in a
segfault (and would be an invalid access, anyway).

As of PHP 7.0.0 the free handlers are invoked in opposite order
of construction, so at least with the given test script there are
no issues.

Anyhow, it seems to me that ext/sqlite3 should better separate
concerns by using dtors and free handlers (currently only free
handlers are used).

Since this issue does not affect PHP 7, and even extended support
for PHP 5 has ended, I'm closing the ticket.