Sounds like a pretty nasty problem to me.

BTW, if you want a workaround, you can use parameters like this:

$stmt = $db->prepare("SELECT * from database where location like ?");
$stmt->execute(array(":memory"));

Doh.  Like this:

$stmt = $db->prepare("SELECT * from database where location like ?");
$stmt->execute(array(":memory:"));

hi wez!
thank you for your help! but!!
If i use parameters, this don't crash apache!! ok!
but if my table haven't record like the parameter (now not only '::memory') then that kill the PHP script!!
I've test it on beta2 and this work properly but with beta3 crashed.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Please provide a backtrace for both of those crashes

The two problem seem identical!
I've generate the backtrace!

#0  _efree (ptr=0x0) at /usr/src/php-5.1.0b3/Zend/zend_alloc.c:285
#1  0x4042f880 in free_statement (stmt=0x821ae24) at /usr/src/php-5.1.0b3/ext/pdo/pdo_stmt.c:1937
#2  0x40568d09 in zend_objects_store_del_ref (zobject=0x821ae24)
    at /usr/src/php-5.1.0b3/Zend/zend_objects_API.c:161
#3  0x405487f1 in _zval_ptr_dtor (zval_ptr=0x82184b0) at zend_variables.h:35
#4  0x4055ba6d in zend_hash_apply_deleter (ht=0x406c8c50, p=0x82184a4)
    at /usr/src/php-5.1.0b3/Zend/zend_hash.c:574
#5  0x4055bad7 in zend_hash_graceful_reverse_destroy (ht=0x406c8c50) at /usr/src/php-5.1.0b3/Zend/zend_hash.c:640
#6  0x40548e54 in shutdown_executor () at /usr/src/php-5.1.0b3/Zend/zend_execute_API.c:216
#7  0x40554433 in zend_deactivate () at /usr/src/php-5.1.0b3/Zend/zend.c:823
#8  0x4051d777 in php_request_shutdown (dummy=0x0) at /usr/src/php-5.1.0b3/main/main.c:1238
#9  0x405d7d94 in php_handler (r=0x8209c30) at /usr/src/php-5.1.0b3/sapi/apache2handler/sapi_apache2.c:443
#10 0x0807e86b in ap_run_handler (r=0x8209c30) at config.c:151
#11 0x0807edee in ap_invoke_handler (r=0x8209c30) at config.c:363
#12 0x0806d4cb in ap_process_request (r=0x8209c30) at http_request.c:246
#13 0x080691ec in ap_process_http_connection (c=0x82053b8) at http_core.c:250
#14 0x0808861b in ap_run_process_connection (c=0x82053b8) at connection.c:42
#15 0x0807d346 in child_main (child_num_arg=0) at prefork.c:609
#16 0x0807d45d in make_child (s=0x80be7e0, slot=0) at prefork.c:649
#17 0x0807d524 in startup_children (number_to_start=5) at prefork.c:721
#18 0x0807db8d in ap_mpm_run (_pconf=0x80ba0a8, plog=0x80f2188, s=0x80be7e0) at prefork.c:940
#19 0x08082fda in main (argc=2, argv=0xbffff7d4) at main.c:617

See also bug #33737

Please try using this CVS snapshot:

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

Seems to work for me with CVS HEAD.
Please try the snap dated after this message to confirm; a self-contained test case will help to really nail the problem if it persists.

Yes that perfectly works.
Thank you very much!
Fred

Marking as "closed" then.