Hi Toby,

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.

Best regards,
Karli


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 <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
>>
>>
>> ------------------------------------------------------------------------------
>


------------------------------------------------------------------------------
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel

Reply via email to