Ticket #111 (closed defect)

Opened 6 years ago

Last modified 6 years ago

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@…
Blocked By: PHP Version: 4.4.7
Application: xcache Need User Feedback: no
Other Exts: SAPI: Irrelevant
Probability: Always Blocking:

Description (last modified by moo) (diff)

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

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

Change History

  Changed 6 years ago by judas_iscariote

  • keywords php4_is_broked added
  • priority changed from critical to major
  • milestone set to 1.2.2

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

  Changed 6 years ago by moo

  • pending set

can't reproduce yet, i need your gdb backtrace

see HowToReportABug for generate a Backtrace

follow-up: ↓ 4   Changed 6 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.

in reply to: ↑ 3   Changed 6 years ago by kamikaze

  • pending unset

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.

  Changed 6 years ago by moo

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

  Changed 6 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 6 years ago by kamikaze

php.ini

  Changed 6 years ago by moo

  • pending set

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

Changed 6 years ago by kamikaze

php -i/phpinfo()

  Changed 6 years ago by moo

  • status changed from new to assigned
  • probability set to Always

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@…

  Changed 6 years ago by trac-robot

  • status changed from assigned to closed
  • pending unset

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.