The Glasgow Haskell Users Mailing List

Bas van Dijk | 17 Jun 2012 17:11

Segmentation fault/access violation in generated code

Hello,

I'm trying to solve #5254
(http://hackage.haskell.org/trac/ghc/ticket/5254). The issue can be
isolated to the following short program which only uses
bindings-libusb
(http://hackage.haskell.org/packages/archive/bindings-libusb/1.4.4.1/doc/html/Bindings-Libusb-InitializationDeinitialization.html):

--------------------------------------------------
module Main where

import Foreign
import qualified Foreign.Concurrent as FC
import Control.Concurrent
import Bindings.Libusb.InitializationDeinitialization

main :: IO ()
main = do
  ctxPtr <- alloca $ \ctxPtrPtr -> do
              _ <- c'libusb_init ctxPtrPtr
              peek ctxPtrPtr

  fp <- newForeignPtr p'libusb_exit ctxPtr
  -- fp <- FC.newForeignPtr ctxPtr $ c'libusb_exit ctxPtr

  threadDelay 3000000
  print $ fp == fp
--------------------------------------------------

When I run this program on Windows I get the following error after 3 seconds:

(Continue reading)

headers

Bas van Dijk | 20 Jun 2012 00:49

Re: Segmentation fault/access violation in generated code

I just tried building the following program with the new GHC
win64_alpha1 and apart from warnings from using the unsupported
stdcall calling convention running the program doesn't give a
segmentation fault as it does when building the program with
GHC-7.4.2:

{-# LANGUAGE ForeignFunctionInterface #-}

module Main where

import Foreign
import Foreign.C.Types

main :: IO ()
main = do
  ctxPtr <- alloca $ \ctxPtrPtr -> do
              _ <- c'libusb_init ctxPtrPtr
              peek ctxPtrPtr

  fp <- newForeignPtr p'libusb_exit ctxPtr

  threadDelay 1000000
  print $ fp == fp

data C'libusb_context = C'libusb_context

foreign import stdcall "libusb_init" c'libusb_init
  :: Ptr (Ptr C'libusb_context) -> IO CInt

foreign import stdcall "&libusb_exit" p'libusb_exit

(Continue reading)

headers

Ian Lynagh | 23 Jun 2012 02:40

Re: Segmentation fault/access violation in generated code


Hi Bas,

On Sun, Jun 17, 2012 at 05:11:35PM +0200, Bas van Dijk wrote:
> 
> module Main where
> 
> import Foreign
> import qualified Foreign.Concurrent as FC
> import Control.Concurrent
> import Bindings.Libusb.InitializationDeinitialization
> 
> main :: IO ()
> main = do
>   ctxPtr <- alloca $ \ctxPtrPtr -> do
>               _ <- c'libusb_init ctxPtrPtr
>               peek ctxPtrPtr
> 
>   fp <- newForeignPtr p'libusb_exit ctxPtr
>   -- fp <- FC.newForeignPtr ctxPtr $ c'libusb_exit ctxPtr
> 
>   threadDelay 3000000
>   print $ fp == fp

What happens if you just call
    c'libusb_exit ctxPtr
at the end, instead of using a finalizer?

Are you able to reproduce this with just a .c file that is compiled and
linked with the program, rather than needing libusb? That would make it

(Continue reading)

headers

Bas van Dijk | 24 Jun 2012 02:13

Re: Segmentation fault/access violation in generated code

On 23 June 2012 02:40, Ian Lynagh <igloo <at> earth.li> wrote:
>
> Hi Bas,
>
> On Sun, Jun 17, 2012 at 05:11:35PM +0200, Bas van Dijk wrote:
>>
>> module Main where
>>
>> import Foreign
>> import qualified Foreign.Concurrent as FC
>> import Control.Concurrent
>> import Bindings.Libusb.InitializationDeinitialization
>>
>> main :: IO ()
>> main = do
>>   ctxPtr <- alloca $ \ctxPtrPtr -> do
>>               _ <- c'libusb_init ctxPtrPtr
>>               peek ctxPtrPtr
>>
>>   fp <- newForeignPtr p'libusb_exit ctxPtr
>>   -- fp <- FC.newForeignPtr ctxPtr $ c'libusb_exit ctxPtr
>>
>>   threadDelay 3000000
>>   print $ fp == fp
>
> What happens if you just call
>    c'libusb_exit ctxPtr
> at the end, instead of using a finalizer?

Then I don't get an error. So executing the following program with the

(Continue reading)