Re: seawasp failing, maybe in glibc allocator

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: seawasp failing, maybe in glibc allocator
Дата
Msg-id alpine.DEB.2.22.394.2105181858580.371742@pseudo
обсуждение исходный текст
Ответ на Re: 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
>> The issue is non-deterministically triggered in contrib checks, either in
>> int or ltree, but not elsewhere. This suggests issues specific to these
>> modules, or triggered by these modules. Hmmm…
>
> Hmm, yeah.  A couple of different ways that ltreetest fails without crashing:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=seawasp&dt=2021-05-13%2001%3A17%3A15
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=seawasp&dt=2021-05-12%2017%3A17%3A15
>
> Otherwise it's mostly free() blowing up, and one case of an assertion
> failure in llvm::StringMapImpl::RemoveKey, I guess before free() is
> reached:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=seawasp&dt=2021-05-14%2009%3A17%3A15

It seems that the upload of the valgrind run (many hours…) failed on "413 
request entity too large", and everything seems to have been cleaned 
despite the "--keepall" I think I put when I started the run.

Not sure about the best way to proceed.

-- 
Fabien.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: PG 14 release notes, first draft
Следующее
От: Nitin Jadhav
Дата:
Сообщение: Re: Removed extra memory allocations from create_list_bounds