Created attachment 24391 [details] test file If request size exceed FcgidMaxRequestInMem PHP got error: UPLOAD_ERR_PARTIAL (The uploaded file was only partially uploaded)
Created attachment 24392 [details] strace while upload test file
Thanks for the report. I'm not yet able to reproduce, so I have a few more questions: * Is this a 32-bit or 64-bit build? * What is your value of FcgidMaxRequestInMem? * Is it possible to get a trace of the httpd process for the same testcase? mod_fcgid 2.2 didn't actually respect FcgidMaxRequestInMem except for fairly low values (< ~8K), so to get the previous behavior you can set FcgidMaxRequestInMem to a very high value.
(In reply to comment #2) > Thanks for the report. > I'm not yet able to reproduce, so I have a few more questions: > * Is this a 32-bit or 64-bit build? test with 32 and 64 bit > * What is your value of FcgidMaxRequestInMem? any. i test with defaut (64K), 32K (for test case) and 1M. if request is large that this value we got broken upload. > * Is it possible to get a trace of the httpd process for the same testcase? see new attache. > mod_fcgid 2.2 didn't actually respect FcgidMaxRequestInMem except for fairly > low values (< ~8K), so to get the previous behavior you can set sorry, my mistake. before we use "origin" 2.3.x (not asf) > FcgidMaxRequestInMem to a very high value. now, we use this as workaround
Created attachment 24396 [details] httpd strace
Thanks for the new data. The temporary file that holds the part of the request body in excess of FcgidMaxRequestInMem is getting truncated after the first buffer of data for this request is getting written there: 19921 open("/tmp/fcgid.tmp.pBN8aH", O_RDWR|O_CREAT|O_EXCL, 0600) = 40 19921 write(40, "pppppppppppppppppppppppppppppppp"..., 1460) = 1460 19921 poll([{fd=39, events=POLLIN, revents=POLLIN}], 1, 120000) = 1 19921 read(39, "PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP"..., 8000) = 1460 19921 ftruncate(40, 0) = 0 19921 write(40, "PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP"..., 1460) = 1460 The fix may be as simple as this: --- mod_fcgid-2.3.4/modules/fcgid/fcgid_bridge.c.orig 2009-10-19 13:08:15.437700200 -0400 +++ mod_fcgid-2.3.4/modules/fcgid/fcgid_bridge.c 2009-10-19 13:08:55.547050836 -0400 @@ -574,7 +574,9 @@ apr_pool_userdata_set((const void *) fd, fd_key, apr_pool_cleanup_null, r->connection->pool); - } else if (need_truncate) { + } + + if (need_truncate) { need_truncate = 0; apr_file_trunc(fd, 0); cur_pos = 0; Before testing that fix I need to see why my testcase isn't failing with 2.3.4 :(
> The fix may be as simple as this: this patch working for me
Thanks for the quick feedback. I found out what was breaking my own test: the request body size has to exceed FcgidMaxRequestInMem by some variable amount before hitting the truncation bug, and I wasn't sending enough data to hit it. The patch is working for my updated testcase as well.
This is now fixed for future mod_fcgid 2.3.5. In the interim: To make mod_fcgid behave like 2.2 (which ignored the in-memory limit in most cases), set FcgidMaxRequestInMem higher than your largest request body. To resolve the regression and at the same time respect FcgidMaxRequestInMem, apply this patch: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c?r1=826829&r2=826828&pathrev=826829
*** Bug 48554 has been marked as a duplicate of this bug. ***
*** Bug 48626 has been marked as a duplicate of this bug. ***