View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0006635 | libmicrohttpd | HTTP POST | public | 2020-10-31 08:14 | 2024-01-21 13:34 |
Reporter | yan01.guo | Assigned To | Christian Grothoff | ||
Priority | normal | Severity | minor | Reproducibility | random |
Status | closed | Resolution | unable to reproduce | ||
Platform | x86 | OS | CentOS7.3 | OS Version | 7.3.1611 |
Product Version | 0.9.68 | ||||
Fixed in Version | 0.9.76 | ||||
Summary | 0006635: HTTP server stuck while trying to resume connection to handle Transfer-encoding chunked data | ||||
Description | Hello, I use libmicrohttpd to support my http server. A post request would be requested to my server, and the http body contained a file. Maybe a few K-Bytes or a few M-Bytes. I realized a speed-limit plan by receive a few bytes, suspend the connection(by function MHD_suspend_connection) and then start a timer to wait for next period to resume the connection(by function MHD_resume_connection), and receive another few bytes. Repeat this operation many times until the whole file/data is received. There was nothing wrong while the http-client request header carrying with Content-length. If the http-client carry Transfer-encoding:chunked instead of Content-length, the problem appear. The program stuck in the function MHD_resume_connection while dealling with the last chunked data, and CPU run 100%. I tried many different sizes of files to fill the http body(bigger than 65536 bytes), it appears mostly. I tried many versions of libmicrohttpd from 0.9.59 to 0.9.68, it appeared the same performance. | ||||
Steps To Reproduce | The same as the discription above. | ||||
Additional Information | top -H -p PID: top - 15:04:32 up 12 days, 14:39, 5 users, load average: 3.23, 2.94, 2.71 Threads: 27 total, 1 running, 26 sleeping, 0 stopped, 0 zombie %Cpu(s): 26.2 us, 2.8 sy, 0.0 ni, 69.8 id, 0.2 wa, 0.0 hi, 1.0 si, 0.0 st KiB Mem : 16225860 total, 9711572 free, 4490756 used, 2023532 buff/cache KiB Swap: 8257532 total, 8257532 free, 0 used. 11147328 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19339 root 20 0 2859744 22372 6624 R 99.9 0.1 2:52.43 MHD-worker 19348 root 20 0 2859744 22372 6624 S 0.3 0.1 0:00.03 defaultName 19322 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.02 frs.spu 19323 root -91 0 2859744 22372 6624 S 0.0 0.1 0:00.00 frs.spu 19324 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.01 defaultName 19325 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19326 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19332 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19333 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19334 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19335 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19336 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 MHD-worker 19337 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 MHD-worker 19338 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 MHD-worker 19340 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19342 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19343 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19344 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19345 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19346 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19347 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19349 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19350 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19351 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19352 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19354 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName 19363 root 20 0 2859744 22372 6624 S 0.0 0.1 0:00.00 defaultName stack info: Thread 16 (Thread 0x522fab40 (LWP 19339)): #0 0x08403178 in resume_suspended_connections () #1 0x08405022 in MHD_epoll () #2 0x0840597d in MHD_polling_thread () #3 0x0840b1a7 in named_thread_starter () #4 0xf76fcbbc in start_thread () from /lib/libpthread.so.0 #5 0xf4f310de in clone () from /lib/libc.so.6 | ||||
Tags | No tags attached. | ||||
|
Can you please provide a test case / example code or compile with debug symbols and extract some information about the 100%-cpu burning loop (like key variables accessed and their values)? What you write is a bit little to go on |
|
No feedback from reporter, cannot reproduce. |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-10-31 08:14 | yan01.guo | New Issue | |
2020-11-01 23:15 | Christian Grothoff | Note Added: 0017079 | |
2023-02-08 16:18 | Christian Grothoff | Assigned To | => Christian Grothoff |
2023-02-08 16:18 | Christian Grothoff | Status | new => feedback |
2024-01-21 13:34 | Christian Grothoff | Status | feedback => resolved |
2024-01-21 13:34 | Christian Grothoff | Resolution | open => unable to reproduce |
2024-01-21 13:34 | Christian Grothoff | Fixed in Version | => 0.9.76 |
2024-01-21 13:34 | Christian Grothoff | Note Added: 0020939 | |
2024-01-21 13:34 | Christian Grothoff | Status | resolved => closed |