Re: seawasp failing, maybe in glibc allocator

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.