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 <m...@tsmithe.net> 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 ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
