How To Report A Bug

If you find a bug in XCache, you can help alot to find a fix for it by following some simple steps:

• ​Don't Panic
• if it's a compile/build problem
  • configure problem: check last n lines error message that configure script outputs, and check config.log
  • make problem: check last n lines error message that make outputs
• if it's a runtime problem
  • if it's reproducable, make a minimum yet still reproducable php script
  • collect information we need
    • check your system version
    • check your gcc version
    • php version
    • if it is a crash ​generate a Backtrace
• file a bug, or submit a patch

You can check the following sections for instructions on how to do all the steps above.

Checking System Version

$ uname -a
Linux gentoo 2.6.12-*** #3 Mon Feb 13 22:58:28 CET 2006 i686 Pentium III (Coppermine) GNU/Linux

Checking gcc/glibc Version

$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/specs
Configured with: ...............
Thread model: posix
gcc version 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)

Checking PHP Version

$ php -v
PHP 5.2.0-dev (cli) (built: May  8 2006 18:26:52) (DEBUG)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
gentoo ~/src/xcache/trunk/build
$ php-cgi -v
PHP 4.4.3-dev (cgi-fcgi) (built: Mar 10 2006 18:46:02)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
    with XCache v1.0, Copyright (c) 2005-2006, by mOo

are you sure which one you use in webserver? check

<?php phpinfo(); ?>

Generating a Backtrace

If you don't have a core file yet

Read ​generating a Backtrace on php.net.

• config xcache.coredump_directory in /etc/php.ini
• Ensure that the xcache.coredump_directory has write permissions for the user who's running PHP.
• Remove any limits you may have on core dump size from your shell:
  • tcsh: unlimit coredumpsize
  • bash/sh: ulimit -c unlimited
• Cause PHP to crash:
  • PHP CGI: Simply run php with the script that crashes it
  • PHP FastCGI: Simply setup normal webserver-fastcgi configuration, and access the script that crashes PHP
  • PHP As Apache Module: Run httpd -X, and access the script that crashes PHP

Once you have the core file

check where the coredump is

$ grep xcache.coredump_directory /etc/php.ini
xcache.coredump_directory = "/tmp/"
$ ls /tmp/core
/tmp/core

ok, it's there

• PHP as CGI/FastCGI: Run gdb with the path to the PHP or PHP-enabled httpd binary, and path to the core file, for example:

  $ gdb /usr/local/bin/php-cgi-fcgi /tmp/core  
  ........
  (gdb) bt 
  (gdb) source ~/src/php5/.gdbinit 
  (gdb) dump_bt
  

• PHP As Webserver Module: Run gdb with the path to the PHP or PHP-enabled httpd binary, and path to the core file, for example:

  $ gdb /usr/local/apache/sbin/httpd /tmp/core 
  ........
  (gdb) bt 
  (gdb) source ~/src/php5/.gdbinit
  (gdb) dump_bt
  

Filing A Bug

File bug here. We need as much information as possible. It will greatly helps us tracing it down.

Submiting A Patch

If you've managed to write a patch, you may attach it at here too. It would helps us a lot if you generate the bug with:

$ svn di > xcache-xxx.patch
(or)
$ diff -u xcache-modified xcache-orig > xcache-xxx.patch

and you should still tell us what the bug/problem is as in normal bug report, not just the patch.