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

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?

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

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.

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