fd/b261edd91cbcc066cc9caff7d8ee07a77d5bcf

   1 Return-Path: <aslatter@gmail.com>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id EB10A429E25\r
   6         for <notmuch@notmuchmail.org>; Sun, 28 Aug 2011 20:26:29 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.799\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13         FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id BUUknBmn1Byg for <notmuch@notmuchmail.org>;\r
  17         Sun, 28 Aug 2011 20:26:28 -0700 (PDT)\r
  18 Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com\r
  19         [209.85.216.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id D7847431FB6\r
  22         for <notmuch@notmuchmail.org>; Sun, 28 Aug 2011 20:26:27 -0700 (PDT)\r
  23 Received: by qwb7 with SMTP id 7so3430137qwb.26\r
  24         for <notmuch@notmuchmail.org>; Sun, 28 Aug 2011 20:26:25 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=mime-version:in-reply-to:references:from:date:message-id:subject:to\r
  27         :cc:content-type:content-transfer-encoding;\r
  28         bh=WWzbH3F9YJio0Ov56PCqcrMFBfPMJ5on0l3AjR3zDww=;\r
  29         b=DAOFRsb36QUF0EjkTjXfVv+uEnAinBc6O3p3eUhioCiRLfoaTJaD3OR8fTUlT/d+at\r
  30         oWvibttu8HsgKSp8bby15ScA2YeFBTIB1syxAqUIur4yKdv9s/koMTiIANeF5+O/mn7z\r
  31         pE8Q1fKTXOdxB0b+/CPpdD1cWts+EReqrI7vA=\r
  32 Received: by 10.229.25.68 with SMTP id y4mr5097349qcb.24.1314588385118; Sun,\r
  33         28 Aug 2011 20:26:25 -0700 (PDT)\r
  34 MIME-Version: 1.0\r
  35 Received: by 10.229.45.195 with HTTP; Sun, 28 Aug 2011 20:26:05 -0700 (PDT)\r
  36 In-Reply-To: <87pqjprzu2.fsf@gmail.com>\r
  37 References: <8739h1pbaq.fsf@gmail.com> <87pqjprzu2.fsf@gmail.com>\r
  38 From: Antoine Latter <aslatter@gmail.com>\r
  39 Date: Sun, 28 Aug 2011 22:26:05 -0500\r
  40 Message-ID:\r
  41  <CAKjSnQGPRu7nWbLiuLX4niUyRNNbziNwBsX1s3+WyYx+9aTpcw@mail.gmail.com>\r
  42 Subject: Re: Bug in GC's ordering of ForeignPtr finalization?\r
  43 To: Ben Gamari <bgamari.foss@gmail.com>\r
  44 Content-Type: text/plain; charset=UTF-8\r
  45 Content-Transfer-Encoding: quoted-printable\r
  46 X-Mailman-Approved-At: Thu, 08 Sep 2011 14:21:55 -0700\r
  47 Cc: Bart Massey <bart@cs.pdx.edu>, glasgow-haskell-users@haskell.org,\r
  48         notmuch@notmuchmail.org, haskell-cafe@haskell.org\r
  49 X-BeenThere: notmuch@notmuchmail.org\r
  50 X-Mailman-Version: 2.1.13\r
  51 Precedence: list\r
  52 List-Id: "Use and development of the notmuch mail system."\r
  53         <notmuch.notmuchmail.org>\r
  54 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  55         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  56 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  57 List-Post: <mailto:notmuch@notmuchmail.org>\r
  58 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  59 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  60         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  61 X-List-Received-Date: Mon, 29 Aug 2011 03:26:30 -0000\r
  62 \r
  63 On Sun, Aug 28, 2011 at 4:27 PM, Ben Gamari <bgamari.foss@gmail.com> wrote:\r
  64 > On Tue, 16 Aug 2011 12:32:13 -0400, Ben Gamari <bgamari.foss@gmail.com> w=\r
  65 rote:\r
  66 >> It seems that the notmuch-haskell bindings (version 0.2.2 built against\r
  67 >> notmuch from git master; passes notmuch-test) aren't dealing with memory\r
  68 >> management properly. In particular, the attached test code[1] causes\r
  69 >> talloc to abort. =C2=A0Unfortunately, while the issue is consistently\r
  70 >> reproducible, it only occurs with some queries (see source[1]). I have\r
  71 >> been unable to establish the exact criterion for failure.\r
  72 >>\r
  73 >> It seems that the crash is caused by an invalid access to a freed Query\r
  74 >> object while freeing a Messages object (see Valgrind trace[3]). I've\r
  75 >> taken a brief look at the bindings themselves but, being only minimally\r
  76 >> familiar with the FFI, there's nothing obviously wrong (the finalizers\r
  77 >> passed to newForeignPtr look sane). I was under the impression that\r
  78 >> talloc was reference counted, so the Query object shouldn't have been\r
  79 >> freed unless if there was still a Messages object holding a\r
  80 >> reference. Any idea what might have gone wrong here? =C2=A0Thanks!\r
  81 >>\r
  82 > After looking into this issue in a bit more depth, I'm even more\r
  83 > confused. In fact, I would not be surprised if I have stumbled into a\r
  84 > bug in the GC. It seems that the notmuch-haskell bindings follow the\r
  85 > example of the python bindings in that child objects keep references to\r
  86 > their parents to prevent the garbage collector from releasing the\r
  87 > parent, which would in turn cause talloc to free the child objects,\r
  88 > resulting in odd behavior when the child objects were next accessed. For\r
  89 > instance, the Query and Messages objects are defined as follows,\r
  90 >\r
  91 > =C2=A0 =C2=A0type MessagesPtr =3D ForeignPtr S__notmuch_messages\r
  92 > =C2=A0 =C2=A0type MessagePtr =3D ForeignPtr S__notmuch_message\r
  93 > =C2=A0 =C2=A0newtype Query =3D Query (ForeignPtr S__notmuch_query)\r
  94 > =C2=A0 =C2=A0data MessagesRef =3D QueryMessages { qmpp :: Query, msp :: M=\r
  95 essagesPtr }\r
  96 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | T=\r
  97 hreadMessages { tmpp :: Thread, msp :: MessagesPtr }\r
  98 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | M=\r
  99 essageMessages { mmspp :: Message, msp :: MessagesPtr }\r
 100 > =C2=A0 =C2=A0data Message =3D MessagesMessage { msmpp :: MessagesRef, mp =\r
 101 :: MessagePtr }\r
 102 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Message { mp ::=\r
 103  MessagePtr }\r
 104 > =C2=A0 =C2=A0type Messages =3D [Message]\r
 105 >\r
 106 \r
 107 One problem you might be running in to is that the optimization passes\r
 108 can notice that a function isn't using all of its arguments, and then\r
 109 it won't pass them. These even applies if the arguments are bound\r
 110 together in a record type.\r
 111 \r
 112 So if you have a record type:\r
 113 \r
 114 > data QueryResult =3D QR {qrQueryPtr :: ForeignPtr (), qrResultPointer :: =\r
 115 Ptr ()}\r
 116 \r
 117 and a function:\r
 118 \r
 119 > processQueryResult :: QueryResult -> IO (...)\r
 120 \r
 121 If the function doesn't use the 'qrQueryPointer' part of the record,\r
 122 the compiler may not even pass it in. This might run the finalizer for\r
 123 the foreign pointer earlier than you expect. If the result pointer is\r
 124 a part of the query foreign pointer, you're in trouble.\r
 125 \r
 126 I'm not sure if this is what's happening, but it sounds like it could be.\r
 127 \r
 128 If this is the case you might want to build some helper functions\r
 129 using the function 'touchForeignPtr', which does nothing other than\r
 130 make it look like the foreign pointer is still in use. In my example\r
 131 it might be something like:\r
 132 \r
 133 > withQueryResultPtr :: QueryResult -> (Ptr QueryResult -> IO a) -> IO a\r
 134 > withQueryResultPtr qr k =3D do\r
 135 >    x <- k (qrQueryPtr qr)\r
 136 >    touchForeignPtr (qrResultPointer qr)\r
 137 >    return x\r
 138 \r
 139 Antoine\r