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