Hi, On 2021-07-25 12:02, Chris Lamb wrote: > Hi Aurelien, > > > Version 5:6.2.4-1 built fine, so it's likely a regression introduced in > > the new upstream version. > > Thanks for the report. I just have a few minutes to look into this > right this second so (for my own convenience) I've attached the diff > between these two particular upstream versions. > > There is this entry in the upstream changelog that might be worthy of > further investigation: > > * Fix ziplist length updates on big-endian platforms (#2080) > > Do you happen to have the full log of this failing build though? I > would suspect it's something in the testsuite that's exposing this > issue, but being able to pin it down would be the ideal next step, > especially as the testsuite is so large (and there were quite a few > changes).
Yes, I have been able to get the corresponding (truncated) build log, please find it attached. For what I have remarked is that the 2560 PiB is allocated from around the beginning of the testsuite, but the crash happened way later. It might just be that there is original issue (allocating insane amount of memory) that is there for some time, but that using many part of it in one of the tests is something new. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
redis_6.2.5-1_s390x-2021-07-25T09:47:25Z.gz
Description: application/gzip
signature.asc
Description: PGP signature