Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jUk1b-0002XF-9d for pgsql-bugs@arkaria.postgresql.org; Sat, 02 May 2020 04:45:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jUk1Z-00016y-EQ for pgsql-bugs@arkaria.postgresql.org; Sat, 02 May 2020 04:45:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jUk1Z-00016r-5w for pgsql-bugs@lists.postgresql.org; Sat, 02 May 2020 04:45:13 +0000 Received: from mail-lf1-x141.google.com ([2a00:1450:4864:20::141]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jUk1R-0004XS-4v for pgsql-bugs@lists.postgresql.org; Sat, 02 May 2020 04:45:12 +0000 Received: by mail-lf1-x141.google.com with SMTP id u10so5350352lfo.8 for ; Fri, 01 May 2020 21:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=K123x2bQmJmrolFQ0Jj29G9Kdl3IdMgDQES8ggPyqxA=; b=Sgk3HZS89JhgH58aYnj2GM9XKDfkoYeKIWUQgFWPfEPrUUh0OQ4oiWsdfOHuAezEv/ eqPNKphzQSG0bcZTKY4d52DgZY0ro/8ssQfgaFEIdD4/zsWUOnUsciI5nM2zilI68v+u QBoUBjs6QdsVswvJKzoV1wwuRqx9bOJIirad00jBuffsnJnZekfYIt5ALfwf0WLuvvq1 0wEDlYG/NQZ9vXx3YDjpK1Xu2l8c8brFFMUs7c1CRp6UYjAFToDfwfzdrFKvq49zg+yO Svq6pIpzUSNdjdufAdHZuQ9Db7EUoFs0WgXtvxOyYV4GyOlQxq2gww7Rh+1I7hSV4TXa 4dRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=K123x2bQmJmrolFQ0Jj29G9Kdl3IdMgDQES8ggPyqxA=; b=mwziTnauI/FHBZW2PzxPsrp4mh+y3U0HwRLHCkz0CbF6taxitNP+LkMCyURl22Kn6N kzK34rEGSmDkyrtgNHmqez10llqr/habnKCnN+oLPi/lluzHFBqDNrYKZsrhwFN7e+H2 dTmfBuU0qk4OOmCniGJjDrKh87aT7iin29nzZM3V9OIbdIU6dHN57UcMtPGR4VMxMng5 PLEYkiDVNc/HI9zFpStYCfTMYuflZQn8DYjJteiZT6n0ghOJP98YHfXo8fznWGKpslI9 dtfEyZe/yOQKd2LX6b3uqPT2Nuzf5OBEbNM9F9//hWfRAidKO/Ia+Fu6VTp8Eh5UxbVZ bi0w== X-Gm-Message-State: AGi0PuZXUn6Qi64y/RCf0YYonXrjPCz5ev9ygxHiizkXW9SMSjLNPtB7 FgEpFHkVQNEYBPiYdtQPb2ItsS3k X-Google-Smtp-Source: APiQypLVE2+T9cVk41DqqIB1XPAaqDa4/Mf1I5aXi18cOgUA4WzOtA36AaiNP2K+AaAaoGWALyFhQw== X-Received: by 2002:a19:4b90:: with SMTP id y138mr4421897lfa.39.1588394702639; Fri, 01 May 2020 21:45:02 -0700 (PDT) Received: from [1.0.0.7] ([178.155.6.12]) by smtp.gmail.com with ESMTPSA id t8sm3642949lfe.25.2020.05.01.21.45.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2020 21:45:01 -0700 (PDT) Subject: Re: BUG #16329: Valgrind detects an invalid read when building a gist index with buffering From: Alexander Lakhin To: pgsql-bugs@lists.postgresql.org References: <16329-7a6aa9b6fa1118a1@postgresql.org> Message-ID: <3dda6945-c147-5afc-7720-38ec6848dafa@gmail.com> Date: Sat, 2 May 2020 07:45:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 06.04.2020 09:00, Alexander Lakhin wrote: > 30.03.2020 00:00, PG Bug reporting form wrote: >>> Running the following query under valgrind: >>> create table gist_point_tbl(id int4, p point); >>> insert into gist_point_tbl (id, p) >>> select g, point(g*10+1, g*10+1) from generate_series(1, 30000) g; >>> create index gist_pointidx2 on gist_point_tbl using gist(p) with (buffering >>> = on, fillfactor=50); >>> >>> leads to a memory access error: >>> ==00:00:00:08.755 18585== Invalid read of size 2 >>> ==00:00:00:08.756 18585== at 0x1F94CA: gistBuildCallback >>> (gistbuild.c:495) > Please look at the patch that modifies the gist regression test to make > the issue visible and fixes it by avoiding access to the memory context > that can be reset in gistProcessEmptyingQueue(). Could you please let me know if the fix is incorrect (or not elaborated enough to be included in the upcoming releases) or this issue is false positive? Best regards, Alexander