Karl Rupp <[email protected]> writes: > thanks for the reports. I'll run the respective functions through a > valgrind-like environment today, but I don't expect something to show up > at this point. The direct solve kernels for dense matrices are unchanged > for quite some time and haven't shown anything suspicious in the nightly > tests for *months* now. Thus, I'm very tempted to assume that this is a > problem with beignet - yet I'll double-check.
Yes, I think so, too, now. But it is weird that I received a segfault on nVidia initially, too. I haven't studied the kernel caching mechanism: at the moment, the PyViennaCL cache directory is versioned, but should it also be separate for different devices? (And I will need to remember to clear out the cache directory for different viennacl git revisions, or add a mechanism to include the git reference..) Toby > > > On 11/04/2014 10:26 AM, Toby St Clere Smithe wrote: >> I deleted my kernel cache and rebuilt with debugging info on -- same >> behaviour, and nothing obvious in the output. See [1]. I've also got a >> more detailed traceback at [2]. I also investigated the arguments and >> local variables in the add_program call[3], and the line >> "num_kernels_in_prog = 35284968" seems suspicious to me. But I'm also >> running the tests on nVidia again (with debugging on and a clean kernel >> cache this time), and so far, no segfault.. >> >> [1] http://paste.ubuntu.com/8815933/ >> [2] http://paste.ubuntu.com/8815949/ >> [3] http://paste.ubuntu.com/8816098/ >> >> Best, >> >> Toby >> >> Toby St Clere Smithe <[email protected]> >> writes: >>> test_direct_solvers.py:38: >>> test_matrix_slice_unit_upper_A_matrix_slice_B_C_float32 >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x00007fffe6c96581 in llvm::Function::getIntrinsicID() const () from >>> /usr/local/lib/beignet//libgbe.so >>> (gdb) bt >>> #0 0x00007fffe6c96581 in llvm::Function::getIntrinsicID() const () from >>> /usr/local/lib/beignet//libgbe.so >>> #1 0x00007fffe5ffbdeb in gbe::materializedFuncCall (src=..., lib=..., >>> KF=..., MFS=...) at >>> /home/toby/src/scientific/beignet/backend/src/llvm/llvm_bitcode_link.cpp:90 >>> #2 0x00007fffe5ffc9c9 in gbe::runBitCodeLinker >>> (mod=mod@entry=0x1f4b0f0) at >>> /home/toby/src/scientific/beignet/backend/src/llvm/llvm_bitcode_link.cpp:157 >>> #3 0x00007fffe6042bbe in gbe::llvmToGen (unit=..., >>> fileName=fileName@entry=0x0, module=module@entry=0x1f4b0f0, >>> optLevel=optLevel@entry=1) >>> at >>> /home/toby/src/scientific/beignet/backend/src/llvm/llvm_to_gen.cpp:226 >>> #4 0x00007fffe5feb2d1 in gbe::Program::buildFromLLVMFile >>> (this=this@entry=0x1ed6780, fileName=fileName@entry=0x0, >>> module=module@entry=0x1f4b0f0, error=..., >>> optLevel=optLevel@entry=1) at >>> /home/toby/src/scientific/beignet/backend/src/backend/program.cpp:115 >>> #5 0x00007fffe60a982f in gbe::genProgramNewFromLLVM (deviceID=358, >>> fileName=0x0, module=0x1f4b0f0, llvm_ctx=<optimised out>, stringSize=912, >>> err=0x1ed6eb8 "", >>> errSize=0x1ed6a20, optLevel=1) at >>> /home/toby/src/scientific/beignet/backend/src/backend/gen_program.cpp:332 >>> #6 0x00007fffe5fee865 in gbe::programNewFromSource (deviceID=358, >>> source=<optimised out>, stringSize=912, >>> options=0x7ffff477d3f8 <std::string::_Rep::_S_empty_rep_storage+24> >>> "", err=0x1ed6eb8 "", errSize=0x1ed6a20) >>> at >>> /home/toby/src/scientific/beignet/backend/src/backend/program.cpp:749 >>> #7 0x00007fffe861eb88 in cl_program_build (p=p@entry=0x1ed6990, >>> options=0x7ffff477d3f8 <std::string::_Rep::_S_empty_rep_storage+24> "") >>> at /home/toby/src/scientific/beignet/src/cl_program.c:463 >>> #8 0x00007fffe86181fa in clBuildProgram (program=0x1ed6990, >>> num_devices=<optimised out>, device_list=<optimised out>, >>> options=<optimised out>, pfn_notify=0x0, >>> user_data=0x0) at /home/toby/src/scientific/beignet/src/cl_api.c:945 >>> #9 0x00007ffff531e234 in >>> viennacl::ocl::context::add_program(std::string const&, std::string const&) >>> () >>> from >>> /home/toby/src/scientific/viennacl/pyviennacl-dev/build/lib.linux-x86_64-2.7/pyviennacl/_viennacl.so >>> >>> >>> In both cases it seems to be something in the program name. Philippe, >>> could you run these on AMD hardware, to be sure it's not idiosyncratic >>> to the nVidia and Intel implementations? >>> >>> Run something like >>> >>> PYTHONPATH=../build/lib.linux-x86_64-2.7 py.test test*py -v -s >>> >>> >>> Cheers, >>> >>> Toby >>> >>> >>> ------------------------------------------------------------------------------ >> > > > ------------------------------------------------------------------------------ -- Toby St Clere Smithe http://tsmithe.net ------------------------------------------------------------------------------ _______________________________________________ ViennaCL-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/viennacl-devel
