[Solved][Relay]Segmentation Fault in GetType when calling infer_type


#1

I’m trying to add a new operator to relay but got segmentation fault when calling infer_type. It happens while populating the constraints https://github.com/dmlc/tvm/blob/master/src/relay/pass/type_infer.cc#L525. After further inspection, segfault happens when returning the checked type: https://github.com/dmlc/tvm/blob/master/src/relay/pass/type_infer.cc#L148 The checked type itself looks right and can be printed. Anyone has the similar issue before?


#2
#0  0x00007fff985df6ed in tvm::relay::TypeInferencer::PrimitiveCall(tvm::relay::FuncTypeNode const*, tvm::Array<tvm::relay::Type, void>, tvm::Attrs const&) ()
   from /home/ubuntu/tvm/build/libtvm.so
#1  0x00007fff985e2a3f in tvm::relay::TypeInferencer::VisitExpr_(tvm::relay::CallNode const*) () from /home/ubuntu/tvm/build/libtvm.so
#2  0x00007fff985d76b4 in std::_Function_handler<tvm::relay::Type (tvm::NodeRef const&, tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>*), tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>::InitVTable()::{lambda(tvm::NodeRef const&, tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>*)#6}>::_M_invoke(std::_Any_data const&, tvm::NodeRef const&, tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>*&&) () from /home/ubuntu/tvm/build/libtvm.so
#3  0x00007fff985d9d13 in tvm::IRFunctor<tvm::relay::Type (tvm::NodeRef const&, tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>*)>::operator()(tvm::NodeRef const&, tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>*) const () from /home/ubuntu/tvm/build/libtvm.so
#4  0x00007fff985dd865 in tvm::relay::TypeInferencer::GetType(tvm::relay::Expr const&) () from /home/ubuntu/tvm/build/libtvm.so
#5  0x00007fff985dfd95 in tvm::relay::TypeInferencer::VisitExpr_(tvm::relay::FunctionNode const*) () from /home/ubuntu/tvm/build/libtvm.so
#6  0x00007fff985d7634 in std::_Function_handler<tvm::relay::Type (tvm::NodeRef const&, tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>*), tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>::InitVTable()::{lambda(tvm::NodeRef const&, tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>*)#5}>::_M_invoke(std::_Any_data const&, tvm::NodeRef const&, tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>*&&) () from /home/ubuntu/tvm/build/libtvm.so
#7  0x00007fff985d9d13 in tvm::IRFunctor<tvm::relay::Type (tvm::NodeRef const&, tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>*)>::operator()(tvm::NodeRef const&, tvm::relay::ExprFunctor<tvm::relay::Type (tvm::relay::Expr const&)>*) const () from /home/ubuntu/tvm/build/libtvm.so
#8  0x00007fff985dd865 in tvm::relay::TypeInferencer::GetType(tvm::relay::Expr const&) () from /home/ubuntu/tvm/build/libtvm.so
#9  0x00007fff985d58a6 in tvm::relay::TypeInferencer::Infer(tvm::relay::Expr) () from /home/ubuntu/tvm/build/libtvm.so
#10 0x00007fff985d5afe in tvm::relay::InferType(tvm::relay::Expr const&, tvm::relay::Module const&) () from /home/ubuntu/tvm/build/libtvm.so
#11 0x00007fff985d5d37 in std::_Function_handler<void (tvm::runtime::TVMArgs, tvm::runtime::TVMRetValue*), tvm::relay::{lambda(tvm::runtime::TVMArgs, tvm::runtime::TVMRetValue*)#2}>::_M_invoke () from /home/ubuntu/tvm/build/libtvm.so
#12 0x00007fff9885b8fe in TVMFuncCall () from /home/ubuntu/tvm/build/libtvm.so
#13 0x00007ffff4e43e40 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#14 0x00007ffff4e438ab in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#15 0x00007ffff50533df in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
#16 0x00007ffff5057d82 in ?? () from /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
#17 0x00000000004c166d in PyEval_EvalFrameEx ()
#18 0x00000000004b9b66 in PyEval_EvalCodeEx ()
#19 0x00000000004d5669 in ?? ()
#20 0x00000000004eef5e in ?? ()
#21 0x00000000004a587e in PyObject_Call ()
#22 0x0000000000548fc3 in ?? ()
#23 0x00000000004c166d in PyEval_EvalFrameEx ()
#24 0x00000000004b9b66 in PyEval_EvalCodeEx ()
#25 0x00000000004c17c6 in PyEval_EvalFrameEx ()
#26 0x00000000004b9b66 in PyEval_EvalCodeEx ()
#27 0x00000000004c1f56 in PyEval_EvalFrameEx ()
#28 0x00000000004c141f in PyEval_EvalFrameEx ()
#29 0x00000000004b9b66 in PyEval_EvalCodeEx ()
#30 0x00000000004eb69f in ?? ()
#31 0x00000000004e58f2 in PyRun_FileExFlags ()
#32 0x00000000004e41a6 in PyRun_SimpleFileExFlags ()
#33 0x00000000004938ce in Py_Main ()
#34 0x00007ffff75f5830 in __libc_start_main (main=0x493370 <main>, argc=2, argv=0x7fffffffe3b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffffffe3a8) at ../csu/libc-start.c:291
#35 0x0000000000493299 in _start ()

This is the full backtrace.


#3

It turns out that I provided the whole api path as op name when register the operator. The actual operator is not registered and some attributes are null pointers.


#4

Is it possible for us to add some CHECK calls in order to provide a better error instead of faulting?