Opened 7 years ago

Closed 7 years ago

#111 closed defect

xcache 1.2.0 and 1.2.1 break php 4.4.7 is_a() call

Reported by: kamikaze Owned by: moo
Priority: major Milestone: 1.2.2
Component: cacher Version: 1.2.1
Keywords: php is_a segfault php4_is_broked Cc: nleippe@…
Application: xcache PHP Version: 4.4.7
Other Exts: SAPI: Irrelevant
Probability: Always Blocked By:
Blocking:

Description (last modified by moo)

create a file is_a.php with contents:

# cat > is_a2.php <<EOF
<?php
class A {};
class B extends A {};
class C extends B {};
$b =& new B;
$c =& new C;
echo is_a($c, 'B');
EOF

# php -v
PHP 4.4.7-pl0-gentoo (cli) (built: May 24 2007 10:39:17)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
    with XCache v1.2.1, Copyright (c) 2005-2007, by mOo

# php is_a.php
Segmentation fault

# php -n is_a.php
1

With xcache, it always works, with xcache enabled, it usually breaks.
Sometimes after moving the file it works the first or second time before
breaking. Sometimes not.

/etc/php/cli-php4/ext/xcache.ini:

zend_extension=/usr/lib64/php4/lib/php/extensions/no-debug-non-zts-20020429/xcache.so
auto_globals_jit="0"
xcache.cacher="1"
xcache.size="10M"
xcache.count="2"
xcache.slots="8k"
xcache.var_size="0"
xcache.var_count="1"
xcache.readonly_protection="0"
xcache.mmap_path="/dev/zero"
xcache.stat="1"
xcache.optimizer="0"
xcache.coverager="0"
xcache.coveragedump_directory=""

Regardless of how xcache is disabled, it then works.
Xcache breaks with php used via any of fast cgi, cli, or sapi with apache2.
This breaks on both amd64 and x86.
Both xcache versions 1.2.0 and 1.2.1 are affected.

All of these combinations break:
amd64/glibc 2.5/gcc 4.1.1
amd64/glibc 2.5/gcc 4.1.2
x86/glibc 2.5/gcc 4.1.2

Attachments (2)

php.ini (38.5 KB) - added by kamikaze 7 years ago.
php.ini
phpinfo.txt (29.3 KB) - added by kamikaze 7 years ago.
php -i/phpinfo()

Download all attachments as: .zip

Change History (11)

comment:1 Changed 7 years ago by judas_iscariote

  • Keywords php4_is_broked added
  • Milestone set to 1.2.2
  • Priority changed from critical to major

Cannot reproduce with your code here using 4_4 CVS and xcache SVN 1.2...

PHP 4 does not work properly in 64 bit systems, so it can crash for other reasons unrelated with xcache ( for such systems, use php 5.1.2 or later) however I see you can reproduce it in 32 bit..

comment:2 Changed 7 years ago by moo

  • pending changed from 0 to 1

can't reproduce yet, i need your gdb backtrace

see HowToReportABug for generate a Backtrace

comment:3 follow-up: Changed 7 years ago by moo

  • Cc nleippe@… added
  • Description modified (diff)
  • SAPI set to Irrelevant

any idea?

did u clean the build directory before installing new XCache? make xcachesvnclean will do, or remove everything and unpack the source and retry.

and make sure to use the right php headers.

comment:4 in reply to: ↑ 3 Changed 7 years ago by kamikaze

  • pending changed from 1 to 0

Here's a backtrace:


(gdb) bt
#0  0x0000000000591564 in zend_binary_strcasecmp (s1=0x2ba799d20000 <Address 0x2ba799d20000 out of bounds>, len1=1, s2=0xa43d90 "a", len2=1)
    at /var/tmp/portage/dev-lang/php-4.4.7/work/php-4.4.7/Zend/zend_operators.c:1653
#1  0x00000000005a0a43 in is_a_impl (ht=2, return_value=0xa43d20, this_ptr=0x0, return_value_used=1, only_subclass=0 '\0') at /var/tmp/portage/dev-lang/php-4.4.7/work/php-4.4.7/Zend/zend_builtin_functions.c:571
#2  0x00000000005a0b2d in zif_is_a (ht=2, return_value=0xa43d20, this_ptr=0x0, return_value_used=1) at /var/tmp/portage/dev-lang/php-4.4.7/work/php-4.4.7/Zend/zend_builtin_functions.c:593
#3  0x00000000005ae0ee in execute (op_array=0xa3d7e0) at /var/tmp/portage/dev-lang/php-4.4.7/work/php-4.4.7/Zend/zend_execute.c:1681
#4  0x00000000005949cf in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /var/tmp/portage/dev-lang/php-4.4.7/work/php-4.4.7/Zend/zend.c:939
#5  0x00000000005506ce in php_execute_script (primary_file=0x7fff12db28a0) at /var/tmp/portage/dev-lang/php-4.4.7/work/php-4.4.7/main/main.c:1757
#6  0x00000000005b74f5 in main (argc=2, argv=0x7fff12db2a18) at /var/tmp/portage/dev-lang/php-4.4.7/work/php-4.4.7/sapi/cli/php_cli.c:838

The test file is:

cat > is_a.php <<EOD
<?

class A {};
class B extends A {};
$b =& new B;
echo (int) is_a($b, 'A'), "\n";

EOD

This is with -O0 -g -pg

It seems to be crashing in a string function. Weird.
I get inconsistent behavior still. If I edit the file, say when I added the ', "\n"' part, it segfaulted. Editing it back, corrected it. So it seems there is something wrong with how it invalidates old entries or something.

Even before I got it to segfault again, however, w/xcache enabled it returns 0, and with xcache disabled it returns 1. So, xcache is changing the behavior of the code somehow.

Since gdb cannot do a call-graph, I was going to try with gprof. I haven't got them yet to compare. If you want me to try and get a call graph, I can.

comment:5 Changed 7 years ago by moo

i need your phpinfo output, or the whole php.ini (or all php/*.ini), u may attach the file here

comment:6 Changed 7 years ago by judas_iscariote

# /opt/php4/bin/php is_a.php
1

/opt/php4/bin/php -v
PHP 4.4.8-dev (cgi-fcgi) (built: Jun  7 2007 03:00:57) (DEBUG)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
    with XCache v1.2.2-dev, Copyright (c) 2005-2007, by mOo

#uname -a

Linux hell 2.6.18.8-0.5-default #1 SMP Fri Jun 22 12:17:53 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux

maybe gentoo ebuilds have non-standard patches ?

Changed 7 years ago by kamikaze

php.ini

comment:7 Changed 7 years ago by moo

  • pending changed from 0 to 1

can u paste your phpinfo() output? removing privacy infos

Changed 7 years ago by kamikaze

php -i/phpinfo()

comment:8 Changed 7 years ago by moo

  • Probability set to Always
  • Status changed from new to assigned

looks like this is relatived to or duplicate of #81

can u (or anyone else who can reproduce it) gimme an ssh access to the box? contact me at mailto:phpxcache@…

comment:1 Changed 7 years ago by trac-robot

  • pending changed from 1 to 0
  • Status changed from assigned to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 28 days.

Note: See TracTickets for help on using tickets.