when I return MHD_NO in my ahc_function, the connection gets stuck from time to time.
I want to upload data to a server via POST and store it in a buffer.
If that buffer is full, I want to force the connection to close and the upload process to abort by returning MHD_NO, which - as expected - gives "Internal application error, closing connection"
That works most of the time but sometimes the connection just does not close.
I then used gdb to see what was going on. This is what I've got:
(gdb) info threads
Id Target Id Frame
6 Thread 0x7f6ba8a6f700 (LWP 22280) "****" 0x00007f6bb2bcd763 in select () at ../sysdeps/unix/syscall-template.S:82
5 Thread 0x7f6ba826e700 (LWP 22282) "****" 0x00007f6bb2bcd763 in select () at ../sysdeps/unix/syscall-template.S:82
4 Thread 0x7f6ba785f700 (LWP 22283) "****" 0x00007f6bb2ba008d in nanosleep () at ../sysdeps/unix/syscall-template.S:82
3 Thread 0x7f6ba685d700 (LWP 22295) "****" 0x00007f6bb2bc8a43 in __GI___poll (fds=<optimized out>, nfds=<optimized out>,
timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
2 Thread 0x7f6ba585b700 (LWP 22299) "****" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
* 1 Thread 0x7f6bb5075740 (LWP 22279) "****" 0x00007f6bb2bc8a43 in __GI___poll (fds=<optimized out>, nfds=<optimized out>,
timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
The important threads here are 6, 5 and 3.
6 and 5 are running on the server and thread 3 handles the client side of the connection.
Here are their traces:
[Switching to thread 3 (Thread 0x7f6ba685d700 (LWP 22295))]
#0 0x00007f6bb2bc8a43 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>)
at ../sysdeps/unix/sysv/linux/poll.c:87
87 in ../sysdeps/unix/sysv/linux/poll.c
(gdb) bt
#0 0x00007f6bb2bc8a43 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>)
at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00007f6bb22786d4 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4
#2 0x00007f6bb2271955 in curl_multi_wait () from /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4
#3 0x00007f6bb226adae in curl_easy_perform () from /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4
#4 0x00007f6bb4b95f65 in helper::client::HttpClient::doRequest (this=0x7f6b9002b5e0, data="">
#5 0x00007f6bb4b95d4d in helper::client::HttpClient::sendRequest (this=0x7f6b9002b5e0, fields=..., dataFieldKey=...,
buffer=0x7f6b9c000b00)
...
[Switching to thread 5 (Thread 0x7f6f0f31e700 (LWP 20747))]
#0 0x00007f6f19c7d763 in select () at ../sysdeps/unix/syscall-template.S:82
82 in ../sysdeps/unix/syscall-template.S
(gdb) bt
#0 0x00007f6f19c7d763 in select () at ../sysdeps/unix/syscall-template.S:82
#1 0x00007f6f19769bb3 in MHD_select (daemon=0x1564800, may_block=1) at daemon.c:1469
#2 0x00007f6f19769d85 in MHD_select_thread (cls=0x1564800) at daemon.c:1729
#3 0x00007f6f1a6b7e9a in start_thread (arg=0x7f6f0f31e700) at pthread_create.c:308
#4 0x00007f6f19c843fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5 0x0000000000000000 in ?? ()
Thread 6: (ident zu Thread 5)
[Switching to thread 6 (Thread 0x7f6f0fb1f700 (LWP 20745))]
#0 0x00007f6f19c7d763 in select () at ../sysdeps/unix/syscall-template.S:82
82 in ../sysdeps/unix/syscall-template.S
(gdb) bt
#0 0x00007f6f19c7d763 in select () at ../sysdeps/unix/syscall-template.S:82
#1 0x00007f6f19769bb3 in MHD_select (daemon=0x15486c0, may_block=1) at daemon.c:1469
#2 0x00007f6f19769d85 in MHD_select_thread (cls=0x15486c0) at daemon.c:1729
#3 0x00007f6f1a6b7e9a in start_thread (arg=0x7f6f0fb1f700) at pthread_create.c:308
#4 0x00007f6f19c843fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5 0x0000000000000000 in ?? ()
As you can see I am using libcurl on the client side and call curl_easy_perform in thread 3.
I also noticed something strange when I took a look at the TCP states of the sockets on each side:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name Timer
tcp 0 224748 localhost:53500 localhost:http-alt CLOSE_WAIT - unkn-4 (1.52/0/0)
tcp 341202 0 localhost:http-alt localhost:53500 FIN_WAIT2 - off (0.00/0/0)
As you can see, the socket on the server is in FIN_WAIT2 and the socket on the client in CLOSE_WAIT.
As I understood it the client should change its state to LAST_ACK and then send FIN to the server, but it seems like this never happens.
My question is, has anybody else experienced something similar before?
Do you know how to solve this problem?
Is it a problem caused by libcurl or by libmicrohttp?
I want to thank you in advance for your help.
Best regards,
Dozzler
PS: I use libmicrohttpd-0.9.27