Hi José,
On 28.09.2021 18:44, José Bollo wrote:
Function MHD_run_wait() was added for upcoming version 0.9.74, but it
does not return flag "need to re-run". MHD_get_timeout() already
serves for this purpose.
I finally had time to look at this new function. It can be improved by
returning a sta
On Sat, 25 Sep 2021 17:35:42 +0300
Evgeny Grin wrote:
> Hi José,
>
> Thanks for the report!
>
> If MHD needs to (re-)run MHD_run() immediately MHD_get_timeout() must
> return zero timeout.
> You don't need to re-run it if no timeout is returned.
> Zero timeout if connection cleanup is pending
Hi José,
Thanks for the report!
If MHD needs to (re-)run MHD_run() immediately MHD_get_timeout() must
return zero timeout.
You don't need to re-run it if no timeout is returned.
Zero timeout if connection cleanup is pending was enforced by Christian
in version 0.9.73.
See https://lists.gnu.o
Hi José,
Original Message
From: José Bollo
Sent: Friday, September 24, 2021, 15:56 UTC+3
Subject: [libmicrohttpd] race condition on 0.9.73
Hi Evgeny, Hi all,
Firstly, protecting MHD_run made the job, the crash disappears and
valgrind is happy. Thank you for that efficient
Hi Evgeny,
Seems fixed on my side. I enforced single call of MHD_run. But I added
a special treatment to enforce call to MHD_run even if MHD_get_timeout
returned a timeout different of zero.
This last point was discussed in the ML thread
https://lists.gnu.org/archive/html/libmicrohttpd/2020-12/
Hi Evgeny, Hi all,
Firstly, protecting MHD_run made the job, the crash disappears and
valgrind is happy. Thank you for that efficient support.
Secundly, I'm still seeing and investigating an issue. Sometime, the
queued response (MHD_queue_response) is not sent. Here again, I think
that it is a ra
On Thu, 23 Sep 2021 18:12:39 +0200
Markus Doppelbauer wrote:
> > ... because valgrind point out ...
>
> You should replace (slow) valgrind with (fast) address-sanatizer.
> Simply tell GCC (or clang) to compile with: -fsanitize=address -fno-
> omit-frame-pointer
>
Thank you Markus for the
On 23.09.2021 22:35, José Bollo wrote:
On Thu, 23 Sep 2021 19:57:23 +0300
Evgeny Grin wrote:
On 23.09.2021 18:43, José Bollo wrote:
For sure you can run MHD with "external poll" mode, but you must
ensure that only single thread is calling MHD_run() at any given
moment of time.
Okay, that
On Thu, 23 Sep 2021 19:57:23 +0300
Evgeny Grin wrote:
> On 23.09.2021 18:43, José Bollo wrote:
> >> For sure you can run MHD with "external poll" mode, but you must
> >> ensure that only single thread is calling MHD_run() at any given
> >> moment of time.
> >
> > Okay, that is a good hint, tha
On 23.09.2021 18:43, José Bollo wrote:
For sure you can run MHD with "external poll" mode, but you must
ensure that only single thread is calling MHD_run() at any given
moment of time.
Okay, that is a good hint, thanks. I'm going to first track concurrent
use of MHD_run. FYI, I tried the late
> ... because valgrind point out ...
You should replace (slow) valgrind with (fast) address-sanatizer.
Simply tell GCC (or clang) to compile with: -fsanitize=address -fno-
omit-frame-pointer
On Thu, 23 Sep 2021 18:14:24 +0300
Evgeny Grin wrote:
> Hi José,
Hi Evgeny,
> For sure you can run MHD with "external poll" mode, but you must
> ensure that only single thread is calling MHD_run() at any given
> moment of time.
Okay, that is a good hint, thanks. I'm going to first track concur
Hi José,
For sure you can run MHD with "external poll" mode, but you must ensure
that only single thread is calling MHD_run() at any given moment of time.
If you want to call several copies of MHD_run(), make sure that you have
individual copies of MHD for each thread (start MHD by
MHD_start
Hi,
My program sends answers in threads and runs the main MHD loop on
external event in an other thread and I get crashes. I'm suspecting
LMHD because valgrind point out that the memory for response is
used after free in a kind of race condition between internals of MHD.
Is it a known issue fixed
14 matches
Mail list logo
