In check_argument_match() a buffer is allocated using strdup() but freed nowhere.
I wouldn't have noticed this leak if it wasn't for valgrind because if a URI is requested without any arguments (my usual case)
the buffer that gets allocated has 'only' a length of 1 byte, thus memory usage will build up very slowly over time.
The patch attached fixes it.
Btw. the indentation of that file is a mess, tabs and spaces are mixed :-|
Regards,
Andreas
Hey,
I'm debugging a problem with a crash in MHD_select_thread. We had
MHD_start_daemon_va fail while creating worker threads with the following
error: "file descriptor for worker control pipe exceeds maximum value". We
know what caused this error and are fixing it. But the problem was that a
MHD_select_thread worker thread was left running in the background after
MHD_start_daemon_va returned failure. I think the problem is from this
code in the thread_failed case in daemon.c:
/* Shutdown worker threads we've already created. Pretend
as though we had fully initialized our daemon, but
with a smaller number of threads than had been
requested. */
daemon->worker_pool_size = i - 1;
MHD_stop_daemon (daemon);
return NULL;
From the code, it looks like "i" is actually the number of threads that
were successfully created, so the "i - 1" in this code will leave an extra
thread hanging since MHD_stop_daemon will clean up one less thread than it
should. I'll probably try to work up a test to verify removing the "- 1"
is correct, but that could take me some time so I wanted to make sure I
wasn't missing something obvious before heading down that path.
~JareD
He is right, this patch fixes it.
Trying to fix this buildslave error:
make[3]: *** No rule to make target '../../src/platform/libplatform_interface.la', needed by 'libmicrohttpd.la'. Stop.
The MHD goes in a busy loop when it is configured with MHD_USE_POLL_INTERNALLY and a connection times out.
When the connection times out, the connection is closed at connection.c:2646, which sets connection->event_loop_info = MHD_EVENT_LOOP_INFO_CLEANUP.
When the loop info is set to MHD_EVENT_LOOP_INFO_CLEANUP, the main function of the thread loop, MHD_poll_all, never calls back the connection idle callback, which would have cleaned the connection and exit the loop.
I resolved the issue in my development code by adding pos->idle_handler (pos) at daemon.c:2477 in MHD_poll_all (SVN 35533).
The busy loop could be tested using a small enough connection timeout and netcat:
nc -v -w 100 <IP ADDRESS> <IP PORT>
CPU usage will reach 100% in one of the CPU and will remain at that level even when the netcat has closed its end of the connection.
Thanks,
Louis Benoit
Hi,
I am doing test with HTTPS at low bit rate for large files using:
wget -v --no-check-certificate --limit-rate=1000 https://....
When the MHD daemon is configured with MHD_USE_EPOLL_INTERNALLY_LINUX_ONLY, I noticed that the thread takes 100% CPU, whereas
the MHD_USE_POLL_INTERNALLY configuration show a normal CPU usage.
Adding logs I see that the busy loops takes place at daemon.c, line 2605 (0.9.38):
daemon->eready_tail never gets NULL most probably due to connection.c, line 2671 to 2721
Thanks,
Louis
Louis wrote:
There is a change of behavior between 0.9.37 and 0.9.38.
When a client adds a "Connection: close" header in 0.9.37, MHD adds a "Connection: close" header to its response and then
close the connection (as suggested in rfc2616, section 8.1.2.1).
The "Connection: close" header is not added in 0.9.38.
I looked into the 0.9.38 code and the code that prevents the inclusion of the "Connection: close" header is at line 773 of connection.c.
if ( ( (NULL != client_requested_close) ||
(MHD_YES == connection->read_closed) ) &&
(NULL == response_has_close) &&
(0 != (connection->response->flags & MHD_RF_HTTP_VERSION_1_0_ONLY) ) )
must_add_close = MHD_YES;
Shouldn't it read
if ( ( (NULL != client_requested_close) ||
(MHD_YES == connection->read_closed) ||
(0 != (connection->response->flags & MHD_RF_HTTP_VERSION_1_0_ONLY) ) ) &&
(NULL == response_has_close) )
must_add_close = MHD_YES;
Thanks,
Louis Benoit
Can't test POLL mode as MHD didn't support POLL on W32. The reason - winsock implementation is somehow different from POSIX one. libcurl initially added poll support for win32 but later it was removed. I didn't check specific reason so for safety MHD didn't use POLL on W32. However I leave changes for POLL code "as is" in case that we will add support for POLL on win32.
SELECT mode now works perfectly. Shutdown processed without any delay.
May be some comments will be good addition.
Patch is attached.
--
Evgeny
09.04.2015, 17:28, "Christian Grothoff" <christian@grothoff.org>:
> Hi Evgeny,
>
> I've tried to put together a patch for the issue, but as I'm on
> GNU/Linux, I cannot even test if the patch compiles... Please let me
> know if it works (and please test with POLL and SELECT separately), at
> least in principle I think this is roughly what the patch should look
> like...
>
> Happy hacking!
>
> Christian
>
> On 04/09/2015 03:25 PM, Evgeny Grin wrote:
>> If HAVE_LISTEN_SHUTDOWN is not defined (as on win32), pipe is used
>> automatically.
>> But pipe is monitored only in main "select()" thread. It's not
>> monitored in "connection" thread.
>>
>> Best Wishes,
>> Evgeny Grin
>>
>> On 04/09/2015 12:56 PM, Evgeny Grin wrote:
>>> Hi Christian!
>>>
>>> Another issue on win32, 100% reproducible.
>>> When running Kodi unittests, MHD always takes 120 seconds to shutdown.
>>>
>>> How to reproduce:
>>> * Start MHD with THREAD_PER_CONNECTION | DEBUG and some static
>> response,
>>> * Generate one http 1.1 request with libcurl. Notice that libcurl
>> always add keep-alive for http 1.1.
>>> * Let MHD to process request and answer with response.
>>> * MHD will stay with master thread and one connection thread waiting
>> for additional requests from same client.
>>> * Call MHD shutdown. Main thread will shutdown all sockets, but
>> additional connection thread will stay at MHD_sys_select_ and will get
>> notification about socket shutdown only after 2 minutes. May be it's
>> after libcurl will close connection.
>>> Again - have no idea how to fix it properly. Use pair of sockets
>> (emulated pipe) for each connection thread? Add daemon pipe FD to
>> select() in connection thread?
I was trying to use MHD_suspend_connection() and MHD_resume_connection() to implement long polling on a request. I am using options MHD_USE_SELECT_INTERNALLY and MHD_USE_POLL options. I noticed the server thread went to 100% CPU after the first MHD_resume_connection() call. Looking at the code in MHD_poll_all() I can see that the file descriptor from daemon->wpipe[0] gets inserted into the list of file descriptors to poll but this file descriptor is never read so every time this function is called it returns immediately. The code works fine if I drop to using just MHD_USE_SELECT_INTERNALLY.
The patch below fixes the problem.
Regards,
Denis
