This was subject was covered briefly in another thread but I'm
documenting it again for the next person.

My setup is:
PHP 5.2.11
FPM 0.6.5
APC 3.0.19 (also tested with 3.1.3p1)

The basic issue was that php-fpm would segfault (in APC) when it
should have returned a 404. This only occurred after at least one
file was successfully cached with APC. That is, after a normal
request a request which should have resulted in a 404 resulted in a
segfault.

The root issue is probably APC not checking if the filename is empty
before attempting send that zero-length filename to zend. Of course,
PHP should tolerate this behavior as well. I don't actually think
fault lies with php-fpm but the issue does not occur if PHP is run via
apxs / Apache.

Setting fix_pathinfo=0 in either php.ini or in the /etc/php-fpm.conf
overrides solved the problem. It might be worth adding this setting
to the default config (commented out), to help make this important
setting more clear in the future.

Further padding this message with helpful keywords, here is my gdb
backtrace of the problem:

(gdb) bt
#0 0xb76fb211 in fread () from /lib/i686/cmov/libc.so.6
#1 0x083e6067 in zend_stream_stdio_reader ()
#2 0x083e60ec in zend_stream_read ()
#3 0x083b043e in lex_scan ()
#4 0x083b6988 in zendlex ()
#5 0x083aaa2b in zendparse ()
#6 0x083b1a1b in compile_file ()
#7 0xb75012a0 in my_compile_file (h=0xbfa72fd8, type=8) at /usr/local/
src/APC-3.1.3p1/apc_main.c:525
#8 0x083d1a4d in zend_execute_scripts ()
#9 0x083870ea in php_execute_script ()
#10 0x08443a88 in main ()

And here you can see the empty filename which APC is attempting to
compile / cache:

(gdb) frame 7
#7 0xb75012a0 in my_compile_file (h=0xbfa72fd8, type=8) at /usr/local/
src/APC-3.1.3p1/apc_main.c:525
525 return old_compile_file(h, type TSRMLS_CC);
(gdb) info locals
key = {data = {file = {device = 3215387700, inode = 154996816}, user =
{identifier = 0xbfa6ec34 "", identifier_len = 0}, fpfile = {fullpath =
0xbfa6ec34 "",
fullpath_len = 0}}, mtime = 30, type = 0 '\0', md5 =
"\000\000\004", '\0' <repeats 12 times>}
cache_entry = <value optimized out>
op_array = (zend_op_array *) 0x0
t = 1263419930
ctxt = {pool = 0x0, copy = APC_NO_COPY, force_update = 0}
bailout = <value optimized out>


I'll file a bug with APC as well.

Thanks
>j.

I just noticed a typo in my post. The PHP setting is actually
cgi.fix_pathinfo not fix_pathinfo.

On Jan 13, 2:12 pm, JayReitz <jre...@gmail.com> wrote:
> This was subject was covered briefly in another thread but I'm
> documenting it again for the next person.
>
> My setup is:
> PHP 5.2.11
> FPM 0.6.5
> APC 3.0.19 (also tested with 3.1.3p1)
>
> The basic issue was that php-fpm would segfault (in APC) when it
> should have returned a 404.  This only occurred after at least one
> file was successfully cached with APC.  That is, after a normal
> request a request which should have resulted in a 404 resulted in a
> segfault.
>
> The root issue is probably APC not checking if the filename is empty
> before attempting send that zero-length filename to zend.  Of course,
> PHP should tolerate this behavior as well.  I don't actually think
> fault lies with php-fpm but the issue does not occur if PHP is run via
> apxs / Apache.
>
> Setting fix_pathinfo=0 in either php.ini or in the /etc/php-fpm.conf
> overrides solved the problem.  It might be worth adding this setting
> to the default config (commented out), to help make this important
> setting more clear in the future.
>
> Further padding this message with helpful keywords, here is my gdb
> backtrace of the problem:
>
> (gdb) bt
> #0  0xb76fb211 in fread () from /lib/i686/cmov/libc.so.6
> #1  0x083e6067 in zend_stream_stdio_reader ()
> #2  0x083e60ec in zend_stream_read ()
> #3  0x083b043e in lex_scan ()
> #4  0x083b6988 in zendlex ()
> #5  0x083aaa2b in zendparse ()
> #6  0x083b1a1b in compile_file ()
> #7  0xb75012a0 in my_compile_file (h=0xbfa72fd8, type=8) at /usr/local/
> src/APC-3.1.3p1/apc_main.c:525
> #8  0x083d1a4d in zend_execute_scripts ()
> #9  0x083870ea in php_execute_script ()
> #10 0x08443a88 in main ()
>
> And here you can see the empty filename which APC is attempting to
> compile / cache:
>
> (gdb) frame 7
> #7  0xb75012a0 in my_compile_file (h=0xbfa72fd8, type=8) at /usr/local/
> src/APC-3.1.3p1/apc_main.c:525
> 525             return old_compile_file(h, type TSRMLS_CC);
> (gdb) info locals
> key = {data = {file = {device = 3215387700, inode = 154996816}, user =
> {identifier = 0xbfa6ec34 "", identifier_len = 0}, fpfile = {fullpath =
> 0xbfa6ec34 "",
>       fullpath_len = 0}}, mtime = 30, type = 0 '\0', md5 =
> "\000\000\004", '\0' <repeats 12 times>}
> cache_entry = <value optimized out>
> op_array = (zend_op_array *) 0x0
> t = 1263419930
> ctxt = {pool = 0x0, copy = APC_NO_COPY, force_update = 0}
> bailout = <value optimized out>
>
> I'll file a bug with APC as well.
>
> Thanks
>
> >j.
>
>

I've had cgi.fix_pathinfo = 1 in my php.ini (not specifically in
php-fpm.conf) for years...

On Wed, Jan 13, 2010 at 2:20 PM, JayReitz <jreitz@gmail.com> wrote:
> I just noticed a typo in my post.  The PHP setting is actually
> cgi.fix_pathinfo not fix_pathinfo.
>
> On Jan 13, 2:12 pm, JayReitz <jre...@gmail.com> wrote:
>> This was subject was covered briefly in another thread but I'm
>> documenting it again for the next person.
>>
>> My setup is:
>> PHP 5.2.11
>> FPM 0.6.5
>> APC 3.0.19 (also tested with 3.1.3p1)
>>
>> The basic issue was that php-fpm would segfault (in APC) when it
>> should have returned a 404.  This only occurred after at least one
>> file was successfully cached with APC.  That is, after a normal
>> request a request which should have resulted in a 404 resulted in a
>> segfault.
>>
>> The root issue is probably APC not checking if the filename is empty
>> before attempting send that zero-length filename to zend.  Of course,
>> PHP should tolerate this behavior as well.  I don't actually think
>> fault lies with php-fpm but the issue does not occur if PHP is run via
>> apxs / Apache.
>>
>> Setting fix_pathinfo=0 in either php.ini or in the /etc/php-fpm.conf
>> overrides solved the problem.  It might be worth adding this setting
>> to the default config (commented out), to help make this important
>> setting more clear in the future.
>>
>> Further padding this message with helpful keywords, here is my gdb
>> backtrace of the problem:
>>
>> (gdb) bt
>> #0  0xb76fb211 in fread () from /lib/i686/cmov/libc.so.6
>> #1  0x083e6067 in zend_stream_stdio_reader ()
>> #2  0x083e60ec in zend_stream_read ()
>> #3  0x083b043e in lex_scan ()
>> #4  0x083b6988 in zendlex ()
>> #5  0x083aaa2b in zendparse ()
>> #6  0x083b1a1b in compile_file ()
>> #7  0xb75012a0 in my_compile_file (h=0xbfa72fd8, type=8) at /usr/local/
>> src/APC-3.1.3p1/apc_main.c:525
>> #8  0x083d1a4d in zend_execute_scripts ()
>> #9  0x083870ea in php_execute_script ()
>> #10 0x08443a88 in main ()
>>
>> And here you can see the empty filename which APC is attempting to
>> compile / cache:
>>
>> (gdb) frame 7
>> #7  0xb75012a0 in my_compile_file (h=0xbfa72fd8, type=8) at /usr/local/
>> src/APC-3.1.3p1/apc_main.c:525
>> 525             return old_compile_file(h, type TSRMLS_CC);
>> (gdb) info locals
>> key = {data = {file = {device = 3215387700, inode = 154996816}, user =
>> {identifier = 0xbfa6ec34 "", identifier_len = 0}, fpfile = {fullpath =
>> 0xbfa6ec34 "",
>>       fullpath_len = 0}}, mtime = 30, type = 0 '\0', md5 =
>> "\000\000\004", '\0' <repeats 12 times>}
>> cache_entry = <value optimized out>
>> op_array = (zend_op_array *) 0x0
>> t = 1263419930
>> ctxt = {pool = 0x0, copy = APC_NO_COPY, force_update = 0}
>> bailout = <value optimized out>
>>
>> I'll file a bug with APC as well.
>>
>> Thanks
>>
>> >j.
>>
>>
>

That's nice. I'm not suggesting the issue is universal. I suspect
that most people do not hit the bug because their webserver
configuration shields php-fpm from receiving requests to non-existent
scripts. However, in my particular configuration the webserver cannot
make that determination prior to proxying the request to php-fpm.

As mentioned, this appears to be an APC bug, not a php-fpm bug.

>j.

On Jan 13, 2:30 pm, Michael Shadle <mike...@gmail.com> wrote:
> I've had cgi.fix_pathinfo = 1 in my php.ini (not specifically in
> php-fpm.conf) for years...
>
> On Wed, Jan 13, 2010 at 2:20 PM, JayReitz <jre...@gmail.com> wrote:
> > I just noticed a typo in my post.  The PHP setting is actually
> > cgi.fix_pathinfo not fix_pathinfo.
>
> > On Jan 13, 2:12 pm, JayReitz <jre...@gmail.com> wrote:
> >> This was subject was covered briefly in another thread but I'm
> >> documenting it again for the next person.
>
> >> My setup is:
> >> PHP 5.2.11
> >> FPM 0.6.5
> >> APC 3.0.19 (also tested with 3.1.3p1)
>
> >> The basic issue was that php-fpm would segfault (in APC) when it
> >> should have returned a 404.  This only occurred after at least one
> >> file was successfully cached with APC.  That is, after a normal
> >> request a request which should have resulted in a 404 resulted in a
> >> segfault.
>
> >> The root issue is probably APC not checking if the filename is empty
> >> before attempting send that zero-length filename to zend.  Of course,
> >> PHP should tolerate this behavior as well.  I don't actually think
> >> fault lies with php-fpm but the issue does not occur if PHP is run via
> >> apxs / Apache.
>
> >> Setting fix_pathinfo=0 in either php.ini or in the /etc/php-fpm.conf
> >> overrides solved the problem.  It might be worth adding this setting
> >> to the default config (commented out), to help make this important
> >> setting more clear in the future.
>
> >> Further padding this message with helpful keywords, here is my gdb
> >> backtrace of the problem:
>
> >> (gdb) bt
> >> #0  0xb76fb211 in fread () from /lib/i686/cmov/libc.so.6
> >> #1  0x083e6067 in zend_stream_stdio_reader ()
> >> #2  0x083e60ec in zend_stream_read ()
> >> #3  0x083b043e in lex_scan ()
> >> #4  0x083b6988 in zendlex ()
> >> #5  0x083aaa2b in zendparse ()
> >> #6  0x083b1a1b in compile_file ()
> >> #7  0xb75012a0 in my_compile_file (h=0xbfa72fd8, type=8) at /usr/local/
> >> src/APC-3.1.3p1/apc_main.c:525
> >> #8  0x083d1a4d in zend_execute_scripts ()
> >> #9  0x083870ea in php_execute_script ()
> >> #10 0x08443a88 in main ()
>
> >> And here you can see the empty filename which APC is attempting to
> >> compile / cache:
>
> >> (gdb) frame 7
> >> #7  0xb75012a0 in my_compile_file (h=0xbfa72fd8, type=8) at /usr/local/
> >> src/APC-3.1.3p1/apc_main.c:525
> >> 525             return old_compile_file(h, type TSRMLS_CC);
> >> (gdb) info locals
> >> key = {data = {file = {device = 3215387700, inode = 154996816}, user =
> >> {identifier = 0xbfa6ec34 "", identifier_len = 0}, fpfile = {fullpath =
> >> 0xbfa6ec34 "",
> >>       fullpath_len = 0}}, mtime = 30, type = 0 '\0', md5 =
> >> "\000\000\004", '\0' <repeats 12 times>}
> >> cache_entry = <value optimized out>
> >> op_array = (zend_op_array *) 0x0
> >> t = 1263419930
> >> ctxt = {pool = 0x0, copy = APC_NO_COPY, force_update = 0}
> >> bailout = <value optimized out>
>
> >> I'll file a bug with APC as well.
>
> >> Thanks
>
> >> >j.
>
>