Segfault in PHP - not sure bug or my fault

Postgresql 9.1, PHP 5.3.8, lighttpd 1.4.29, Suse 11.4 x64.

I’m trying to insert image converted with imagick to bytea field.


    $imagick->scaleImage(800, 1300, true);
    $this->_thumbnail = base64_encode($imagick); 
     
    # Save to Postgresql
    DECODE('{$image->getThumbnail()}', 'base64')

Some images work but others give me errors.


From lighttpd log:
2011-10-27 20:39:02: (mod_fastcgi.c.2566) unexpected end-of-file (perhaps the fastcgi process died): pid: 0 socket: unix:/srv/.../x.socket 
2011-10-27 20:39:02: (mod_fastcgi.c.3354) response not received, request sent: 45894 on socket: unix:/srv/.../x.socket for /index.php?, closing connection 

/var/log/messages:
Oct 27 20:39:03 linux kernel: [33328.101710] php-cgi[17873]: segfault at 7fffa8fbbf48 ip 00007fd590910ff6 sp 00007fffa8fbbf00 error 6 in libpcre.so.0.0.1[7fd590900000+35000]
Oct 27 20:39:03 linux postgres[29093]: [5-1] 2011-10-27 20:39:03 CEST x x LOG:  unexpected EOF in client connection

Do You have some idea what can cause a problem?

On 2011-10-27 20:56, xorock wrote:

> Do You have some idea what can cause a problem?

Nope.

However, even if your actions can trigger a segfault, it is still a problem
with that program: its devs need to correct that fault.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

It may be the external process that php-cgi invokes that is segfaulting so check that. Try executing the equivalent ImageMagick command on the same data.

Just used nginx with php-fpm to make sure it’s not spawn-fcgi but “2011/10/28 09:23:03 [error] 16020#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream.” When I insert just base64 encoded data to bytea field postgres never reported any error. Must be something with DECODE() function.

Could it be that the DECODE statement should be:

 
[LEFT]DECODE([/LEFT][LEFT]$image->getThumbnail()[/LEFT][LEFT], 'base64')

?[/LEFT]

Without apostrophes Postgres reports syntax error. Query is part of Zend_Db_Table and this particular column escaped with Zend_Db_Expr().

It was merely a guess :D. My comparison is from MySQL, php, html, where I made a mistake that looked like this.