From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3154 invoked by alias); 16 Feb 2017 12:52:32 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 40554 Received: (qmail 17279 invoked from network); 16 Feb 2017 12:52:32 -0000 X-Qmail-Scanner-Diagnostics: from mailout1.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(210.118.77.11):SA:0(-5.0/5.0):. Processed in 2.909589 secs); 16 Feb 2017 12:52:32 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f1-f793f6d000007796-0f-58a5a083c388 Date: Thu, 16 Feb 2017 12:52:15 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: [PATCH] db/gdbm rewrite Message-id: <20170216125215.1b744bf6@pwslap01u.europe.root.pri> In-reply-to: <1487245575.1843244.882932424.59844A89@webmail.messagingengine.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsWy7djP87otC5ZGGMwOtTjY/JDJgdFj1cEP TAGMUVw2Kak5mWWpRfp2CVwZu79/ZS04Klhxu3UyewPjQ94uRg4OCQETiWPnlLsYOYFMMYkL 99azdTFycQgJLGWUOHmjlQXC6WWSaD6zjhGiykTi1/qNUIlljBIPFjUzQTjTmCSuzPoJ1X+G UWLzi01QzllGiYZ5h1lA+lkEVCX+Nf8Bm8UmYCgxddNsMFtEQFzi7NrzYDXCAioSTd96mEBs XgF7iSOPL7CB2JwCARKNx5+D2fwC+hJX/35igrjJXmLmlTOMEPWCEj8m3wObwyygKbF193p2 CFtb4sm7C6wgB0kINLNLdJybzwQJAVmJTQeYIea4SGzb8pAVwhaWeHV8CzuELSNxeXI3C4Td zyjxpNsXYs4MRonTZ3awQSSsJfpuX2SEWMYnMWnbdGaI+bwSHW1CECUeEk/v3YG62VFiT8N0 9gmMirOQnD0LydmzkJy9gJF5FaNIamlxbnpqsZFecWJucWleul5yfu4mRmAaOP3v+McdjO9P WB1iFOBgVOLhdchYEiHEmlhWXJl7iFGCg1lJhNdz/tIIId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rx7FlwJFxJITyxJzU5NLUgtgskycXBKNTDucPac2LfV+fEBntj5BXxqaq8j7/6v+XhIp0rh 4O4TH0KzDjOb/FEL3b36cs/J3HvJV5c3zP7BLV3nunvrvasbSh4u+JOQ2tP6yy1lupXg69wD uybxsi79rXCupe1uW0S9zAd3QZlJH3evCbx2S21uzdPzuUtu9W2V5M69GP3//DLZMJm5jgLq SizFGYmGWsxFxYkABUHTyv8CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsVy+t/xa7rtC5ZGGHTsErI42PyQyYHRY9XB D0wBjFFuNhmpiSmpRQqpecn5KZl56bZKoSFuuhZKCnmJuam2ShG6viFBSgpliTmlQJ6RARpw cA5wD1bSt0twy9j9/StrwVHBitutk9kbGB/ydjFyckgImEj8Wr+RBcIWk7hwbz1bFyMXh5DA EkaJG9+6mSCcGUwS57fehsqcY5Q41D+DHaRFSOAso8SUewEgNouAqsS/5j+MIDabgKHE1E2z wWwRAXGJs2vPg60QFlCRaPrWwwRi8wrYSxx5fIENxOYUCJBoPP4casFjJolT92ewgiT4BfQl rv79xARxn73EzCtnGCGaBSV+TL4HNpRZQF1i0rxFzBC2tsSTdxdYIY5Tl7hxdzf7BEbhWUha ZiFpmYWkZQEj8ypGkdTS4tz03GIjveLE3OLSvHS95PzcTYzAONp27OeWHYxd74IPMQpwMCrx 8DpkLIkQYk0sK67MPcQowcGsJMLrOX9phBBvSmJlVWpRfnxRaU5q8SFGU2DITGSWEk3OB8Z4 Xkm8oYmhuaWhkbGFhbmRkZI479QPV8KFBNITS1KzU1MLUotg+pg4OKUaGA3uhhmelu79l/v6 //+rInIZU5dX9cnebmnQE2vVP+ktYh35oWe2zAz75dvCn5roBK9bL6z2vb04fP0ed4l4hryd pZs9Q3Ual5pvvvxzz4x9XxeqmrbcKT29MfzuOf+77W/WP9y/2MT+0/bwH7W79kR/PeXhNc2b Y3fB8xlBK5UZzYVCTzmvNFJiKc5INNRiLipOBACDPnFOuQIAAA== X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170216125219eucas1p17a27d6101b5578e90f0d0c18ada00353 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1ByaW5jaXBhbCBFbmdpbmVlciwgU29mdHdhcmU=?= X-Global-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUbU2Ft?= =?UTF-8?B?c3VuZyBFbGVjdHJvbmljcxtQcmluY2lwYWwgRW5naW5lZXIsIFNvZnR3YXJl?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDA1Q0QwNTAwNTg=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20170215102727epcas1p4e08c26a6f0e39459b496db85e37df63f X-RootMTR: 20170215102727epcas1p4e08c26a6f0e39459b496db85e37df63f References: <1487074831.317363.880495280.04595B08@webmail.messagingengine.com> <1487154163.615323.881647656.040AB25F@webmail.messagingengine.com> <20170216101658.46555c47@pwslap01u.europe.root.pri> <1487245575.1843244.882932424.59844A89@webmail.messagingengine.com> On Thu, 16 Feb 2017 03:46:15 -0800 Sebastian Gniazdowski wrote: > =E2=80=93 The parameter "testkey" in the hash should be empty as it is it= s first > use. It comes from getgdbmnode(): > val_pm =3D (Param) zshcalloc( sizeof (*val_pm) ); > val_pm->node.flags =3D PM_SCALAR | PM_HASHELEM; /* no PM_UPTODATE > */ > val_pm->gsu.s =3D (GsuScalar) ht->tmpdata; > ht->addnode( ht, ztrdup( name ), val_pm ); // sets pm->node.nam >=20 > =E2=80=93 zshcalloc() should result in "pm->u.str" to be set to NULL >=20 > =E2=80=93=C2=A0so the "first zsfree() in gdbmsetfn()" should not run: > if (pm->u.str) { > zsfree(pm->u.str); > ... The parameter in question at the point of the error contains $1 =3D {node =3D {next =3D 0x0, nam =3D 0x8d7d9c8 "testkey", flags =3D 5373= 95200}, u =3D {data =3D 0x8d7d8b8, arr =3D 0x8d7d8b8, str =3D 0x8d7d8b8 "te= stdata", val =3D 148363448, valptr =3D 0x8d7d8b8, dval =3D 7.33012827553541= 98e-316, hash =3D 0x8d7d8b8}, gsu =3D {s =3D 0x8dfb540, i =3D 0x8dfb540, f = =3D 0x8dfb540, a =3D 0x8dfb540, h =3D 0x8dfb540}, base =3D 0, width =3D 0, = env =3D 0x0, ename =3D 0x0, old =3D 0x0, level =3D 0} I'm guessing this must be a node within the hash, not the hash itself. I think this is because the file already exists... Yep, I only get the error the second time I run the code, so my information was incomplete. The original allocation will have been at whatever point the internal hash entries were set up. So you need to check what length that was (should be 9 for zsfree() to work on "testdata"). In non-zsh malloc, zsfree() simply dispatches to free() and doesn't care about the size of the string. However, replacing all the zsfree()s with free gave me an infinite loop on a free. This was at free(umkey) inside the braces (the first of the two) in gdbmgetfn(). So the internal calculation of what needs freeing is definitely getting confused by something that's going on. I won't have a lot of time to look at this myself. Evidence the same effect doesn't happen with a different allocator isn't useful with memory errors, which are very sensitive to internal layout. pws