Segmentation fault when using php -l to validate any PHP script

I am not able to reproduce this. Can you please provide more info.

Thanks
chuck

Just to comment that this happens to me too.

We have a bzr plugin which adds a pre-commit hook which runs all new and modified PHP files in the commit though php -l, as a basic sanity checker.

From time to time php -l will segfault on a perfectly valid PHP file. Re-attempting usually succeeds.

It gets most annoying when trying to do a large commit, since the greater number of files increases the chance of the segfault occurring, and can result in an irritating number of attempts being required in order for the commit to succeed.

I've encountered the problem on a single-processor i386 machine running jaunty, and just now encountered it on an amd64 dual core machine running an up to date karmic system.

The test case in the original bug report does reproduce the problem for me, but not every time. For each set of 50, I usually get 0-2 instances of the segfault happening.

Confirmed on Ubuntu 9.04 Jaunty amd64.

Steps to reproduce (and capture a backtrace) are:

# Ensure we dump core
ulimit -c 2000000
# Delete any pre-existing core file
rm core
# Create a command input file for use by gdb
echo bt >/tmp/bt
# Create a trivial PHP script
echo -e "<?php\n?>\n" >/tmp/a.php
# Check it 100 times
for i in `seq 1 100` ; do php -l /tmp/a.php >/dev/null; done
# Run GDB to capture the backtrace
gdb -batch -x /tmp/bt `which php` core
# Clean up temp files
rm core /tmp/bt /tmp/a.php

Backtrace attached. It might be worth trying it with a debug version of PHP
if this backtrace is insufficient.

Since two people other than the original reporter have now reproduced this bug, I am setting its status to confirmed.

Just a quick note to add that this problem also happens if the file (a.php) is completely empty (zero-length).

I'm not really au-fait with gdb and the like. However I installed libgcc1-dbg to get more debugging symbols and got the attached trace using Jonathan's a.php. Hopefully it will be of some use.

I am using Jaunty 32 bit.

My kernel is 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC 2009 i686 GNU/Linux.

My php version is: PHP 5.2.6-3ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 23 2009 14:35:05)

This also happened when simply executing the same file a.php,
for i in `seq 1 100`;do php a.php;done --> would also end up in a segmentation fault (rarely)

Also php web-pages were halted but that probably was related to the race condition in libmysqlclient15off ( bug #343870)

Relative bugs:
OpenVZ: http://bugzilla.openvz.org/show_bug.cgi?id=1012
Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515143

The problem is not in PHP but in MySQL, it just affects PHP in particular.

This is caused by code in libmysqlclient introduced in mysql bug #24507 (http://bugs.mysql.com/bug.php?id=24507). That workaround is itself a source of problems described here and elsewhere.

The solution is to reverse-apply the patch from the above mysql bug. The ready-to-go patch is available in the above-referenced openvz and debian bugs.

Hope that helps.

Appropriate MySQL bug (still not fixed at the moment):
http://bugs.mysql.com/bug.php?id=42850

Thank for the report, as per your latest comments this looks like bug 343870 which is fixed on karmic, could you test the same there with a karmic live cd or installation and confirm ? Thanks.

I just tried this on a completely up to date karmic machine:

$ while true; do php -r ""; done
Segmentation fault (core dumped)

Segfaults continue to appear every few seconds.

Russ,

I think it makes more sense to report it not here but in bug #343870, since there they believe it's fixed. Also please specify your php* and mysql* versions