php4-pgsql-4.3.11-1

[Michał Łukaszek]

Dnia sobota, 16 kwietnia 2005 11:21, Jakub Bogusz napisał:

> Try glibc 2.3.5 (present on ftp in ac-test).
> After upgrade I don't observe segfaults on exit, which used to happen

# rpm -q glibc php apache
glibc-2.3.5-0.1
php-5.0.4-2
apache-2.0.53-4

But I did some more testing. First of all I realized that the code I was 
talking about was actually using MySQL, not PostgreSQL ;-) (written long time 
ago) - but I found out that it's not the DB connection that kills php.

I was erasing parts of code, line by line, and I found out that lines that 
blow up php were those commented ones:

 $dir = dirname($_SERVER['PATH_TRANSLATED']);
 define('SMARTY_DIR', $dir.'/smarty/');
# require(SMARTY_DIR.'Smarty.class.php');
# $smarty = new Smarty();

To be more precise, it's the require line (when I commented just the line with 
object creation, it still failed). It's quite strange, because I use Smarty 
exentensively in other projects and everything works just fine.

What is even more bizarre, during my tests I encountered such behavior:
The code:
<?
 $link = mysql_connect('localhost', 'aaa', 'bbb');
 mysql_select_db('ccc', $link);
 if($link) mysql_close($link);
 echo 'I am still alive';
?>
works fine.
But when you change mysql_connect to mysql_pconnect:
<?
 $link = mysql_pconnect('localhost', 'aaa', 'bbb');
 mysql_select_db('ccc', $link);
 if($link) mysql_close($link);
 echo 'I am still alive';
?>
you get:
(no debugging symbols found)
I am still alive
Program received signal SIGSEGV, Segmentation fault.
0x40474180 in ?? ()
(gdb) bt
#0  0x40474180 in ?? ()
#1  0x40140ea1 in plist_entry_destructor ()
   from /usr/lib/libphp_common-5.0.4.so
#2  0x4013fa38 in zend_hash_clean () from /usr/lib/libphp_common-5.0.4.so
#3  0x4013fadc in zend_hash_graceful_reverse_destroy ()
   from /usr/lib/libphp_common-5.0.4.so
#4  0x4013889f in zend_shutdown () from /usr/lib/libphp_common-5.0.4.so
#5  0x400fc26e in php_module_shutdown () from /usr/lib/libphp_common-5.0.4.so
#6  0x0804acc9 in main ()
(gdb)     

This is so unpredictable that I don't know what to look for. I suspect that 
usage of lists if fscked up, so I blame glibc.

-- 
regards,
PriSM (Michal Lukaszek)