View Issue Details

IDProjectCategoryView StatusLast Update
0006635libmicrohttpdHTTP POSTpublic2024-01-21 13:34
Reporteryan01.guo Assigned ToChristian Grothoff  
PrioritynormalSeverityminorReproducibilityrandom
Status closedResolutionunable to reproduce 
Platformx86OSCentOS7.3OS Version7.3.1611
Product Version0.9.68 
Fixed in Version0.9.76 
Summary0006635: HTTP server stuck while trying to resume connection to handle Transfer-encoding chunked data
DescriptionHello, 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 ReproduceThe same as the discription above.
Additional Informationtop -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
TagsNo tags attached.

Activities

Christian Grothoff

2020-11-01 23:15

manager   ~0017079

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

Christian Grothoff

2024-01-21 13:34

manager   ~0020939

No feedback from reporter, cannot reproduce.

Issue History

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