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
Список 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 по дате отправления: