Getting segfault. Could you check?

I appended samplecode of cl.hpp with another kernel and I get a segmentation fault. Is the kernel wrong? Did I forgot anything?

It would be very helpful, if some of you check this program for segfaults.

System: Arch Linux

NVidia Linux 64bit driver 260.19.36

[Update1]: and also 260.19.44.

[Update2]: Driver 270.18 and 270.26 (Beta!!) do not crash. However I get 5 invalid reads, so further crashes are possible. I hope these will vanish over time.

My code:

#define __CL_ENABLE_EXCEPTIONS

#if defined(__APPLE__) || defined(__MACOSX)

#include <OpenCL/cl.hpp>

#else

#include <CL/cl.hpp>

#endif

#include <cstdio>

#include <cstdlib>

#include <iostream>

const char * helloStr  = "__kernel void mipmap(__global __read_only image2d_t in0,"

							"__global __read_only image2d_t in1,"

							"__global __read_only image2d_t in2,"

							"__global __read_only image2d_t in3,"

							"__global __write_only image2d_t out){"

							"}";

int

 main(void)

 {

    cl_int err = CL_SUCCESS;

    try {

std::vector<cl::Platform> platforms;

      cl::Platform::get(&platforms);

      if (platforms.size() == 0) {

          std::cout << "Platform size 0\n";

          return -1;

      }

cl_context_properties properties[] =

         { CL_CONTEXT_PLATFORM, (cl_context_properties)(platforms[0])(), 0};

      cl::Context context(CL_DEVICE_TYPE_DEFAULT, properties);

std::vector<cl::Device> devices = context.getInfo<CL_CONTEXT_DEVICES>();

cl::Program::Sources source(1,

          std::make_pair(helloStr,strlen(helloStr)));

      cl::Program program_ = cl::Program(context, source);

      program_.build(devices);

}

    catch (cl::Error err) {

       std::cerr

          << "ERROR: "

          << err.what()

          << "("

          << err.err()

          << ")"

          << std::endl;

    }

return EXIT_SUCCESS;

 }

The corresponding valgrind message:

==4395== Memcheck, a memory error detector

==4395== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.

==4395== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info

==4395== Command: ./badcode

==4395== 

==4395== Invalid read of size 4

==4395==    at 0x63FBB9E: ??? (in /usr/lib/libcuda.so.260.19.36)

==4395==    by 0x63FC264: ??? (in /usr/lib/libcuda.so.260.19.36)

==4395==    by 0x63FD79A: ??? (in /usr/lib/libcuda.so.260.19.36)

==4395==    by 0x640A53D: ??? (in /usr/lib/libcuda.so.260.19.36)

==4395==    by 0x64935B4: ??? (in /usr/lib/libcuda.so.260.19.36)

==4395==    by 0x401BE8: cl::Program::build(std::vector<cl::Device, std::allocator<cl::Device> > const&, char const*, void (*)(_cl_program*, void*), void*) const (in /home/alex/projects/opencl/badcode)

==4395==    by 0x401334: main (in /home/alex/projects/opencl/badcode)

==4395==  Address 0x28 is not stack'd, malloc'd or (recently) free'd

==4395== 

==4395== 

==4395== Process terminating with default action of signal 11 (SIGSEGV)

==4395==  Access not within mapped region at address 0x28

==4395==    at 0x63FBB9E: ??? (in /usr/lib/libcuda.so.260.19.36)

==4395==    by 0x63FC264: ??? (in /usr/lib/libcuda.so.260.19.36)

==4395==    by 0x63FD79A: ??? (in /usr/lib/libcuda.so.260.19.36)

==4395==    by 0x640A53D: ??? (in /usr/lib/libcuda.so.260.19.36)

==4395==    by 0x64935B4: ??? (in /usr/lib/libcuda.so.260.19.36)

==4395==    by 0x401BE8: cl::Program::build(std::vector<cl::Device, std::allocator<cl::Device> > const&, char const*, void (*)(_cl_program*, void*), void*) const (in /home/alex/projects/opencl/badcode)

==4395==    by 0x401334: main (in /home/alex/projects/opencl/badcode)

==4395==  If you believe this happened as a result of a stack

==4395==  overflow in your program's main thread (unlikely but

==4395==  possible), you can try to increase the size of the

==4395==  main thread stack using the --main-stacksize= flag.

==4395==  The main thread stack size used in this run was 8388608.

==4395== 

==4395== HEAP SUMMARY:

==4395==     in use at exit: 872,953 bytes in 1,877 blocks

==4395==   total heap usage: 203,792 allocs, 201,915 frees, 42,249,831 bytes allocated

==4395== 

==4395== LEAK SUMMARY:

==4395==    definitely lost: 5,723 bytes in 225 blocks

==4395==    indirectly lost: 9,552 bytes in 75 blocks

==4395==      possibly lost: 3,113 bytes in 60 blocks

==4395==    still reachable: 854,565 bytes in 1,517 blocks

==4395==         suppressed: 0 bytes in 0 blocks

==4395== Rerun with --leak-check=full to see details of leaked memory

==4395== 

==4395== For counts of detected and suppressed errors, rerun with: -v

==4395== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 16 from 10)

Thank you!

Best regards,

Alex