php4-pgsql-4.3.11-1

[Jakub Bogusz]

On Sat, Apr 16, 2005 at 05:33:11PM +0200, Michał Łukaszek wrote:
> 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

So it's another issue...

> 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.

Could you provide self-contained testcase?
The above doesn't crash php without Smarty files.

> 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.

Confirmed this one. Predictably.

(gdb) bt
#0  0xb78a6978 in ?? ()
#1  0xb7f557da in plist_entry_destructor (ptr=0x81e11b8)
    at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:204
#2  0xb7f5385f in zend_hash_apply_deleter (ht=0x8052c50, p=0x81ec1a0)
    at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_hash.c:574
#3  0xb7f53ab0 in zend_hash_graceful_reverse_destroy (ht=0x8052c50)
    at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_hash.c:640
#4  0xb7f558f6 in zend_destroy_rsrc_list (ht=0x8052c50, tsrm_ls=0x804f0a0)
    at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:234
#5  0xb7f49c20 in zend_shutdown (tsrm_ls=0x804f0a0)
    at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend.c:714
#6  0xb7ef42d5 in php_module_shutdown (tsrm_ls=0x804f0a0)
    at /home/comp/rpm/BUILD/php-5.0.4/main/main.c:1518
#7  0x0804be1e in main (argc=2, argv=0xbffff174)
    at /home/comp/rpm/BUILD/php-5.0.4/sapi/cli/php_cli.c:1055
(gdb) f 1
#1  0xb7f557da in plist_entry_destructor (ptr=0x81e11b8)
    at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:204
204                                             ld->plist_dtor_ex(le TSRMLS_CC);
(gdb) p ld->plist_dtor_ex
$1 = 0xb78a6978
(gdb) x ld->plist_dtor_ex
0xb78a6978:     Cannot access memory at address 0xb78a6978

The list here is "persistent_list", which is used by php-mysql for
persistent connection - so it's probably bug in php-mysql module or php
engine itself.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/