Re: seawasp failing, maybe in glibc allocator - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: seawasp failing, maybe in glibc allocator
Date
Msg-id alpine.DEB.2.22.394.2105100837110.494329@pseudo
Whole thread Raw
In response to seawasp failing, maybe in glibc allocator  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: seawasp failing, maybe in glibc allocator
List pgsql-hackers
Hello Thomas,

> Since seawasp's bleeding-edge clang moved to "20210226", it failed
> every run except 4, and a couple of days ago it moved to "20210508"
> and it's still broken.

Indeed I have noticed that there is indeed an issue, but the investigation 
is not very high on my current too deep pg-unrelated todo list.

> It's always like this:
>
> 2021-05-09 03:31:37.602 CEST [1678796:171] pg_regress/_int LOG:
> statement: RESET enable_seqscan;
> corrupted double-linked list
>
> ... which doesn't appear in our code, but matches this:
>
> https://github.com/bminor/glibc/blob/cedbf6d5f3f70ca911176de87d6e453eeab4b7a1/malloc/malloc.c#L1645

> No reason to think it's our fault, but it'd be nice to see a
> backtrace.

ISTM it looks like some kind of memory corruption. If I'd have to guess 
between glibc, clang and pg, not sure which one I'd chose between the two 
laters potential bug sources.

> Is gdb installed, and are core files being dumped by that SIGABRT, and 
> are they using the default name (/proc/sys/kernel/core_pattern = core), 
> which the BF can find with the value it's using, namely 'core_file_glob' 
> => 'core*'?

Nope:

   sh> cat /proc/sys/kernel/core_pattern
   |/usr/share/apport/apport %p %s %c %d %P %E

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Allow batched insert during cross-partition updates
Next
From: Peter Smith
Date:
Subject: GetSubscriptionRelations declares too many scan keys