While playing with this library (first time I use OpenCL), I got into an issue resulting in crashers (segmentation faults) when using CUChar/uint8. Here's what happens:
I try to run the first example (example01.hs), but altered it slightly to use 8-bit integers instead of floats, here's the diff:
--- example01.hs 2011-12-29 00:13:44.127347130 +0100
+++ example01bis.hs 2011-12-29 00:19:21.372373866 +0100
@@ -31,11 +31,11 @@
-}
import System.GPU.OpenCL
import Foreign( castPtr, nullPtr, sizeOf )
-import Foreign.C.Types( CFloat )
+import Foreign.C.Types( CUChar )
import Foreign.Marshal.Array( newArray, peekArray )
programSource :: String
-programSource = "__kernel void duparray(__global float *in, __global float *out ){\n int id = get_global_id(0);\n out[id] = 2*in[id];\n}"
+programSource = "__kernel void duparray(__global uint8 *in, __global uint8 *out ){\n int id = get_global_id(0);\n out[id] = 2*in[id];\n}"
main :: IO ()
main = do
@@ -51,8 +51,8 @@
kernel <- clCreateKernel program "duparray"
-- Initialize parameters
- let original = [0 .. 20] :: [CFloat]
- elemSize = sizeOf (0 :: CFloat)
+ let original = [0 .. 20] :: [CUChar]
+ elemSize = sizeOf (0 :: CUChar)
vecSize = elemSize * length original
putStrLn $ "Original array = " ++ show original
input <- newArray original
Running the float example works as expected:
[nicolas@tau mvmul]$ ghc --make -lOpenCL -fforce-recomp example01.hs
[1 of 1] Compiling Main ( example01.hs, example01.o )
Linking example01 ...
[nicolas@tau mvmul]$ ./example01
Original array = [0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0,16.0,17.0,18.0,19.0,20.0]
Result array = [0.0,2.0,4.0,6.0,8.0,10.0,12.0,14.0,16.0,18.0,20.0,22.0,24.0,26.0,28.0,30.0,32.0,34.0,36.0,38.0,40.0]
and doesn't fail, even upon repeated execution.
The altered version crashes:
[nicolas@tau mvmul]$ ghc --make -lOpenCL -fforce-recomp example01bis.hs
[1 of 1] Compiling Main ( example01bis.hs, example01bis.o )
Linking example01bis ...
[nicolas@tau mvmul]$ ./example01bis
Original array = [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20]
Result array = [0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40]
*** glibc detected *** ./example01bis: corrupted double-linked list: 0x0000000001ef6d10 ***
======= Backtrace: =========
/lib64/libc.so.6[0x314be7c2d6]
/lib64/libc.so.6[0x314be7c7a9]
/lib64/libc.so.6[0x314be7d3c9]
/home/nicolas/Projects/OpenCL/AMD-APP-SDK-v2.6-RC3-lnx64/lib/x86_64/libamdocl64.so(+0xdfa26d)[0x7fcde48e426d]
/home/nicolas/Projects/OpenCL/AMD-APP-SDK-v2.6-RC3-lnx64/lib/x86_64/libamdocl64.so(+0xdfb51e)[0x7fcde48e551e]
/home/nicolas/Projects/OpenCL/AMD-APP-SDK-v2.6-RC3-lnx64/lib/x86_64/libamdocl64.so(+0xe5d97d)[0x7fcde494797d]
/home/nicolas/Projects/OpenCL/AMD-APP-SDK-v2.6-RC3-lnx64/lib/x86_64/libamdocl64.so(+0xe5d9a5)[0x7fcde49479a5]
/home/nicolas/Projects/OpenCL/AMD-APP-SDK-v2.6-RC3-lnx64/lib/x86_64/libamdocl64.so(+0x1830b9)[0x7fcde3c6d0b9]
/lib64/libc.so.6[0x314be39931]
/lib64/libc.so.6[0x314be399b5]
./example01bis[0x4d21a8]
./example01bis[0x4d21cd]
./example01bis[0x4daab1]
./example01bis[0x4daafe]
/lib64/libc.so.6(__libc_start_main+0xed)[0x314be2169d]
./example01bis[0x406b45]
======= Memory map: ========
(snip)
Loading the coredump using gdb to retrieve symbol information gives:
#0 0x000000314be36285 in __GI_raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x000000314be37b9b in __GI_abort () at abort.c:91
#2 0x000000314be75fae in __libc_message (do_abort=2,
fmt=0x314bf74af8 "*** glibc detected *** %s: %s: 0x%s ***\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:198
#3 0x000000314be7c2d6 in malloc_printerr (action=3,
str=0x314bf71aac "corrupted double-linked list", ptr=<optimized out>)
at malloc.c:5021
#4 0x000000314be7c7a9 in malloc_consolidate (av=0x314c1af700)
at malloc.c:4266
#5 0x000000314be7d3c9 in malloc_consolidate (av=0x314c1af700)
at malloc.c:4227
#6 _int_free (av=0x314c1af700, p=<optimized out>, have_lock=0)
at malloc.c:4158
#7 0x00007fcde48e426d in ?? ()
from /home/nicolas/Projects/OpenCL/AMD-APP-SDK-v2.6-RC3-lnx64/lib/x86_64/libamdocl64.so
#8 0x00007fcde48e551e in ?? ()
from /home/nicolas/Projects/OpenCL/AMD-APP-SDK-v2.6-RC3-lnx64/lib/x86_64/libamdocl64.so
#9 0x00007fcde494797d in ?? ()
from /home/nicolas/Projects/OpenCL/AMD-APP-SDK-v2.6-RC3-lnx64/lib/x86_64/libamdocl64.so
#10 0x00007fcde49479a5 in ?? ()
from /home/nicolas/Projects/OpenCL/AMD-APP-SDK-v2.6-RC3-lnx64/lib/x86_64/libamdocl64.so
#11 0x00007fcde3c6d0b9 in ?? ()
from /home/nicolas/Projects/OpenCL/AMD-APP-SDK-v2.6-RC3-lnx64/lib/x86_64/libamdocl64.so
#12 0x000000314be39931 in __run_exit_handlers (status=0, listp=0x314c1af668,
run_list_atexit=true) at exit.c:78
#13 0x000000314be399b5 in __GI_exit (status=<optimized out>) at exit.c:100
#14 0x00000000004d21a8 in stg_exit ()
#15 0x00000000004d21cd in shutdownHaskellAndExit ()
#16 0x00000000004daab1 in real_main ()
#17 0x00000000004daafe in hs_main ()
#18 0x000000314be2169d in __libc_start_main (main=0x404030 <main>, argc=1,
ubp_av=0x7fff96abc628, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fff96abc618) at libc-start.c:226
#19 0x0000000000406b45 in _start ()
Once in a while execution crashes with this backtrace:
#0 0x000000314be7c65f in malloc_consolidate (av=0x314c1af700)
at malloc.c:4258
#1 0x000000314be7d3c9 in malloc_consolidate (av=0x314c1af700)
at malloc.c:4227
#2 _int_free (av=0x314c1af700, p=<optimized out>, have_lock=0)
at malloc.c:4158
(rest as above)
I'm not sure, but this looks like a double-free to me.
This might obviously be a bug in the AMD SDK, not sure...
Using ghc-7.0.4-31.3.fc16.x86_64, AMD-APP-SDK-v2.6-RC3-lnx64 and (Haskell) OpenCL 1.0.2.4.