Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jImXP-0004g1-Nu for pgsql-bugs@arkaria.postgresql.org; Mon, 30 Mar 2020 05:00:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jImWt-00014f-1f for pgsql-bugs@arkaria.postgresql.org; Mon, 30 Mar 2020 05:00:07 +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 1jImWs-00014Y-PG for pgsql-bugs@lists.postgresql.org; Mon, 30 Mar 2020 05:00:06 +0000 Received: from mail-lf1-x144.google.com ([2a00:1450:4864:20::144]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jImWp-0001fa-RR for pgsql-bugs@lists.postgresql.org; Mon, 30 Mar 2020 05:00:06 +0000 Received: by mail-lf1-x144.google.com with SMTP id t16so12177777lfl.2 for ; Sun, 29 Mar 2020 22:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=6E2cnN+WxZGAfzdzckJtPRCWDPf6yhe7NhtTbv7qBww=; b=nwuSwhcHLq62DKzvIPiyXHzIk9v3mXpC4mTs+9MxI2BggnY62TpaRrg/x4CBmX8eBW j9PoCvmkjFTc9vTGJgOLXWq8CWZqOKSqnED9sqIH/mhVarROBCs9QJbYOD9CaVYe/FBH PtPVBW7vQFb08PDkFvWPPcIO2AayLn5+V1f4aWUXqkQ3O1bdKc+UlGvsGrOcFumeknwD yULL2uNKM5nkoQhIVjwwAtjiR9BO+W5x9ZUvDKKfP+qNeT+T/K9Yk4WdI2+HM3wA0UQ6 j3V53VEMpor8byTBdITBxZNb9X8CU/5uuGn+SBpRsci1qJhUUou7SHIxyfhM2xlck3QH w10A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6E2cnN+WxZGAfzdzckJtPRCWDPf6yhe7NhtTbv7qBww=; b=ktoa9Bqo/geIuNwYAZeirNiFwH1GxbB8M1IOxjBtWo2T980KUSq8WKag82+sud4dQv b2O8c4dv7I6YCJZPZMSHIn4gV8DRwMXnMkBSCPMSlnZnQxoMc7YHNUQwxXqIVP8UxV1a ua0LpS8TrCJR3rNquVjGN0CGtvEJ1BYCoHVHzBi7y0B1lvFH8FpOAfZV+KGHqOMFyv4X jrBxIvgO4tYITvNgsqmVsIIlgQRKbCYd2ZeW5EgxpeI9tyyugaAl/xPHH4IB261VK/rt Z7aPRx13RpH5EnDDyc0RvEf0lAYbxCAqNd6hmF3K/7q/ye8gn9ISGNlTeyvd/jkBLXgW YZlw== X-Gm-Message-State: AGi0PuYWROvKz4N6rnYXoDHF9z1UTDqB9edNlnhJpvw3q9zW7PaFnysN M64+w5/S4mf+HeJ9tdNtF65I6p1N X-Google-Smtp-Source: APiQypLHaDIcwBxmYoBe1l+TrHOCKCUBEUm8UJR1mNdlXC4omBZru4wm950kEd6NF4+SkHp48q25yA== X-Received: by 2002:a19:4a50:: with SMTP id x77mr6882864lfa.159.1585544402047; Sun, 29 Mar 2020 22:00:02 -0700 (PDT) Received: from [1.0.0.7] ([178.155.4.66]) by smtp.gmail.com with ESMTPSA id k3sm6324097lji.43.2020.03.29.22.00.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Mar 2020 22:00:01 -0700 (PDT) Subject: Re: BUG #16329: Valgrind detects an invalid read when building a gist index with buffering To: pgsql-bugs@lists.postgresql.org References: <16329-7a6aa9b6fa1118a1@postgresql.org> From: Alexander Lakhin Message-ID: Date: Mon, 30 Mar 2020 08:00:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <16329-7a6aa9b6fa1118a1@postgresql.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 30.03.2020 00:00, PG Bug reporting form wrote: > The following bug has been logged on the website: > > Bug reference: 16329 > Logged by: Alexander Lakhin > Email address: exclusion@gmail.com > PostgreSQL version: 12.2 > Operating system: Ubuntu 18.04 > Description: > > 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) I've found that the memory context where the itup is created:     oldCtx = MemoryContextSwitchTo(buildstate->giststate->tempCxt);     /* form an index tuple and point it at the heap tuple */     itup = gistFormTuple(buildstate->giststate, index, values, isnull, true); can be reset in gistBufferingBuildInsert->gistProcessEmptyingQueue:             /* Free all the memory allocated during index tuple processing */             MemoryContextReset(buildstate->giststate->tempCxt); Probably, the offending commit is d22a09dc.