On Fri, May 10, 2019 at 11:52:31AM +0200, Willy Tarreau wrote:
> > Actually I think there's an additional change needed in my patch. By
> > passing the parameters to HA_ATOMIC_CAS we end up attempting to
> > dereference a void *. So this should needs to cast to a proper type. For
> > what it's
> What I find very strange is why you're possibly the only one seeing this
> (and maybe also @serimin on github issue #94). If we could figure what
> makes your case specific it could help narrow the issue down. I'm seeing
> that you have a very simple Lua service to respond to health checks, so
>
Patch applied, finger crossed, testing! :-)
Thanks!
sob., 11 maj 2019 o 14:58 Willy Tarreau napisał(a):
> On Sat, May 11, 2019 at 11:01:42AM +0200, Willy Tarreau wrote:
> > On Sat, May 11, 2019 at 10:52:35AM +0200, Willy Tarreau wrote:
> > > I certainly made a few reasoning mistakes above but
Hi Patrick,
On Fri, May 10, 2019 at 09:17:25AM -0400, Patrick Hemmer wrote:
> So I see a few updates on some of the other 100% CPU usage threads, and that
> some fixes have been pushed. Are any of those in relation to this issue? Or
> is this one still outstanding?
Apparently we've pulled a long
On Sat, May 11, 2019 at 11:01:42AM +0200, Willy Tarreau wrote:
> On Sat, May 11, 2019 at 10:52:35AM +0200, Willy Tarreau wrote:
> > I certainly made a few reasoning mistakes above but I don't see anything
> > in the code preventing this case from happening.
> >
> > Thus I'd like you to try the
On Sat, May 11, 2019 at 09:56:18AM +0200, Willy Tarreau wrote:
> I'm back to auditing the code to figure how we can free an h2s without
> first detaching it from the lists. I hope to have yet another patch to
> propose to you.
So I'm seeing something which bothers me in the code. Since I'm not at
Hi Maciej,
On Fri, May 10, 2019 at 06:45:21PM +0200, Maciej Zdeb wrote:
> Olivier, it's still looping, but differently:
>
> 2609list_for_each_entry_safe(h2s, h2s_back, >send_list, list) {
> (gdb) n
> 2610if (h2c->st0 >= H2_CS_ERROR || h2c->flags &
> H2_CF_MUX_BLOCK_ANY)
>
Hi Thierry,
I just stumbled upon the patch series below you sent a while ago. I see
that you didn't receive any feedback on it, but see no reason not to
merge it, as it must still be valid given that it's outside of the
core. Do you have any objection against it getting merged ? Or maybe
even a
Hello,
I would like to inquire about publishing a guest post on your site - unique
& objective content, not self-promotional and of course relevant to your
site's audience.
We'd be willing to pay for it.
Please let me know how can we proceed.
Looking forward to working with you,
Levente
Hi,
This is a friendly bot that watches fixes pending for the next haproxy-stable
release! One such e-mail is sent periodically once patches are waiting in the
last maintenance branch, and an ideal release date is computed based on the
severity of these fixes and their merge date. Responses
Hi,
This is a friendly bot that watches fixes pending for the next haproxy-stable
release! One such e-mail is sent periodically once patches are waiting in the
last maintenance branch, and an ideal release date is computed based on the
severity of these fixes and their merge date. Responses
On Sat, May 11, 2019 at 10:52:35AM +0200, Willy Tarreau wrote:
> I certainly made a few reasoning mistakes above but I don't see anything
> in the code preventing this case from happening.
>
> Thus I'd like you to try the attached patch which is supposed to prevent
> this scenario from happening.
12 matches
Mail list logo
