Expected error during testing causes an error?

No difference between the fail.patch files or the rest of them for that matter:

root@xen1:/var/www/drupal/sites# diff -u default/files/pifr_simpletest/fail.patch all/modules/project_issue_file_review/review/simpletest/confirmation/fail.patch 

Though there is one extra patch.patch file in the files directory, the contents of which are

non-unix
line
endings

root@xen1:/var/www/drupal/sites/default/files/pifr_simpletest# ls
apply.patch  install.patch  patch.patch   test.patch
fail.patch   pass.patch     syntax.patch

vs

root@xen1:/var/www/drupal/sites# ls all/modules/project_issue_file_review/review/simpletest/confirmation/
CVS          fail.patch     pass.patch    test.patch
apply.patch  install.patch  syntax.patch

I see you just made some commits, so I'll do a completely fresh install and try again.

I'm using a fresh install now. It also happens occasionally during step 7 of the self test for the install.patch file. Same situation as aforementioned step 9, "Invalid PHP syntax in install.php."

root@xen1:/var/www/drupal/sites/default/files/checkout# cvs diff -u
cvs diff: Diffing .
Index: install.php
===================================================================
RCS file: /cvs/drupal/drupal/install.php,v
retrieving revision 1.220
diff -u -r1.220 install.php
--- install.php	27 Oct 2009 06:07:38 -0000	1.220
+++ install.php	28 Oct 2009 04:10:39 -0000
@@ -5,7 +5,7 @@
  * Root directory of Drupal installation.
  */
 define('DRUPAL_ROOT', getcwd());
-
+break_me();
 require_once DRUPAL_ROOT . '/includes/install.inc';
 
 /**

Unfortunately I have had this problem before and changing to a different linux distro fixed it. I could start trying that again, but it gets old bouncing from distro to distro without knowing what the root cause is...

In this case, it is Ubuntu 9.04 i386, which has been the most dependable one for me to sandbox with in the past. PIFR 1 client #44 is on Debian 5.0... I guess I could try that next.

I checked /var/log/apache2/error.log and discovered this after each failed self test:

patch: **** Only garbage was found in the patch input.
Segmentation fault
Segmentation fault

This is really the entire cvs diff -u when it breaks on #7 for "Invalid PHP syntax in install.php."

root@xen1:/var/www/drupal/sites/default/files/checkout# cvs diff -u
cvs diff: Diffing .
Index: install.php
===================================================================
RCS file: /cvs/drupal/drupal/install.php,v
retrieving revision 1.220
diff -u -r1.220 install.php
--- install.php	27 Oct 2009 06:07:38 -0000	1.220
+++ install.php	29 Oct 2009 18:01:21 -0000
@@ -5,7 +5,7 @@
  * Root directory of Drupal installation.
  */
 define('DRUPAL_ROOT', getcwd());
-
+break_me();
 require_once DRUPAL_ROOT . '/includes/install.inc';
 
 /**

Is there a php.ini setting that would cause a missing function to be interpreted as invalid PHP syntax? I checked against a stock php.ini-recommended file and changed a few things that Ubuntu's version differed from, but that didn't fix this problem. Maybe a module I shouldn't have installed in mod_php?

root@xen1:/var/log/apache2# php -m
[PHP Modules]
bcmath
bz2
calendar
ctype
curl
date
dba
dom
exif
filter
ftp
gd
gettext
hash
iconv
json
libxml
mbstring
mcrypt
mime_magic
mysql
mysqli
ncurses
openssl
pcntl
pcre
PDO
pdo_mysql
posix
readline
Reflection
session
shmop
SimpleXML
soap
sockets
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xml
xmlreader
xmlwriter
zip
zlib

So... whatever it is about Linode's Ubuntu 9.04 i386 image causes segfaults that don't happen in their Debian 5.0 i386 image, because I got past all that by starting over in Debian 5.0.

I resolved this problem by doing one of the following:

a2enmod deflate
/etc/init.d/apache2 restart

If not that, then try, in /etc/apache2/conf.d/security

ServerTokens Minimal
ServerSignature Off
TraceEnable Off

Make sure your /etc/php5/apache2/php.ini and /etc/php5/cli/php.ini
files have

display_errors = On
log_errors = Off

In /etc/apache2/apache2.conf and /etc/apache2/sites-available/default
comment out or remove the custom log.

In /etc/apache2/sites-available/default, remove the docs and cgi-bin
directory options.

I think deflate is the actual fix, but I did all those things at the same time, so I'm not entirely sure which one did it. I'm running a test with #48 right now with deflate module disabled to make sure.

It's not deflate or security that fixes it. Still trying stuff. Right now I'm trying CustomLog in apache2.conf.

I reverted all the stuff in #9 to back what it was when it was broken and I can't break it again so I can confirm what the fix was. Either I did something I have forgotten about doing or the mere act of restarting apache2 fixed it. When I can get my hands on another broken install, I'll diff the /etc/php5 and /etc/apache2 directories with a working server. I know those are the only two places I touched any files when I was working on debugging this.

I diffed Ryan's linode with mine, so they should be using the same base VM image. The PHP configuration looks alright. The only difference I found was the memory, which is more related to #534484: increase recommended php memory_limit to 384M.

Apache differs only slightly. I don't see anything to act on, yet. They differ in i686 vs x86_64, but Damien's working client is x86_64 on Lenny, so that's probably not the cause either.

Now I'm really confused. Both machines are running at linode, they have the same OS, the same diff and patch versions, and the attached diff of /var/www shows only the fail.patch, settings.php connection information, and cvs vs package versions in the d6 core checkout.

Maybe I'm still missing something in this diff that is consequential, but I still don't see anything in the /etc diff between Ryan and Damien's servers that would cause this failure.

How about this diff of package installs from Ryan's to my server or Ryan's to Damien's? Is there something else installed that could make the difference? I put php5-mcrypt and php5-mhash on Ryan's machine and that didn't fix it.

I don't think it's closed. I think Ryan and others just gave up trying to figure it out.

i haven't seen this happen in a while