August 2011 - Haskell-Cafe

[CUFP 2011] Birds of a Feather sessions
by Ashish Agarwal 30 Aug '11

30 Aug '11

========================================================= Birds of a Feather sessions (BOFs) Commercial Users of Functional Programming Workshop (CUFP 2011) http://cufp.org/bofs-2011 Tokyo, Japan, September 22 - 23 ========================================================= Following last year's success, CUFP 2011 will again include Birds of a Feather sessions. BoFs provide a place for our community to gather informally at CUFP and reach consensus on matters of importance. Any CUFP attendee can propose a BoF session, and grab one of the spare rooms to hold a discussion. Attendance in the evening is open to all. BoF sessions facilitate ad-hoc discussions and provide a place to gather and start off the chat, before moving on during the evening to a local restaurant or pub. There is no deadline for proposing a session, but we encourage you to do so at the earliest possible time to help us with planning and to publicize your proposed discussion. Attendees are also free to show up even if you have not confirmed, but again earlier confirmation will help us with planning. Please see http://cufp.org/bofs-2011 for details on how to propose a BoF session or confirm attendance at one of them. Scheduled BoFs will be listed here as they are confirmed. General information on CUFP 2011 can be found at http://cufp.org/conference/2011. The conference is co-located with ICFP. You can register for CUFP at the main ICFP website http://www.icfpconference.org/icfp2011.

1 0

Re: [Haskell-cafe] Decompressing and http-enumerator
by Herbert Valerio Riedel 30 Aug '11

30 Aug '11

On Mon, 2011-08-29 at 16:50 +0100, Colin Adams wrote: > On 29 August 2011 16:45, Michael Snoyman <michael(a)snoyman.com> wrote: > "chunked" is the only valid transfer-encoding[1], while gzip > must be > specified on the content-encoding header[2]. For a simple > example of > these two, look at the response headers from Haskellers[3] in > something like Chrome developer tools. > > [1] > http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6 > [2] > http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5 > [3] http://www.haskellers.com/ > > Well [1] contradicts your claim: > > "The Internet Assigned Numbers Authority (IANA) acts as a registry for > transfer-coding value tokens. Initially, the registry contains the > following tokens: "chunked" (section 3.6.1), "identity" (section > 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and > "deflate" (section 3.5). " This added paragraph was actually one of the major changes between RFC2068 and RFC2616, in order to enhance the "Transfer-Encoding" field to become "full-fledged" as the "Content-Encoding" field was, as the previous definitions were deemed to have "significant problems".[1] So, using 'Content-Encoding: gzip' was required before RFC2616... but w/ RFC2616 'Transfer-Encoding: gzip, chunked' becomes possible too... It's also been a long standing bug/deficiency in Firefox[2]. So, RFC2616 differentiates between the 'entity' (= the actual information content, mostly end-to-end) and the 'message' (= transfer "wire format", mostly hop-by-hop). The content-* headers pertain to the 'entity', whereas the transfer-* headers describe the 'message' format. But I have to admit, that we have an unfortunate situation here, where the real-world implementations of RFC2616 don't follow the intent of the RFC (or alternatively: they implement the obsolete RFC2068). And I'm well aware that a 100% compliant RFC2616 implementation most likely will cause a lot of trouble in terms of interoperability... maybe the HTTPbis[3] effort will improve on the situation... Long story short: HTTP client libraries should be flexible enough to let the client-code decide whether transparent decoding of the specified Content-Encoding is desired or not. [1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.6.3 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=68517 [3]: http://tools.ietf.org/wg/httpbis/

1 0

GHC API question
by Chris Smith 30 Aug '11

30 Aug '11

I'm using the GHC API in GHC 7.2, and running into some problems. For background, I have working code that uses compileExpr to get a value from a dynamically loaded module. However, I'd like to do some profiling, and it appears that compileExpr doesn't work from executables that are built with profiling. So instead, I tried to take a more circuitous route... I'm using getModuleInfo and modInfoTyThings to get a list of all the declarations in the module, and finding the one I want, which I call var. This all works fine, and I can print the type and the name, and I know I have the right thing and it's got the correct type. But then I do: session <- getSession v <- liftIO $ getHValue session var return (unsafeCoerce# v) and I get a segfault when I try to access the resulting value. Keep in mind that this is the same value that works fine when I access it with compileExpr on an expression I've constructed to retrieve it. Any ideas what's going on? Am I missing a step? -- Chris Smith

4 6

Unexpected Typeable behaviour; Prelude.undefined
by Philip Holzenspies 30 Aug '11

30 Aug '11

L.S., I'm currently writing code where I want some ADTs to be parametric with a monad. There are some extra conditions that I place on my parameter, but I've boiled things down to minimal reproducibility. When I define MyADT as follows: import Data.Typeable data MyADT m = MyADT (m ()) instance (Typeable1 m, Monad m) => Typeable (MyADT m) where typeOf t@(MyADT _) = mkTyCon "MyADT" `mkTyConApp` [typeOf1 ((return :: Monad m => MyADT m -> m (MyADT m)) t)] it compiles fine and GHCi works as expected on a single instance of MyADT: *Main> typeOf (MyADT (return () :: IO ())) MyADT IO However, as soon as I place my data type in a structure of sorts, things break down: *Main> typeOf [(MyADT (return () :: IO ()))] *** Exception: Prelude.undefined *Main> typeOf (Just (MyADT (return () :: IO ()))) *** Exception: Prelude.undefined *Main> typeOf ((return :: a -> IO a) (MyADT (return () :: IO ()))) *** Exception: Prelude.undefined But if I stick a number in a similar structure, typeOf works just fine: *Main> typeOf ((return :: a -> IO a) 5) IO Integer I don't quite understand where the undefined comes from. I'm certainly not using it anywhere (as shown by the minimal reproduction above). Weirder still, when I *do* introduce a nice error, that too does not come up, viz. import Data.Typeable data MyADT m = MyADT (m ()) instance (Typeable1 m, Monad m) => Typeable (MyADT m) where typeOf t@(MyADT _) = error "foobar" with GHCi-session: *Main> typeOf (MyADT (return () :: IO ())) *** Exception: foobar *Main> typeOf ((return :: a -> IO a) (MyADT (return () :: IO ()))) *** Exception: Prelude.undefined *Main> typeOf $ Just (MyADT (return () :: IO ())) *** Exception: Prelude.undefined *Main> typeOf $ Just 42 Maybe Integer FYI, I'm using GHC 7.0.3, as installed with the Haskell Platform 2011.2.0.1. Am I overlooking something? Any help would be appreciated. Regards, Philip

4 4

Decompressing and http-enumerator
by Michael Snoyman 30 Aug '11

30 Aug '11

Hi all, Erik just opened an issue on Github[1] that affected me very recently as well when writing some automated Hackage checking code[2]. The issue is that http-enumerator sees the content-encoding header and decompresses the tarball, returning an uncompressed tarfile. I can avoid this with rawBody = False, but that's not a real solution, since that also disables chunked response handling. So one possible solution is to just add an option to never decompress response bodies, but that's a bit of a hack. The real question is: what's the correct way to handle these tarballs? Web browsers seem to know not to decompress them, but AFAICT http-enumerator is correctly following the spec by decompressing. Another possibility is to determine whether or not to decompress based on the content type, using either a white or black list (e.g., never compress TAR files, always decompress HTML files, etc). I'm open to suggestions here. Michael [1] https://github.com/snoyberg/http-enumerator/issues/30 [2] https://github.com/yesodweb/maintenance/blob/master/release/sdist-check.hs

6 11

Re: [Haskell-cafe] [xmonad] Cabal install problem
by Brent Yorgey 29 Aug '11

29 Aug '11

On Tue, Aug 30, 2011 at 12:30:08AM +0300, Tayfur Yilmaz wrote: > > > > > > Quoting Tayfur Yilmaz <yilmaz.tayfur(a)gmail.com>: > > > > > > >Hi everyone > > > >I have some problem for install 'cabal-install package' I downloaded > > and > > > >succesfully build a binary source ghc-7.0.2. Then I want to install > > > >cabal-0.10.2 and ? see some warning and last output like this > > > >Linking Setup ... > > > >Configuring Cabal-1.10.1.0... > > > >Setup: At least the following dependencies are missing: > > > >base >=4 && <3 && >=2 && <5, unix >=2.0 && <2.5 > > > > > > > >Error during cabal-install bootstrap: > > > >Configuring the Cabal package failed > > > > > > > >Then ? want to use cabal-0.8 and output like this > > > >Linking Setup ... > > > >Configuring Cabal-1.8.0.2... > > > >Setup: At least the following dependencies are missing: > > > >base >=4 && <3 && >=1 && <5, > > > >filepath >=1 && <1.2, > > > >unix >=2.1 && <2.5 > > > > > > > >Error during cabal-install bootstrap: > > > >Configuring the Cabal package failed > > > > > > > >So Which compatible versiyon for cabal-install version I use Kde4 on > > > >Pardus<http://www.pardus.org.tr/> > > > > > > > >Best Regards > > Can someone describe install packages sort list.. > I read some document and > 1.Firstly ı download a binary version of Ghc (version 7.0.2) > (bootstrap.py) bootstrap.py? There should not be any python scripts involved in installing a binary version of GHC. Where did you download it from? After installing it, does it work? If you type ghci at a command prompt, what happens? -Brent > 2. cabal-install package download and install bu I send this bug > > And now I want to build hackage platform > > Command > $ sudo ./configure > Output > ************************************************** > * > * Haskell Platform Source Installer > * > * For the Haskell Platform 2011.2.0.1 and GHC 7.0.3 > * > ************************************************** > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > *checking for ghc... notfound* > configure: error: > This installer for the Haskell Platform requires ghc to be installed first > * If ghc is installed not on the PATH then use --with-ghc= and > --with-ghc-pkg=* > Command > $ sudo ./configure --with-ghc= --with-ghc-pkg= > Output > ************************************************** > * > * Haskell Platform Source Installer > * > * For the Haskell Platform 2011.2.0.1 and GHC 7.0.3 > * > ************************************************** > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > *checking for hsc2hs... notfound* > configure: error: The hsc2hs program could not be found. > It is usually installed along with ghc. You may need to specify > --with-hsc2hs= > > Command > sudo ./configure --with-ghc= --with-ghc-pkg= --with-hsc2hs= > Output > ************************************************** > * > * Haskell Platform Source Installer > * > * For the Haskell Platform 2011.2.0.1 and GHC 7.0.3 > * > ************************************************** > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > checking version of ghc... > *configure: error: does not seem to work (or maybe it is not actually ghc). > * > > > I build ghc binary and why I can't solve this problems.

2 1

Trouble with Haddock
by anonymous 29 Aug '11

29 Aug '11

First time using haddock. I'm unable to include code examples in the module header. Haddock fails with this error: haddock module header parse failed: Cannot parse header documentation paragraphs It's about 12 lines of code, which doesn't seem like much compared to other packages. e.g. -- | describing module -- -- > code -- > ... -- > code module Foo ( .... I tried @...@ code blocks, but that didn't work either. If I shorten the code to 3 lines or so, it will work.

2 1

Re: [Haskell-cafe] Dynamic loading of module
by Arnaud Bailly 29 Aug '11

29 Aug '11

Hello Albert, Thanks for taking the time to help me fix this package stuff. So I wiped out my package.conf.d/ and tried to reinstall my stuff. Installing template-haskell 2.5.0.0 is ok (2.6 is not, fails to compile on ghc 7.0.3) but then: D:\projets\>ghc --make -package ghc main <command line>: cannot satisfy -package ghc (use -v for more information) I suspect I really *do* have to reinstall haskell-platform. Here is the output of ghc-pkg list -v: using cache: C:\Documents and Settings\abailly\Application Data\ghc\i386-mingw32-7.0.3\package.conf.d\package.cache using cache: D:/Program Files/Haskell Platform/2011.2.0.1\lib\package.conf.d\package.cache D:/Program Files/Haskell Platform/2011.2.0.1\lib\package.conf.d: Cabal-1.10.1.0 (Cabal-1.10.1.0-55f781465ee9f32289755ad706c71f0f) GLUT-2.1.2.1 (GLUT-2.1.2.1-2d30997b9a19d27be388572e75af52bf) HTTP-4000.1.1 (HTTP-4000.1.1-267a332938fa742ba5a5d59de0b46d60) HUnit-1.2.2.3 (HUnit-1.2.2.3-102fbfbd594cd6d38461f5c68d880996) OpenGL-2.2.3.0 (OpenGL-2.2.3.0-a58ce3ad6070e6b7932a3e779be57f75) Win32-2.2.0.1 (Win32-2.2.0.1-26cf39fdf591bdac61b11d5a443c62ab) array-0.3.0.2 (array-0.3.0.2-8e9cd0144e87fa9cc86cc9031631c4f3) base-4.3.1.0 (base-4.3.1.0-f520cd232cc386346843c4a12b63f44b) bin-package-db-0.0.0.0 (bin-package-db-0.0.0.0-97d865e5935b41538bcb29fc1040ae7d) bytestring-0.9.1.10 (bytestring-0.9.1.10-cd85f14e02463c02ba4c77d7adcdb54f) cgi-3001.1.7.4 (cgi-3001.1.7.4-659440ce11c2975fd9c9c471a1e8ff3b) containers-0.4.0.0 (containers-0.4.0.0-18deac99a132f04751d862b77aab136e) deepseq-1.1.0.2 (deepseq-1.1.0.2-09b3aed0c4982bbc6569c668100876fa) directory-1.1.0.0 (directory-1.1.0.0-3a2367d72569467a8af8a231656ff1b8) extensible-exceptions-0.1.1.2 (extensible-exceptions-0.1.1.2-d8c5b906654260efd7249f497d17a831) ffi-1.0 (builtin_ffi) fgl-5.4.2.3 (fgl-5.4.2.3-595811d6eabb1e1768685703ea66e982) filepath-1.2.0.0 (filepath-1.2.0.0-f132e9f7703da4e20a47ff2b9acf1ea1) (ghc-binary-0.5.0.2 (ghc-binary-0.5.0.2-aba2b5dca5546ea1a972188de48f87b5)) ghc-prim-0.2.0.0 (ghc-prim-0.2.0.0-e1f7c380581d61d42b0360d440cc35ed) haskell-src-1.0.1.4 (haskell-src-1.0.1.4-7428a8c9049cd6bf5abdc0bbd2d417c5) (haskell2010-1.0.0.0 (haskell2010-1.0.0.0-53d9cd65595c551eea0c0269f534b5e0)) haskell98-1.1.0.1 (haskell98-1.1.0.1-35ec26bae828637c1638c8be441b3d68) hpc-0.5.0.6 (hpc-0.5.0.6-481dbb43fb624c21ad3bb9434675e3ac) html-1.0.1.2 (html-1.0.1.2-a494249f98a0f38b1a8db28bc70f8b0b) integer-gmp-0.2.0.3 (integer-gmp-0.2.0.3-91607778cf3ae8f3948a50062b4f8479) mtl-2.0.1.0 (mtl-2.0.1.0-fb4d1695269b74308c1517c06b76e6e8) network-2.3.0.2 (network-2.3.0.2-47657e39a6118a978d9f443d72e85d4a) old-locale-1.0.0.2 (old-locale-1.0.0.2-6e2a3c0744e8cf4e0ac2d4e58659f7b5) old-time-1.0.0.6 (old-time-1.0.0.6-445ce39cbcebd38069c25c0f383b728d) parallel-3.1.0.1 (parallel-3.1.0.1-6eaa564e1ef1537bc88ad1fea6c90fe2) parsec-3.1.1 (parsec-3.1.1-9da59b00c02e52f9f62f3c87c7e0e2ec) pretty-1.0.1.2 (pretty-1.0.1.2-abc7c632374e50e1c1927987c2651f0f) process-1.0.1.5 (process-1.0.1.5-b3dded8e54a2e13d22af410bdcfafff4) random-1.0.0.3 (random-1.0.0.3-1abde37180be5476311abeefe300abc2) regex-base-0.93.2 (regex-base-0.93.2-9e1b027c41dbec856469a30982495bb9) regex-compat-0.93.1 (regex-compat-0.93.1-31c61fe0aee45e8a9853edf7a844f74e) regex-posix-0.94.4 (regex-posix-0.94.4-f5eb628ea5dae5f91552d5ea0e26359d) rts-1.0 (builtin_rts) stm-2.2.0.1 (stm-2.2.0.1-57e291244ee02349552a4f79caeb4ffe) syb-0.3 (syb-0.3-8db7bc4339a1cb8a6f2a46c40447ef0b) text-0.11.0.6 (text-0.11.0.6-398a3f02891247aea46662fc7379c4a5) time-1.2.0.3 (time-1.2.0.3-74ef6ac31cee9aec02b036978af002d2) transformers-0.2.2.0 (transformers-0.2.2.0-2fe7b735c63a6cbe8724038d8e4d812a) xhtml-3000.2.0.1 (xhtml-3000.2.0.1-ace31b2e48c396e565655b0f34f5d2b7) zlib-0.5.3.1 (zlib-0.5.3.1-5fbdf714525b76e0e601c2ffb25f2044) C:\Documents and Settings\abailly\Application Data\ghc\i386-mingw32-7.0.3\package.conf.d: QuickCheck-2.4.1.1 (QuickCheck-2.4.1.1-04d68679694a517ba23022a4c6bc1cde) ghc-paths-0.1.0.8 (ghc-paths-0.1.0.8-be391faf057d651dbb92b73671fe9eee) template-haskell-2.5.0.0 (template-haskell-2.5.0.0-87f4f416a22a910e480ac9f269479a5f) utf8-string-0.3.7 (utf8-string-0.3.7-dcbcb8de655cdfe1c4c28c094f8c6799) Thanks again, Arnaud On Sat, Aug 27, 2011 at 8:59 PM, Albert Y. C. Lai <trebla(a)vex.net> wrote: > You have too many instances of template-haskell. The important parts are: > > > package ghc-7.0.3-**fc75cf67c86ba2c0d64b07024a18d3**b4 is unusable due to > missing or recursive dependencies: > template-haskell-2.5.0.0-**7d9b1443ac5ab69e5ed705a487990d**eb > > package template-haskell-2.5.0.0-**7d9b1443ac5ab69e5ed705a487990d**eb is > shadowed by package template-haskell-2.5.0.0-** > 87f4f416a22a910e480ac9f269479a**5f > > and in "ghc-pkg list -v": > > D:/Program Files/Haskell Platform/2011.2.0.1\lib\**package.conf.d: > > > template-haskell-2.5.0.0 (template-haskell-2.5.0.0-** > 7d9b1443ac5ab69e5ed705a487990d**eb) > > C:\Documents and Settings\abailly\Application Data\ghc\i386-mingw32-7.0.3\ > **package.conf.d: > > > template-haskell-2.5.0.0 (template-haskell-2.5.0.0-** > 87f4f416a22a910e480ac9f269479a**5f) > > I don't know how you got to this unsafe state. But my article explains > what's wrong with it. (Though my example has different version numbers on > top of different ABI hashes). > > The user instance of template-haskell (**87f4f416a22a910e480ac9f269479a**5f) > is getting into the way. Lose it by doing "ghc-pkg unregister --user > template-haskell" on it. Oh, it will complain about breaking other packages; > well, lose them too. > > (Or go one step further and lose all of C:\Documents and > Settings\abailly\Application Data\ghc\i386-mingw32-7.0.3\**package.conf.d > which means losing all user packages.) > > (Reinstalling haskell platform changes nothing, as long as some user > package gets into the way.) >

3 10

Problems creating Haskell-dll without -fvia-C
by KlasI 29 Aug '11

29 Aug '11

Hi! I recently read a haskell-cafe-thread telling me that the compiler option -fvia-C will be removed. This gets me a bit worried... I use -fvia-C when I build my haskell dll, and it works just fine (Haskell 2010.2.0.0): ghc -c Adder.hs -O2 -fvia-C ghc -c StartEnd.c ghc -shared -o Adder.dll Adder.o Adder_stub.o StartEnd.o Adder.def Next I create a lib which can be imported in Visual C++: lib /machine:i386 /def:SingThing.def BUT...if I remove the flag -fvia-C, the program crashes when I run it:( I've tried experimenting with a few things: * Haskell FFI's calling conventions ccall/stdcall * Skipping the .def file * Skipping "lib /machine:i386 /def:SingThing.def", instead trying the approach descibed in: http://blogs.msdn.com/b/satnam_singh/archive/2011/04/19/creating-a-windows-… Can anyone please give me a hint of whats going on? I guess it must be somthing with pointers and calling conventions, but I'm banging my head against the wall now:( Cheers Klas (Btw... I should mention that the simple Adder.hs example actually works without -fvia-C, my dll is more advanced, but I'm following the same compiling procedure) -- View this message in context: http://haskell.1045720.n5.nabble.com/Problems-creating-Haskell-dll-without-… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

1 0

Memory management issue in notmuch-haskell bindings
by Ben Gamari 29 Aug '11

29 Aug '11

It seems that the notmuch-haskell bindings (version 0.2.2 built against notmuch from git master; passes notmuch-test) aren't dealing with memory management properly. In particular, the attached test code[1] causes talloc to abort. Unfortunately, while the issue is consistently reproducible, it only occurs with some queries (see source[1]). I have been unable to establish the exact criterion for failure. It seems that the crash is caused by an invalid access to a freed Query object while freeing a Messages object (see Valgrind trace[3]). I've taken a brief look at the bindings themselves but, being only minimally familiar with the FFI, there's nothing obviously wrong (the finalizers passed to newForeignPtr look sane). I was under the impression that talloc was reference counted, so the Query object shouldn't have been freed unless if there was still a Messages object holding a reference. Any idea what might have gone wrong here? Thanks! Cheers, - Ben [1] Test case, import Data.List import Control.Monad import System.Environment import Foreign.Notmuch dbpath = "/home/ben/.mail" getAddresses :: Database -> String -> IO [String] getAddresses db q = do query <- queryCreate db q msgs <- queryMessages query addrs <- mapM (flip messageGetHeader $ "From") msgs return addrs main = do db <- databaseOpen dbpath DatabaseModeReadOnly --addrs2 <- getAddresses db "tag:haskell" -- This succeeds addrs3 <- getAddresses db "to:dietz" -- This fails --print addrs2 --print addrs3 databaseClose db [2] Crashed session and backtrace, [1217 ben@ben-laptop ~] $ ghc test.hs -auto-all -rtsopts -prof && gdb ./test GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/ben/test...(no debugging symbols found)...done. (gdb) run Starting program: /home/ben/test [Thread debugging using libthread_db enabled] Program received signal SIGABRT, Aborted. 0x00007ffff5979d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) bt #0 0x00007ffff5979d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff597dab6 in abort () at abort.c:92 #2 0x00007ffff6de038c in talloc_abort (reason=0x7ffff6de56e8 "Bad talloc magic value - access after free") at ../talloc.c:210 #3 0x00007ffff6de0271 in talloc_abort_access_after_free (ptr=0x769190, location=0x7ffff7bd4e04 "lib/messages.c:142") at ../talloc.c:229 #4 talloc_chunk_from_ptr (ptr=0x769190, location=0x7ffff7bd4e04 "lib/messages.c:142") at ../talloc.c:250 #5 _talloc_free (ptr=0x769190, location=0x7ffff7bd4e04 "lib/messages.c:142") at ../talloc.c:1164 #6 0x00007ffff7bc7e65 in notmuch_messages_destroy (messages=0x769190) at lib/messages.c:142 #7 0x00000000004de1c9 in scheduleFinalizers () #8 0x00000000004e013d in GarbageCollect () #9 0x00000000004d9e40 in scheduleDoGC.clone.18 () #10 0x00000000004db0e0 in exitScheduler () #11 0x00000000004d9066 in hs_exit_ () #12 0x00000000004d940a in shutdownHaskellAndExit () #13 0x00000000004d8a91 in real_main () #14 0x00000000004d8ade in hs_main () #15 0x00007ffff5964eff in __libc_start_main (main=0x408ed0 <main>, argc=1, ubp_av=0x7fffffffe4f8, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffffffe4e8) at libc-start.c:226 #16 0x0000000000407791 in _start () (gdb) [3] Valgrind output, ==25241== Memcheck, a memory error detector ==25241== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==25241== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==25241== Command: ./test ==25241== ==25241== Conditional jump or move depends on uninitialised value(s) ==25241== at 0x52BB510: inflateReset2 (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4) ==25241== by 0x52BB605: inflateInit2_ (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4) ==25241== by 0x5F211BE: ChertTable::lazy_alloc_inflate_zstream() const (chert_table.cc:1672) ==25241== by 0x5F23B06: ChertTable::read_tag(Cursor*, std::string*, bool) const (chert_table.cc:1264) ==25241== by 0x5F260F9: ChertTable::get_exact_entry(std::string const&, std::string&) const (chert_table.cc:1210) ==25241== by 0x5F26DE2: ChertTermList::ChertTermList(Xapian::Internal::RefCntPtr<ChertDatabase const>, unsigned int) (chert_termlist.cc:44) ==25241== by 0x5EFF2E5: ChertDatabase::open_term_list(unsigned int) const (chert_database.cc:891) ==25241== by 0x5E7E7FB: Xapian::Document::termlist_begin() const (omdocument.cc:176) ==25241== by 0x4E41822: _notmuch_message_ensure_metadata(_notmuch_message*) (message.cc:309) ==25241== by 0x4E429DC: _notmuch_message_ensure_filename_list(_notmuch_message*) (message.cc:632) ==25241== by 0x4E42C37: notmuch_message_get_filename (message.cc:698) ==25241== by 0x4E41CA7: _notmuch_message_ensure_message_file(_notmuch_message*) (message.cc:403) ==25241== ==25241== Invalid read of size 4 ==25241== at 0x5C25DED: _talloc_free (talloc.c:242) ==25241== by 0x4E39E64: notmuch_messages_destroy (messages.c:142) ==25241== by 0x4DE1C8: scheduleFinalizers (in /home/ben/test) ==25241== by 0x4E013C: GarbageCollect (in /home/ben/test) ==25241== by 0x4D9E3F: scheduleDoGC.clone.18 (in /home/ben/test) ==25241== by 0x4DB0DF: exitScheduler (in /home/ben/test) ==25241== by 0x4D9065: hs_exit_ (in /home/ben/test) ==25241== by 0x4D9409: shutdownHaskellAndExit (in /home/ben/test) ==25241== by 0x4D8A90: real_main (in /home/ben/test) ==25241== by 0x4D8ADD: hs_main (in /home/ben/test) ==25241== by 0x6F4FEFE: (below main) (libc-start.c:226) ==25241== Address 0x8324e90 is 64 bytes inside a block of size 136 free'd ==25241== at 0x4C282ED: free (vg_replace_malloc.c:366) ==25241== by 0x5C29884: _talloc_free_internal (talloc.c:714) ==25241== by 0x5C25F22: _talloc_free (talloc.c:667) ==25241== by 0x4E452BF: notmuch_query_destroy (query.cc:358) ==25241== by 0x4DE1C8: scheduleFinalizers (in /home/ben/test) ==25241== by 0x4E013C: GarbageCollect (in /home/ben/test) ==25241== by 0x4D9E3F: scheduleDoGC.clone.18 (in /home/ben/test) ==25241== by 0x4DB0DF: exitScheduler (in /home/ben/test) ==25241== by 0x4D9065: hs_exit_ (in /home/ben/test) ==25241== by 0x4D9409: shutdownHaskellAndExit (in /home/ben/test) ==25241== by 0x4D8A90: real_main (in /home/ben/test) ==25241== by 0x4D8ADD: hs_main (in /home/ben/test) ==25241== ==25241== Invalid read of size 8 ==25241== at 0x5C26251: _talloc_free (talloc.c:249) ==25241== by 0x4E39E64: notmuch_messages_destroy (messages.c:142) ==25241== by 0x4DE1C8: scheduleFinalizers (in /home/ben/test) ==25241== by 0x4E013C: GarbageCollect (in /home/ben/test) ==25241== by 0x4D9E3F: scheduleDoGC.clone.18 (in /home/ben/test) ==25241== by 0x4DB0DF: exitScheduler (in /home/ben/test) ==25241== by 0x4D9065: hs_exit_ (in /home/ben/test) ==25241== by 0x4D9409: shutdownHaskellAndExit (in /home/ben/test) ==25241== by 0x4D8A90: real_main (in /home/ben/test) ==25241== by 0x4D8ADD: hs_main (in /home/ben/test) ==25241== by 0x6F4FEFE: (below main) (libc-start.c:226) ==25241== Address 0x8324e80 is 48 bytes inside a block of size 136 free'd ==25241== at 0x4C282ED: free (vg_replace_malloc.c:366) ==25241== by 0x5C29884: _talloc_free_internal (talloc.c:714) ==25241== by 0x5C25F22: _talloc_free (talloc.c:667) ==25241== by 0x4E452BF: notmuch_query_destroy (query.cc:358) ==25241== by 0x4DE1C8: scheduleFinalizers (in /home/ben/test) ==25241== by 0x4E013C: GarbageCollect (in /home/ben/test) ==25241== by 0x4D9E3F: scheduleDoGC.clone.18 (in /home/ben/test) ==25241== by 0x4DB0DF: exitScheduler (in /home/ben/test) ==25241== by 0x4D9065: hs_exit_ (in /home/ben/test) ==25241== by 0x4D9409: shutdownHaskellAndExit (in /home/ben/test) ==25241== by 0x4D8A90: real_main (in /home/ben/test) ==25241== by 0x4D8ADD: hs_main (in /home/ben/test) ==25241== ==25241== ==25241== HEAP SUMMARY: ==25241== in use at exit: 192,328 bytes in 555 blocks ==25241== total heap usage: 19,852 allocs, 19,297 frees, 35,375,726 bytes allocated ==25241== ==25241== LEAK SUMMARY: ==25241== definitely lost: 0 bytes in 0 blocks ==25241== indirectly lost: 0 bytes in 0 blocks ==25241== possibly lost: 27,799 bytes in 292 blocks ==25241== still reachable: 164,529 bytes in 263 blocks ==25241== suppressed: 0 bytes in 0 blocks ==25241== Rerun with --leak-check=full to see details of leaked memory ==25241== ==25241== For counts of detected and suppressed errors, rerun with: -v ==25241== Use --track-origins=yes to see where uninitialised values come from ==25241== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 4 from 4)

2 4