Re: seawasp failing, maybe in glibc allocator

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: seawasp failing, maybe in glibc allocator
Дата
Msg-id alpine.DEB.2.22.394.2105100837110.494329@pseudo
обсуждение исходный текст
Ответ на seawasp failing, maybe in glibc allocator  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: seawasp failing, maybe in glibc allocator  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Allow batched insert during cross-partition updates
Следующее
От: Peter Smith
Дата:
Сообщение: GetSubscriptionRelations declares too many scan keys