The problem was in my test cases, because it tries to mock MHD. Basically I
just had to create fake instances like "struct MHD_Connection *con =
sg_alloc(256)" and fixed the tests:
https://github.com/risoflora/libsagui/commit/bd8304ebe439095312d7232aec5f88ad36a20157
On Tue, Feb 27, 2024 at 1:58 PM
Hi Evgeny,
unsigned int daemon_flags = MHD_USE_INTERNAL_POLLING_THREAD |
MHD_USE_POLL | MHD_ALLOW_SUSPEND_RESUME | MHD_USE_ERROR_LOGResponse is
generated in a dedicated thread.I will try to write a testcase.
Best wishes
Am Dienstag, dem 27.02.2024 um 18:19 +0100 schrieb Evgeny Grin:
> Hi Markus,
Hi Markus,
Can you share a larger piece of code or give more details, like used
mode (internal polling or external polling), polling function, other
relevant information?
--
Evgeny
27-Feb-2024 17:58 (UTC+0100), Markus Doppelbauer via libmicrohttpd wrote:
What was your issue? How did you fix
What was your issue? How did you fix it?
I am getting "Assertion failed" from "connection.c:6864": case
MHD_CONNECTION_CHUNKED_BODY_UNREADY:
mhd_assert (0);
This happens if I create a response from callback, e.g.:
struct MHD_Response *response = MHD_create_response_from_callback(
MHD_SIZE
Problem fixed! \o/
I have a couple of test cases that call some MHD functions internally, but
after creating fake MHD_Connections to pass to the functions instead of
NULL the problem was fixed.
Thanks a lot guys!
On Mon, Feb 26, 2024 at 5:41 PM silvioprog wrote:
> Seems like it will be hard to
Hey Christian. =)
Yes sure, I'll try to reproduce the problem and provide all the logs.
On Mon, Feb 26, 2024 at 4:23 PM Christian Grothoff
wrote:
> Hi Silvio,
>
> Well, we didn't try to break anything with the update, so you shouldn't
> have to change anything on your side either. Can you send
Hi Silvio,
Well, we didn't try to break anything with the update, so you shouldn't
have to change anything on your side either. Can you send us a stack
trace/valgrind output and/or test code to reproduce? That'll expedite a
fix...
Happy hacking!
-Christian
On 2/26/24 19:44, silvioprog wrot
Remove MHD_OPTION_NOTIFY_COMPLETED --- or pass two extra arguments with
the function and closure you want MHD to call upon completion. Right
now, you're telling MHD to jump to a bad address upon connection completion.
On 3/3/23 15:02, klemens wrote:
Hi all,
I have an issue with a segfault I
Hi Tim,
Technically this cannot happen, the 'digest != NULL' check before
correlates with password == NULL and vice versa. But, I'm happy to add
an additional assertion to make static analysis happier...
I've applied your realloc() patch as well.
Happy hacking!
Christian
On 4/14/19 9:08 PM, Ti
Hi!
We need to understand the issue better before updating the documentation
on this kind of speculative fix -- especially as the fix may work for
your application, but may not be general.
-Christian
On 07/19/2015 08:16 PM, Markus Doppelbauer wrote:
> Hello,
>
> Since I have moved the callM
Hello,
Since I have moved the call
MHD_get_daemon_info( MHD_DAEMON_INFO_CURRENT_CONNECTIONS )
toMHD_NotifyConnectionCallback() no segfaults did occur.
Could this be true? Maybe update the documentation?
Thanks a lot
Markus
Am Samstag, den 18.07.2015, 17:25 +0200 schrieb Markus Doppelbaue
Hi,
Maybe it is not allowed to call
MHD_get_daemon_info( MHD_DAEMON_INFO_CURRENT_CONNECTIONS )
at any time from any thread? Maybe only from
MHD_NotifyConnectionCallback() ?
Thanks a lot
Markus
Am Samstag, den 18.07.2015, 17:18 +0200 schrieb Markus Doppelbauer:
> Hi,
>
> Sorry - I can't prov
Hi,
Sorry - I can't provide a testcase - I only have the coredumps.
IMHO the problem is, that two threads work in the same critical section
MHD_cleanup_connections()
#1 MHD-Thread from microhttpd/daemon.c:2937 from
MHD_select_thread()
#2 Worker-thread from microhttpd/daemon.c:4630from
MHD
Hi!
I'm sorry, but I still don't even see how the race could happen.
I checked all calls to MHD_pool_destroy, and the respective connection
is always in 1 of 3 disjoint ownership states:
1) never aliased, about to be freed (failures during connection setup)
2) 'active' connection, going down with
Sorry the NULL patch is the wrong fix - it makes it only more
unlikely to double-free() the pool. The scheduler could interrupt
right before "pos->pool = NULL".
Maybe the only solution is either to protect "MHD_cleanup_connections()"
with a mutex or to remove the call to "MHD_cleanup_connections()
Hello,
Maybe simply nullify "pos->pool" after free()?
Thanks a lot
Markus
}
}
MHD_pool_destroy (pos->pool);
+ pos->pool = NULL;
#if HTTPS_SUPPORT
if (NULL != pos->tls_session)
gnutls_deinit (pos->tls_session);
Hello,
Maybe simply nullify "pos->pool" after MHD_pool_destroy()"?
Should avoid this double-free().
Or is there a chance to get the number of open connections
without calling "MHD_cleanup_connections()"?
Thanks a lot
Markus
}
}
MHD_pool_destroy (pos->pool);
+
17 matches
Mail list logo
