FastCGI problem with subrequests and POST-data

[openresty]

FastCGI problem with subrequests and POST-data

Update: I just became a bit desperate and installed another VMware with Archlinux 64bit - did a clean setup with nginx 1.0.4 and the modules - and it worked!

So the fault has to be somewhere in the 32bit <-> 64bit difference which is very strange :(

[agentzh]

On Tue, Jun 21, 2011 at 8:44 PM, moodydeath
[email protected]
wrote:

At first: I still don't know, where the error is coming from exactly.

When doing a post-request with data to php-scripts via ngx.location.subrequests the fastcgi processing has a timeout (504 for the client then) like:

Thanks for the detailed information. I don't see any clue in the debug
log. Could you please dump out the fastcgi request headers on the php
side? It seems that php is waiting for something that will never
arrive. Debugging on the php side should be easier.

Thanks!
-agentzh

[agentzh]

On Wed, Jun 22, 2011 at 4:22 PM, agentzh [email protected] wrote:

Thanks for the detailed information. I don't see any clue in the debug
log. Could you please dump out the fastcgi request headers on the php
side? It seems that php is waiting for something that will never
arrive. Debugging on the php side should be easier.

Also, using the strace utility to check what the php-fpm process is
doing during the hang will be very helpful too :)

-agentzh

Hi, i just straced php-fpm with 1 chidprocess on the 64bit and 32bit installation with the test-scripts from the post above.

Here's the failing 32bit one: http://pastebin.com/BHYRBQD3
And the working 64bit version: http://pastebin.com/9i7fTfG1

Currently compiling php and php-fpm with debug-mode... will take some time, but i will post the results, then, too :-)

Thanks!
moody

Feeling kind of stupid because i can't find a log-file produced by php or php-fpm where the content of the requests is logged. (the only thing i can produce are php-scripts which have the request-headers as output, but they are the same for 64bit and 32bit - and i won't really rely on them to be correct and that it contains everything)

but i think there could be a hint in the 32bit-log from strace:

[pid 10750] write(3, "\1\6\0\1\0007\1\0X-Powered-By: PHP/5.3.6\r"..., 80) = -1 EPIPE (Broken pipe)
[pid 10750] --- {si_signo=SIGPIPE, si_code=SI_USER, si_pid=10750, si_uid=1000} (Broken pipe) ---

[agentzh]

On Wed, Jun 22, 2011 at 9:28 PM, moodydeath
[email protected]
wrote:

Hi, i just straced php-fpm with 1 chidprocess on the 64bit and 32bit installation with the test-scripts from the post above.

Here's the failing 32bit one: http://pastebin.com/BHYRBQD3

I cannot tell what syscall php-fpm is block upon from this complete
strace dump. What is the last syscall when the hang is actually
happening? Is it this one?

[pid 10750] read(3,  <unfinished ...>

Could you print out the Content-Length header in your php script (you
can temporarily remove the body reading section from your .php
script)?

I wonder if the Content-Length header takes a value larger than 3 :)

Thanks!
-agentzh

[agentzh]

On Tue, Jun 21, 2011 at 8:44 PM, moodydeath
[email protected]
wrote:

I don't know what could cause this - The machines are theoretically the same! (Besides one is 32bit and one 64bit), all the configuration-files are the same, too.

Okay, the key issue is with "32bit". I've found a bug in ngx_lua that
when running on 32bit systems, it will produce memory invalid writes
(that is, writing a 32-bit size_t to a 64-bit off_t in
ngx_http_lua_adjust_subrequest), which results in erroneously large
Content-Length headers for POST/PUT subrequests. And it will certainly
cause your php-fpm process to hang because the php is expecting a
huge request body which is actually several bytes long.

Could you please try out the latest devel branch of ngx_lua?

Waiting for your feedback on my patch! :D

(It seems that I should have prepared a 32-bit system to test my C code :P)

Thanks!
-agentzh

Hi,
sorry - was just about to log the content-length headers when your commit appeared.

I tested the devel-branch on both 32bit installations (Ubuntu 10.04 and ArchLinux) and to be on the safe side even on the ArchLinux64 Machine ;-)

Everything working perfect now!

Thanks,
moody