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
