#13 imageGetData returns block with a hole: SEGV

needs test case
closed-fixed
nobody
None
5
2008-03-16
2004-08-04
Anonymous
No

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
problem.

Discussion

  • Eric Kow

    Eric Kow - 2008-02-18

    Logged In: YES
    user_id=242465
    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
    user_id=1312539
    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
    user_id=242465
    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."

    http://www.wxwidgets.org/manuals/2.6.3/wx_wxstaticbox.html

    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
    user_id=242465
    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