Hi,
On Wed, Jul 05, Lukas Tribus wrote:
> Am 05.07.2017 um 13:58 schrieb Emeric Brun:
> >
> >> Another bisect (this time with -dM or -DDEBUG_MEMORY), another commit...
> >> Now it points to 23e9e931 (MINOR: log: Add logurilen tunable).
> >>
> >>
> > Hi Lukas,
> >
> > Indeed this commit introduced
Hi Emeric,
Am 05.07.2017 um 13:58 schrieb Emeric Brun:
>
>> Another bisect (this time with -dM or -DDEBUG_MEMORY), another commit...
>> Now it points to 23e9e931 (MINOR: log: Add logurilen tunable).
>>
>>
> Hi Lukas,
>
> Indeed this commit introduced a regression.
>
> The commit in attachment
Hi Aleks,
On Wed, Jul 05, 2017 at 02:12:13PM +0200, Aleksandar Lazic wrote:
> Amazing how fast this Open source community is ;-)
>
> Open : Dienstag, 04. Juli 2017, 21:56:09 (Tue, 4 Jul 2017 21:56:09 +0200)
> Close: Mittwoch, 05. Juli 2017, 14:00:32 (Wed, 5 Jul 2017 14:00:32 +0200)
>
>
On Wed, Jul 05, 2017 at 01:58:03PM +0200, Emeric Brun wrote:
> Indeed this commit introduced a regression.
>
> The commit in attachment should fix the issue.
Awesome, now merged, thanks! And it was specific to 1.8-dev.
Willy
On 07/05/2017 12:25 AM, Lukas Tribus wrote:
>
> Am 04.07.2017 um 23:18 schrieb Willy Tarreau:
>> On Tue, Jul 04, 2017 at 10:57:08PM +0200, Lukas Tribus wrote:
>>> The call trace doesn't really look different when I used -dM or
>>> -DDEBUG_MEMORY.
>>>
>>> I was able to get a different trace by
Am 04.07.2017 um 23:18 schrieb Willy Tarreau:
> On Tue, Jul 04, 2017 at 10:57:08PM +0200, Lukas Tribus wrote:
>> The call trace doesn't really look different when I used -dM or
>> -DDEBUG_MEMORY.
>>
>> I was able to get a different trace by actually connecting to a backend
>> however,
>>
On Tue, Jul 04, 2017 at 10:57:08PM +0200, Lukas Tribus wrote:
> The call trace doesn't really look different when I used -dM or
> -DDEBUG_MEMORY.
>
> I was able to get a different trace by actually connecting to a backend
> however,
> (instead of showing an haproxy internal 403 error):
(...)
Hi,
Am 04.07.2017 um 22:35 schrieb Willy Tarreau:
>
> This one should theorically not be caused by an issue in the task scheduler,
> unless we're reusing something already freed. We could retry it with -dM
> and/or -DDEBUG_MEMORY to force earlier corruption to pop up.
The call trace doesn't
On Tue, Jul 04, 2017 at 10:29:27PM +0200, Lukas Tribus wrote:
> > On Tue, Jul 04, 2017 at 09:56:09PM +0200, Lukas Tribus wrote:
> >> Hi Emeric,
> >>
> >>
> >> since 8d85aa4 ("BUG/MAJOR: map: fix segfault during 'show
> >> map/acl' on cli") my setup crashes when a request comes in
> >> going
Hi Willy,
Am 04.07.2017 um 22:24 schrieb Willy Tarreau:
> Hi Lukas,
>
> On Tue, Jul 04, 2017 at 09:56:09PM +0200, Lukas Tribus wrote:
>> Hi Emeric,
>>
>>
>> since 8d85aa4 ("BUG/MAJOR: map: fix segfault during 'show
>> map/acl' on cli") my setup crashes when a request comes in
>> going through
Hi Lukas,
On Tue, Jul 04, 2017 at 09:56:09PM +0200, Lukas Tribus wrote:
> Hi Emeric,
>
>
> since 8d85aa4 ("BUG/MAJOR: map: fix segfault during 'show
> map/acl' on cli") my setup crashes when a request comes in
> going through SSL termination.
>
> memory corruption, invalid pointers, double
Hi Emeric,
since 8d85aa4 ("BUG/MAJOR: map: fix segfault during 'show
map/acl' on cli") my setup crashes when a request comes in
going through SSL termination.
memory corruption, invalid pointers, double free is what haproxy
randomly crashes with.
Here 2 crashes with full backtrace:
*** Error
12 matches
Mail list logo
