Created attachment 91998 [details] gegl don't askfor cl/gl extensions The tests/compositions/clones.xml from gegl test suite segfaults when using mesa OpenCL on Radeon HD 7570 (AMD Turks). I tired running it in gdb, here's the backtrace: [New Thread 0x7fffca312700 (LWP 8187)] Program received signal SIGSEGV, Segmentation fault. 0x00007fffffffc8b0 in ?? () (gdb) bt #0 0x00007fffffffc8b0 in ?? () #1 0x00007fffffffc960 in ?? () #2 0x00007fffe6238202 in (anonymous namespace)::InlineSpiller::insertSpill(unsigned int, bool, llvm::MachineBasicBlock::bundle_iterator<llvm::MachineInstr, llvm::ilist_iterator<llvm::MachineInstr> >) () from /home/vesely/.local/lib/libLLVMCodeGen.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) llvm, clang, mesa, libclc, gegl, babl are all latest git as of today. Note that I had to patch gegl in order to use OpenCL on mesa at all (it requires some GL/CL extensions). The patch is attached. Note that the same test crashes when using intel-ocl too.
There are 4 more tests that were failing for different reason, but after applying http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199497.html segfault in the same way: contrast-curve, pixelize, posterize, weighted blend. Note that all of these test use conversion kernels from (gegl)/opencl/colors.cl. patching gegl to not use opencl makes the tests pass.
I should have noted that my llvm git includes http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199497.html. Without these patches the backtrace in clones.xml test looks like this: Program received signal SIGSEGV, Segmentation fault. 0x00007fffee163705 in clover::kernel::global_argument::set (this=0xfee690, size=8, value=0x0) at core/kernel.cpp:330 330 buf = &obj<buffer>(*(cl_mem *)value); (gdb) bt #0 0x00007fffee163705 in clover::kernel::global_argument::set (this=0xfee690, size=8, value=0x0) at core/kernel.cpp:330 #1 0x00007fffee1af9d6 in clSetKernelArg (d_kern=0x115e658, idx=1, size=8, value=0x0) at api/kernel.cpp:98 #2 0x00007ffff7db32c2 in gegl_operation_point_composer_cl_process (level=0, result=0xc7f1d0, output=0x106b4b0, aux=0x0, input=0xe152f0, operation=0x9dd010) at gegl-operation-point-composer.c:195 #3 gegl_operation_point_composer_process (operation=0x9dd010, input=0xe152f0, aux=0x0, output=0x106b4b0, result=0xc7f1d0, level=0) at gegl-operation-point-composer.c:246 #4 0x00007ffff7db2bc4 in gegl_operation_composer_process2 ( operation=0x9dd010, context=<optimized out>, output_prop=<optimized out>, result=0xc7f1d0, level=0) at gegl-operation-point-composer.c:117 #5 0x00007ffff7dbbe46 in gegl_graph_process (path=0xcc1020) at gegl-graph-traversal.c:418 #6 0x00007ffff7dbb268 in gegl_eval_manager_apply (self=self@entry=0x81df40, roi=roi@entry=0xb89140) at gegl-eval-manager.c:133 #7 0x00007ffff7db67ed in gegl_node_apply_roi (self=self@entry=0xf8d030, roi=roi@entry=0xb89140) at gegl-node.c:887 #8 0x00007ffff7db6c53 in gegl_node_blit (self=0xf8d030, scale=scale@entry=1, roi=roi@entry=0xb89140, format=0x63ee60, destination_buf=destination_buf@entry=0x1284530, rowstride=rowstride@entry=0, flags=flags@entry=GEGL_BLIT_DEFAULT) ---Type <return> to continue, or q <return> to quit--- at gegl-node.c:948 #9 0x00007ffff7dbd0be in render_rectangle (processor=0xd7a560) at gegl-processor.c:502 #10 gegl_processor_render (progress=0x0, rectangle=0xd7a580, processor=0xd7a560) at gegl-processor.c:642 #11 gegl_processor_work (processor=processor@entry=0xd7a560, progress=progress@entry=0x0) at gegl-processor.c:777 #12 0x00007ffff7db68b2 in gegl_node_process (self=<optimized out>) at gegl-node.c:1610 #13 0x0000000000401d27 in main (argc=6, argv=0x7fffffffe008) at gegl.c:232
Created attachment 92006 [details] Don't crash on NULL global mem objects The attached patch fixes the original issue (bt in #c2), and adds prelimnary support for NULL global mem objects.
(In reply to comment #3) > Created attachment 92006 [details] > Don't crash on NULL global mem objects > > The attached patch fixes the original issue (bt in #c2), and adds prelimnary > support for NULL global mem objects. Can you send this patch to the mailing list and cc Francisco. Also, in order to fix this correctly on r600g, you will need to reserve offset 0 in the memory pool, so that there are 0 can never be a valid pointer. You can do this by creating a 1024 byte memory pool item and adding it to the item list in the compute_memory_pool_init() function. This should reserve the space so no other items can use it.
fixed in 6ec210989fa10847091f06fcfcab77dd07618dff
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.