purebred-mua / hs-notmuch

Modern Haskell binding to the Notmuch mail indexer
11 stars 2 forks source link

Fix segfaults #25

Closed frasertweedale closed 6 years ago

frasertweedale commented 6 years ago
f27ba3a (Fraser Tweedale, 50 minutes ago)
   Fix segfaults when iterating thread-derived messages

   Some iterators reach back into their parent(s), meaning that the parent
   cannot be safely destroyed before the children are, even if the child
   pointers are detached.  Examples include (non-exhaustive):

   - iterating threads (and/or thread tags) requires the query
   - iterating thread-derived messages requires the thread
   - iterating message replies requires the message *and* the thread

   To ensure the parents are kept alive we need to reference their
   ForeignPtr(s) in the children.  Change 'Message' and 'Thread' accordingly
   and update threadsToList/messagesToList to receive the parent pointer(s)
   with which to endow the objects produced by the interator.

   Performance appears to be largely unchanged. For example,
   hs-notmuch-tag-count with 161474 messages is now:

        426,484,136 bytes allocated in the heap
       172,065,680 bytes copied during GC
        42,854,568 bytes maximum residency (8 sample(s))
           378,608 bytes maximum slop
                72 MB total memory in use (0 MB lost due to fragmentation)

     total time  =        7.66 secs   (7661 ticks @ 1000 us, 1 processor)
    total alloc = 260,249,536 bytes  (excludes profiling overheads)

   whereas at the previous commit:

        418,734,288 bytes allocated in the heap
       169,549,048 bytes copied during GC
        40,965,384 bytes maximum residency (8 sample(s))
           385,384 bytes maximum slop
                69 MB total memory in use (0 MB lost due to fragmentation)

     total time  =        7.49 secs   (7486 ticks @ 1000 us, 1 processor)
    total alloc = 257,666,520 bytes  (excludes profiling overheads)

   There is a small increase in time and allocation rate, and a small decrease
   in maximum residency.

06d03dd (Fraser Tweedale, 2 days ago)
   abstract constructF over the pointer type

   Make the type of constructF more general so it can work on types other than
   'ForeignPtr a'.  This involves pushing the construction of the ForeignPtr
   back out to the call site.  This is appropriate because we will soon change
   some of those to be plain pointers.
frasertweedale commented 6 years ago

haw, had a feeling that might happen. will update PR with fix for notmuch-0.24 later.