#13 imageGetData returns block with a hole: SEGV

needs test case

The following function generates a Segmentation
violation after printing byte 19300. It looks like
imageGetData is returning a pointer to a memory block
with a hole in it.

> pixelLayers im width height =
> do
> putStrLn "About to get image data"
> rawPtr <- imageGetData im
> putStrLn ("Got pointer. About to peek
array at " ++ show rawPtr)
> sequence_ $ map (\i -> do
> (byte :: Word8) <- peekByteOff rawPtr i
> putStrLn ("Byte " ++ show i ++ " = "
++ show byte))
> [0,100 .. (width * height * 3 - 1)]
> (byteN :: Word8) <- peekByteOff rawPtr
(width * height * 3 - 1)
> putStrLn ("Last byte is " ++ (show byteN))
> (pixels :: [Word8]) <-
> return $ unsafeLazyPeekArray (5000)
(castPtr rawPtr)
> putStrLn "Got image data."
> putStrLn ("First bytes are " ++ (show $
take 5000 pixels))
> return (teeList 3 pixels)

Compiled with:

ghc -fglasgow-exts -package wx -O -fvia-C
-keep-hc-files --make -o image

Environment: wxHaskell 0.8, WX 2.4.2, GHC 6.2.1, Fedora
Core 2.

My email address is paul at cogito dot org dot uk.
Please email me if you want more information about this


  • Eric Kow

    Eric Kow - 2008-02-18

    Logged In: YES
    Originator: NO

    Sent Paul an email asking for him to submit this as a test case.

  • Eric Kow

    Eric Kow - 2008-02-18
    • milestone: --> needs test case
    • status: open --> pending
  • SourceForge Robot

    Logged In: YES
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

  • SourceForge Robot

    • status: pending --> closed
  • Eric Kow

    Eric Kow - 2008-03-13
    • status: closed --> open
  • Eric Kow

    Eric Kow - 2008-03-16

    Logged In: YES
    Originator: NO

    Well, I'm unable to run your demonstrator (unsafeLazyPeekArray? teeList?), but I have a good reason to believe that this is fixed by this patch, now in the darcs repository and soon to appear in 0.10.3rc2

    Sat Mar 15 22:57:22 GMT 2008 Eric Kow <eric.kow@gmail.com>
    * Push wxStaticBox generated by boxed combinator to bottom (fixes bug 1549363).

    The wxWidgets documentation says:
    "[T]he order in which you create new controls is important. Create your
    wxStaticBox control before any siblings that are to appear inside the
    wxStaticBox in order to preserve the correct Z-Order of controls."


    Basically, the wxStaticBox created by 'boxed' was covering up the widgets
    it was supposed to contain.

  • Eric Kow

    Eric Kow - 2008-03-16
    • status: open --> closed-fixed
  • Eric Kow

    Eric Kow - 2008-03-16

    Logged In: YES
    Originator: NO

    Err, hang on, wrong patch

    Sat Mar 15 15:13:39 GMT 2008 Eric Kow <eric.kow@gmail.com>
    * Add withImageData and withPixelBuffer (fixes bug 1003006).

    Quoting Jules Bean, whose solution I implemented:

    > 1 image <- imageCreateSized (WX.Size 256 256)
    > 2 pixels <- imageGetData image
    > 3 bytes <- peekArray (256*256*3) (castPtr pixels)
    > After line 2 is executed, there is no remaining reference to 'image' in
    > the program. 'image' is dead, and can be garbage collected. (Although it
    > may not be at any particular time). If 'image' gets GC'ed, because there
    > is a ForeignPtr inside, that calls the C++ destructor. The wxImage C++
    > destructor believes it owns the data block, so it free()s it, and
    > 'pixels' is left pointing to a free()ed block.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks