Re: seawasp failing, maybe in glibc allocator - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: seawasp failing, maybe in glibc allocator
Date
Msg-id alpine.DEB.2.22.394.2105181858580.371742@pseudo
Whole thread Raw
In response to Re: seawasp failing, maybe in glibc allocator  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: seawasp failing, maybe in glibc allocator  (Thomas Munro <thomas.munro@gmail.com>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: PG 14 release notes, first draft
Next
From: Nitin Jadhav
Date:
Subject: Re: Removed extra memory allocations from create_list_bounds