ZF-8399: Zend_Db Query crashes on insert more than 358 characters

Issue Type: Bug Created: 2009-11-26T02:17:06.000+0000 Last Updated: 2012-05-12T03:24:43.000+0000 Status: Closed Fix version(s): Reporter: Robert Gies (rgies) Assignee: Adam Lundrigan (adamlundrigan) Tags: - Zend_Db

  • FixForZF1.12
  • zf-caretaker-adamlundrigan
  • zf-crteam-padraic
  • zf-crteam-priority

Related issues: - ZF-7911



On inserting more than 358 characters with insert sql on Zend_Db php crashes. My given sample works fine if you change number of inserted characters to 358. The crash is database adapter independent and can reproduct with Pdo_Mysql and Pdo_Oci.

On executing following code php crashes(tested on php 5.3):

<pre class="highlight">
$val = str_repeat('x', 359);
$sql = "INSERT INTO `test` (`test`) VALUES ('$val')";

$db = Zend_Db::factory(
    array('host' => 'localhost', 'username' => 'root', 'password' => '', 'dbname' => 'testdb')

Database schema to reproduce:

<pre class="highlight">
CREATE TABLE `testdb`.`test` (


Posted by Robert Gies (rgies) on 2009-11-30T00:13:30.000+0000

I have forget to say that the problem are on WAMP Systems. I have at moment no chance for testing on LAMP.

Posted by Benjamin Eberlei (beberlei) on 2009-11-30T01:06:10.000+0000

Fixed formatting

Posted by Mickael Perraud (mikaelkael) on 2009-11-30T13:04:15.000+0000

Test added with r19317 in trunk and r19318 in 1.9 release branch but cannot reproduce. Tested with PHP 5.2.8 et PHP 5.3.0 on Windows: Mysql 5.0.67 (with mysqli and pdo_mysql), SQLite, MsSQL and PgSQL. No equivalent field type for Oracle and Db2.

Could you be more precise on your environment? Or can you simply run Zend_Db tests on your environment?

Posted by Daniel Kreuer (dkreuer) on 2009-12-01T03:08:16.000+0000

After further analysis it can be said, that this is no error with Zend_Db in particular but may be an issue with the preg methods in PHP itself. The following test script caused the Apache/PHP process to die unexpectly (not all the time reproducable, not all the time with the given string length, not reproducable on every test machine):

<pre class="highlight">
$val = str_repeat('x', 342);
$sql = "UPDATE `test` SET `test` = '$val'";
$tmp = preg_replace("/'(''|\\\\{2}|[^'])*'/", '', $sql);

There may be other causes and side-effects leading to this crash behavior. Maybe a work-around without using preg-methods could be discussed.

This behavior is referenced in and too.

Posted by Michael Rehbein (tech13) on 2010-01-14T08:21:29.000+0000

Test segfaulting on Debian Lenny.

PHP 5.2.6-1+lenny4 with Suhosin-Patch (cli) (built: Nov 22 2009 02:38:03) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

libpcre3 7.6-2.1 Perl 5 Compatible Regular Expression Library - runtime files

Looks like they have fixed it for Debian, but not sure when the fix will show up in Lenny.……

Test passes on: CentOS release 5.4 Red Hat Enterprise Linux Server release 5.3

Posted by Marcus Kielly (sunwukung) on 2010-05-21T07:46:09.000+0000

I've also just encountered this error - with exactly the same sql count(358): trying to execute the following statement:

$db = Zend_Registry::get('db'); $sql = 'INSERT INTO table_name'; $sql .= ' (user_id,type_id,title,summary,description,keywords,categories)'; $sql .= ' VALUES ('; $sql .= '\'5539\','; $sql .= '1,'; $sql .= '\'Sample Title\','; $sql .= '\'Sample content\','; $lorem = '\'FROM ZEND PDO INSTANCE Lorem ipsum dolor sit amet, consectetur adipiscing elit. In et pellentesque mauris. Curabitur hendrerit, leo id ultrices pellentesque, est purus mattis ligula, vitae imperdiet neque ligula bibendum sapien. Curabitur aliquet nisi et odio pharetra tincidunt. Phasellus sed iaculis nisl. Fusce commodo mauris et purus vehicula dictum. Nulla feugiat molestie accumsan. Donec fermentum libero in risus tempus elementum aliquam et magna. Fusce vitae sem metus. Aenean commodo pharetra risus, nec pellentesque augue ullamcorper nec. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nullam vel elit libero. Vestibulum in turpis nunc. Donec aliquam dignissim nunc, eu condimentum tellus auctor ac. In hac habitasse platea dictumst. Integer auctor velit ac dolor semper et consequat risus tempus. Vivamus congue, purus vel imperdiet placerat, dui massa facilisis metus, ac consectetur orci dui nec lorem.\','; $sql .= $lorem; $sql .= '\'this,is,a,sample,array\',';//keywords $sql .= '\'category_title\'';//categories $sql .= ')';

//works $link = mysql_connect('localhost', 'opendoor', 'am93vH4UX5Zb') or die('Could not connect: ' . mysql_error()); mysql_select_db('new_supplier_bank') or die('Could not select database'); mysql_query($sql);

//works $pdo = new PDO('mysql:host=localhost;dbname=new_supplier_bank', 'opendoor', 'am93vH4UX5Zb'); $stmt = $pdo->prepare($sql); $stmt->execute();

//works $pdo = $db->getConnection(); $pdo->query($sql);

//works $db->getConnection()->exec($sql);

//FAILS $db->query($sql);

Environment: WinXP Wamp: Apache 2.2.11 PHP 5.3 MySQL 5.1.36

Posted by Mihai Bojin (mihaibojin) on 2010-08-20T06:20:20.000+0000

I just encountered this problem. I am doing large updates into a table with Zend_Db_Adapter_Pdo_Mysql, on a Zend Server CE 4.0.6, PHP 5.3.0, Zend Engine v2.3.0 running on MacOSX 10.6.4 and it just crashes with no error message (probably php segfault). After I found this post (btw thanks Marcus!) I switched from running $adapter->query("UPDATE ..."); to $adapter->getConnection()->query("UPDATE ..."); which works for all the big queries I was running.

Thanks again Marcus, I've been struggling to understand what was the problem for over 3 hours now...

Posted by Pawel Trauth (eithed) on 2011-05-16T13:25:20.000+0000

I've encountered similar problem with select statement which led me to debug that the problem lies within PCRE library used - for big regular expressions, aka [code]str_repeat('a',10000);[/code] line 205 in Zend/Db/Statement.php: [code]$sql = preg_replace("/$q($qe|\\{2}|[^$q])*$q/", '', $sql);[/code] causes segmentation fault within PCRE, caused by stack overflow. There's really no solution for this problem (or it's unknown to me), besides rewriting given expression to be less greedy, as reducing PCRE settings in php.ini results in receiving incorrect results (NULL instead of expected string). Apparently this issue appeared with update of PCRE to version 7.0, but as of PHP version 5.2.x it still persists. I hope this entry will spare a couple of hours debugging where the problem lies.

Posted by Pádraic Brady (padraic) on 2011-08-14T18:15:35.000+0000

Ralph, is there any update on this issue? From what I can tell it's restricted to Mac OS (and possible Windows) and will not be fixed at the PHP level. It is also marked as a Blocker issue which seems to be correct.

Posted by Benoît Durand (intiilapa) on 2011-08-26T17:16:58.000+0000

The test works fine with Mac OS and PHP 5.3.3.

Posted by Adam Lundrigan (adamlundrigan) on 2011-10-17T01:02:40.000+0000

Tests pass against trunk for me on both my test machines.

Machine 1: PHP 5.3.8-ZS5.5.0 (cli) (built: Aug 23 2011 09:15:05) Ubuntu 11.10 (3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux)

Machine 2: PHP 5.3.3 (cli) (built: Jan 28 2011 14:53:13) RHEL 5.5 (2.6.18-164.15.1.el5 #1 SMP Mon Mar 1 10:56:08 EST 2010 x86_64 x86_64 x86_64 GNU/Linux)

Posted by Adam Lundrigan (adamlundrigan) on 2011-10-17T01:04:28.000+0000

This is likely related to ZF-7911

Posted by Adam Lundrigan (adamlundrigan) on 2012-05-12T03:24:43.000+0000

This issue will be resolved at ZF-5063 and/or ZF-7911

Have you found an issue?

See the Overview section for more details.


© 2006-2021 by Zend by Perforce. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.