Another question: I set "max-procs" to 1 for my application in lighttpd.conf. I noticed that lighttpd start two processes : "MyApp" and "MyApp client". What is that "MyApp client" for? Where does it come from? Does it affect anything?

Thanks!

Hey Wei,

I'm not sure what is going on with the file upload issue, but my guess would be that it might be because the 200M max-request-size is somehow not well configured ?

As to the two processes: one is a daemon which relays FastCGI connections from the web server to a 'client' process which is the actual application process. So this is as expected.

Regards,

koen

Thank you for the reply.

At the time of creating file upload dialog, I printed out Wt::WApplication::maximumRequestSize(), the value is 204800000. Anywhere else I should look to make sure the 200M is correctly configured?

Also, while looking at lighttpd log, the larger than 64K files are sent by chunk, which is anticipated. It seems all the packets are sent/received OK. Segmentation Fault or Abort happened to the Wt application at the end of getting all the packets. Not sure where. When looking at the core dump, it does not give much info at all: (The "list" is the beginning of the Wt app.) ¶

(gdb) bt

#0 0x40c032dc in ?? () from /lib/libc.so.6

#1 0x40c032a8 in ?? () from /lib/libc.so.6

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb) list

100 //! Argument count.

101 //! @param[in] argv

102 //! Argument value strings.

103 //------------------------------------------------------------------------------------------------------------------------------------------------------------------------104 int main(int argc, char **argv)

105 {

106 char msg[128];

107 char *value; ¶

Here is the lighttpd log that shows chunked packets are received fine at lighttpd level: ¶

2013-04-19 16:02:10: (mod_fastcgi.c.1743) connect succeeded: 18

2013-04-19 16:02:10: (mod_fastcgi.c.3037) got proc: pid: 293 socket: unix:/tmp/wt.socket-0 load: 2

2013-04-19 16:02:10: (mod_fastcgi.c.2071) tosend: 0 / 133018

2013-04-19 16:02:10: (mod_fastcgi.c.2076) chunk: 0 / 65535

2013-04-19 16:02:10: (mod_fastcgi.c.2086) sending 65535 bytes from (0 / 133018) /var/tmp/lighttpd-upload-ieeMo5

2013-04-19 16:02:10: (mod_fastcgi.c.2071) tosend: 65535 / 133018

2013-04-19 16:02:10: (mod_fastcgi.c.2076) chunk: 0 / 65535

2013-04-19 16:02:10: (mod_fastcgi.c.2086) sending 65535 bytes from (65535 / 133018) /var/tmp/lighttpd-upload-ieeMo5

2013-04-19 16:02:10: (mod_fastcgi.c.2071) tosend: 131070 / 133018

2013-04-19 16:02:10: (mod_fastcgi.c.2076) chunk: 0 / 1948

2013-04-19 16:02:10: (mod_fastcgi.c.2086) sending 1948 bytes from (131070 / 133018) /var/tmp/lighttpd-upload-ieeMo5

2013-04-19 16:02:10: (mod_fastcgi.c.2118) next chunk

2013-04-19 16:02:10: (mod_fastcgi.c.2545) unexpected end-of-file (perhaps the fastcgi process died): pid: 293 socket: unix:/tmp/wt.socket-0

2013-04-19 16:02:10: (mod_fastcgi.c.3333) response not received, request sent: 134041 on socket: unix:/tmp/wt.socket-0 for /?wtd=t0730QXntjDecCcA&request=resource&resource=oqzr8dn&rand=0, closing connection

2013-04-19 16:02:10: (mod_fastcgi.c.1490) released proc: pid: 293 socket: unix:/tmp/wt.socket-0 load: 1

2013-04-19 16:02:10: (mod_fastcgi.c.2545) unexpected end-of-file (perhaps the fastcgi process died): pid: 293 socket: unix:/tmp/wt.socket-0

2013-04-19 16:02:10: (mod_fastcgi.c.3333) response not received, request sent: 997 on socket: unix:/tmp/wt.socket-0 for /?wtd=t0730QXntjDecCcA, closing connection

2013-04-19 16:02:10: (mod_fastcgi.c.1490) released proc: pid: 293 socket: unix:/tmp/wt.socket-0 load: 0

2013-04-19 16:02:11: (mod_fastcgi.c.1732) connect failed: Connection refused on unix:/tmp/wt.socket-0

2013-04-19 16:02:11: (mod_fastcgi.c.454) backend disabled for 1 seconds

2013-04-19 16:02:11: (mod_fastcgi.c.3004) backend died; we'll disable it for 1 seconds and send the request to another backend instead: reconnects: 0 load: 1

2013-04-19 16:02:11: (mod_fastcgi.c.2783) child signaled: 11

2013-04-19 16:02:11: (mod_fastcgi.c.2814) ---- fastcgi spawning

socket unix:/tmp/wt.socket-0

current: 1 / 1

2013-04-19 16:02:11: (mod_fastcgi.c.867) new proc, socket: 0 /tmp/wt.socket-0

2013-04-19 16:02:11: (mod_fastcgi.c.1541) release proc for reconnect: 1086 unix:/tmp/wt.socket-0

2013-04-19 16:02:11: (mod_fastcgi.c.1743) connect succeeded: 14

2013-04-19 16:02:11: (mod_fastcgi.c.3037) got proc: pid: 1086 socket: unix:/tmp/wt.socket-0 load: 1

2013-04-19 16:02:11: (mod_fastcgi.c.2071) tosend: 0 / 98

2013-04-19 16:02:11: (mod_fastcgi.c.2076) chunk: 0 / 98 ¶

Any tips help!

Thanks!

I figured out what happened.

In FCGIRecord.C, it allocates memory to read buffer. Buffer length has type "short". Which means the largest value is 65536. On lighttpd, the FCGI_MAX_LENGTH is 65536. When adding header and etc., FCGIRecord will try to allocate a buffer larger than 64K, while ended up allocate a buffer only the size of mod(64K). This will corrupt the memory/stack. Cause misery of uncertainty.

I attached a patch for my fix.

Hi Wei,

Thank you for searching the root cause for this.

I'm looking at your patch, and trying to understand what the minimal fix for the problem is, is it correct if I said that plainTextLength_ has to be unsigned int rather than unsigned short, and that the other fixes are more-or-less performance related?

BR,

Wim.

plainTextBufLength_ has to be unsigned int as well.

contentLength_ is OK to be unsigned short considering FCGI packet max length is limited to 0xFFFF.

Patch for the FCGIRecord.C is purely for performance improvement.

Thanks,

Wei

Ok. Patch committed.

Wim.