Bug #841

Segmentation fault using fastcgi / php5-cgi

Added by Anonymous over 8 years ago. Updated almost 7 years ago.

Status:FixedStart date:
Priority:UrgentDue date:
Assignee:-% Done:

0%

Category:mod_fastcgi
Target version:-
Missing in 1.5.x:

Description

Hi all,

I have a critical problem using lighty on Ubuntu Linux 6.06.1 Dapper {{{ "Linux kyr0desk 2.6.15-25-386 #1 PREEMPT Wed Jun 14 11:25:49 UTC 2006 i686 GNU/Linux" }}}
using the default Ubuntu universal repository lighttpd binary in version 1.4.11.

Lighty crashes by browsing to "localhost" using fastcgi with php5-cgi.

But it's not a php5-cgi problem:


root@kyr0desk:/www# /usr/bin/php5-cgi index.php
X-Powered-By: PHP/5.1.2
Content-type: text/html

testroot@kyr0desk:/www#

index.php source:


<?php

 echo("test");

?>

-- kyr0

lighty.bugreport.data - strace, valgrind & internal lighttpd config -- support (76.2 KB) Anonymous, 2006-09-08 12:14

lighttpd_fix_841.patch Magnifier - fix #841: Segmentation fault using fastcgi / php5-cgi (3.81 KB) stbuehler, 2008-01-15 23:10

History

#1 Updated by Anonymous over 8 years ago

I think its because php5-cgi hasn't been built with lighttpd support; the Ubuntu package depends on php4-cgi. I had the same problem on my first attempt. In any case, you can get it working - and probably working a heck of a lot faster - by using a socket instead of a port connection.
ie, make the config:

fastcgi.server       = (
".php" => (
"localhost" => (
"bin-path" => "/usr/bin/php5-cgi",[[[BR]]]
"socket" => "/tmp/php5-fcgi.socket",[[[BR]]]
)))

#2 Updated by jan about 8 years ago

  • Status changed from New to Assigned

Good catch, can you rebuild the strace with the option -s 512:

$ strace -s 512 -tt ...

Without the -s 512 the strings are cut off too early:

424 write(5, "2006-09-08 14:36:46: (mod_fastcg"..., 80) = 80
425 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
426 ++ killed by SIGSEGV ++

and can you use the debug-version of lighty when you run valgrind ?

If you compiled from source a lighttpd-binary with debug-symbols is in the src/ folder:

$ file src/lighttpd
lighttpd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

Otherwise I don't get line-numbers for the segfault as you see below:

1192 11737 1 errors in context 1 of 10:
1193 11737 Invalid write of size 4
1194 11737 at 0x45168B0: (within /usr/lib/lighttpd/mod_fastcgi.so)
1195 11737 by 0x805E5D6: plugins_call_handle_subrequest (in /usr/sbin/lighttpd)
1196 11737 by 0x804FCB6: http_response_prepare (in /usr/sbin/lighttpd)
1197 11737 by 0x805261C: connection_state_machine (in /usr/sbin/lighttpd)
1198 11737 by 0x80535A5: network_server_handle_fdevent (in /usr/sbin/lighttpd)
1199 11737 by 0x804E01E: main (in /usr/sbin/lighttpd)
1200 11737 Address 0x28 is not stack'd, malloc'd or (recently) free'd

#3 Updated by darix over 7 years ago

please retest this bug on a newer release.

#4 Updated by stbuehler over 7 years ago

confirmed for 1.4.16

The problem is, that it is not clear in the source, if it is ok to not specify "host".
The config sanity check requires the following:
- that you do not set (host or port) AND unixsocket,
- if unixsocket is not set -> tcp/ip
- you set at least "host" or "bin-path"
- port != 0
The struct docu says that for tcp/ip host AND port are needed.

Now some code (like fcgi_spawn_connection), accepts unspecified host for tcp, but not all code does, e.g. fcgi_write_request.

Try the patch below, which uses INADDR_LOOPBACK if host is not specified.
Another possibility would be to spawn the fcgi-process with bind(INADDR_ANY) and connect to INADDR_LOOPBACK (just remove the second part of the patch, which changes INADDR_ANY to INADDR_LOOPBACK).

One problem remains: if the fastcgi-process does not die while the server gets restarted, the proc is marked as not local; if the fastcgi-process dies now, the server wont restart it, as it is not local, although it has a bin_path.

#5 Updated by stbuehler almost 7 years ago

I just read through the mod_fastcgi diff since 1.4.16 and i didn't find a fix for this, so i think it is just there (i did not test it again).
Updated patch for current svn.

#6 Updated by glen almost 7 years ago

  • Status changed from Assigned to New

#7 Updated by glen almost 7 years ago

  • Status changed from New to Fixed
  • Resolution set to fixed

Committed revision r2037.

Also available in: Atom