Forum

I have no problem running php-cgi directly via ExecuteCGI, but when I set it up as fastcgi i load any *.php file and the server returns an empty result and hiawatha crashes without putting anything into the logs

I've followed the directions exactly, had the fastcgi/php listener active and tested connectivity with telnet. Makes me a sad panda

Please, follow these instructions [projects.leisink.org].

I will try and do this to help out. It's running on OpenBSD 4.1 so I may not be able to use valgrind. I see what I can do though.

Also! Thank you for wonderful http server! It is SO much better then apache

Also, here is my phpinfo page for what it's worth (running the executecgi method, but it's the same php-cgi binary)

http://codekungfoo.net/test.php

I will try to reproduce the bug on OpenBSD 4.1 myself tomorrow.

The php-cgi port I used is here:
http://download.pureftpd.org/OpenBSD/misc/ports/

Just extracted it and moved the directory into /usr/ports/www/php5-cgi

i'll try to get you some debugging info tonight.

-- Alex

hahaha. It seems that hiawatha is spawning zombie php-cgi processes when using executecgi method (although pages load correctly):

# ps aux
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
_hiawatha 29886 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 406 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 17978 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 4709 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 5357 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 15207 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 19033 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 9052 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 16758 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 2638 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 11651 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 28593 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 8506 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 19718 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 6142 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 1495 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 12071 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 5130 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 2373 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 22160 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)
_hiawatha 15133 0.0 0.0 0 0 ?? Z - 0:00.00 (php-cgi)

im trying to get some tracings with ktrace right now

alrighty! tracings are here:

Using executecgi method:
http://codekungfoo.net/exetrace.txt

Using FastCGI method:
http://codekungfoo.net/fasttrace.txt

In each of these I recreated the causing event once (loaded the phpinfo() page)

also here are my fastcgi processes used during the FastCGI trace:
_hiawatha 20525 0.0 0.6 4412 5436 ?? Is 6:12PM 0:00.06 /usr/local/bin/php-cgi -b 127.0.0.1:2005
_hiawatha 19884 0.0 0.2 4436 1516 ?? I 6:12PM 0:00.05 /usr/local/bin/php-cgi -b 127.0.0.1:2005

The port doesn't work. I get:

# make
===> www/php5-cgi/core
Fatal: Missing comment. (in www/php5-cgi/core)
*** Error code 1

Stop.
*** Error code 1

Stop in /usr/ports/www/php5-cgi (line 103 of /usr/ports/infrastructure/mk/bsd.port/subdir.mk).

I'm no OpenBSD user, so I have know clue about what to do next.

About the zombies: that's weird. It must be an OpenBSD specific thing. It looks like OpenBSD doesn't handle the SIG_IGN the way Linux, FreeBSD and other Unixes do.

I've found where the problem is:

Hiawatha crashes on line 620 in target.c: the call to send_fcgi_request().

I just don't understand why on OpenBSD Hiawatha crashes on this call. The paramaters are oke, I've checked those. And besides that, a program should not crash just on calling a function, no matter the content of the parameters. It must be an OpenBSD issue, because on all other OSes it works fine. If somehow Valgrind could work op OpenBSD....

Maybe it's the php implementation. OpenBSD automatically patches php with a hardening patch:

my php info page:


This server is protected with the Suhosin Patch 0.9.5
Copyright (c) 2006 Hardened-PHP Project
http://www.hardened-php.net/suhosin/index.html


Maybe if I can install php without that patch it will work correctly.

Also valgrind is a no-go :

checking for a supported OS... no (openbsd4.1)
configure: error: Valgrind is operating system specific. Sorry. Please consider doing a port.

Well, if Hiawatha crashes, it can't be PHP's fault. The problem must lie somewhere in Hiawatha. I just don't understand why it crashes under OpenBSD and not under Linux, FreeBSD, MacOSX, etc. I will continue to find the cause of the crash under OpenBSD.

Well the zombie issue seems to be a threading issue with hiawatha. I wont even pretend like I know alot about threading. I kill hiawatha and all of the php-cgi processes die. I've tried sending different signals to hiawatha to kill the zombies without any results (SIGCHLD) For some reason hiawatha is not reaping its dead children on openbsd

# ps alux | grep php
579 14542 27035 7 -22 0 0 0 - Z ?? 0:00.00 (php-cgi) _hiawatha 0.0 0.0 -
579 19693 27035 9 -22 0 0 0 - Z ?? 0:00.00 (php-cgi) _hiawatha 0.0 0.0 -
# ps 27035
PID TT STAT TIME COMMAND
27035 ?? Is 0:00.05 hiawatha


If you need me to do any testing or anything like that I am fully willing to ^_^

webmaster : a.t : codekungfoo.net

I've already solved the problem with the zombies on OpenBSD. POSIX.1-2001 specifies that when a program has SIGCHLD set to SIG_IGN, terminated children should be removed automaticly, thus without an explicit wait(). It seems that OpenBSD does not comply to this specification, so I've made some changes to Hiawatha to fix this OpenBSD issue. It will be available in the next release (5.13).

I will continue to find the problem with the FastCGI crashes. If I need some testing to be done, I'll let you know. Thanks for the offer.

Antoine Jacoutot emailed me about this issue. I haven't looked at the code or anything specific related to this issue, however this sounds just like what happens when the thread stack size is too small. OpenBSD's default thread stack size is quite small (64K I believe). Does the function that's crashing have a big array in it that will exceed the default stack size?

No, not at all. The function that is executed with each thread (called by pthread_create) takes a pointer to a structure as a parameter. The structure is about 2kB large. The function only uses one integer. You can see for yourself: it's connection_handler() in hiawatha.c

Ok I looked at the code. Yes this is a stack size issue. You mentioned:

Hiawatha crashes on line 620 in target.c: the call to send_fcgi_request().

send_fcgi_request() has one local var "t_fcgi_buffer fcgi_buffer;" and that is defined as:

#define FCGI_BUFFER_SIZE 65535

typedef struct {
int sock;
unsigned char data[FCGI_BUFFER_SIZE + 8];
int size;
unsigned char mode;
} t_fcgi_buffer;

which is > 64K.

Something like this should do the trick:
--- hiawatha.c.orig Wed Sep 26 10:42:38 2007
+++ hiawatha.c Wed Sep 26 10:43:52 2007
@@ -1322,6 +1322,7 @@ int accept_connection(t_binding *binding, t_config *co
if (add_client(session) == 0) {
pthread_attr_init(&child_attr);
pthread_attr_setdetachstate(&child_attr, PTHREAD_CREATE_DETACHED);
+ pthread_attr_setstacksize(&child_attr, 1024*1024*1024);
if (pthread_create(&child_thread, &child_attr, (void*)connection_handler, (void*)session) == 0) {
kick_client = false;
} else {

Rather 512K - 2M is usually enough for most apps. :-)

It works!!! Thank you!