This macro crashes LibreOffice: sub foo a = Array() oUnoValue = CreateUnoValue( "[]", a ) end sub The problem is "[]", not describing the type of the sequence. TypeConverter_Impl::convertTo tries to dereference nullpointer returned from aDestTD.get(). Stephan: IMO this is wrong to allow macros to crash software; but is there any obstacles disallowing checking this situation?
> Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault. > 0x00007fffc413b2db in stoc_tcv::(anonymous namespace)::TypeConverter_Impl::convertTo (this=0x3269200, rVal=uno::Any("[]any": empty uno::Sequence), aDestType=invalid uno::Type) at stoc/source/typeconv/convert.cxx:537 > 537 reinterpret_cast<typelib_IndirectTypeDescription *>(aDestTD.get())->pType ); > (gdb) bt > #0 0x00007fffc413b2db in stoc_tcv::(anonymous namespace)::TypeConverter_Impl::convertTo(com::sun::star::uno::Any const&, com::sun::star::uno::Type const&) (this=0x3269200, rVal=uno::Any("[]any": empty uno::Sequence), aDestType=invalid uno::Type) at stoc/source/typeconv/convert.cxx:537 > #1 0x00007fffc413d144 in non-virtual thunk to stoc_tcv::(anonymous namespace)::TypeConverter_Impl::convertTo(com::sun::star::uno::Any const&, com::sun::star::uno::Type const&) () at instdir/program/libstocserviceslo.so > #2 0x00007ffff4fe0264 in convertAny(com::sun::star::uno::Any const&, com::sun::star::uno::Type const&) (rVal=uno::Any("[]any": empty uno::Sequence), aDestType=invalid uno::Type) at basic/source/classes/sbunoobj.cxx:324 > #3 0x00007ffff4fdfe79 in RTL_Impl_CreateUnoValue(SbxArray&) (rPar=...) at basic/source/classes/sbunoobj.cxx:4157 > #4 0x00007ffff513b1b0 in SbRtl_CreateUnoValue(StarBASIC*, SbxArray&, bool) (rPar=...) at basic/source/runtime/methods1.cxx:1403 > #5 0x00007ffff50ea80e in SbiStdObject::Notify(SfxBroadcaster&, SfxHint const&) (this=0x2003400, rBC=..., rHint=...) at basic/source/runtime/stdobj.cxx:1059 > #6 0x00007ffff3decfae in SfxBroadcaster::Broadcast(SfxHint const&) (this=0x3329e90, rHint=...) at svl/source/notify/SfxBroadcaster.cxx:39 > #7 0x00007ffff518e772 in SbxVariable::Broadcast(SfxHintId) (this=0x31e8f60, nHintId=SfxHintId::BasicDataWanted) at basic/source/sbx/sbxvar.cxx:151 > #8 0x00007ffff5186d4f in SbxValue::SbxValue(SbxValue const&) (this=0x31ff450, vtt=0x7ffff51ae718 <VTT for SbxMethod+16>, r=...) at basic/source/sbx/sbxvalue.cxx:66 > #9 0x00007ffff518d291 in SbxVariable::SbxVariable(SbxVariable const&) (this=0x31ff450, vtt=0x7ffff51ae710 <VTT for SbxMethod+8>, r=...) at basic/source/sbx/sbxvar.cxx:45 > #10 0x00007ffff517d44a in SbxMethod::SbxMethod(SbxMethod const&) (this=0x31ff450, r=...) at basic/source/sbx/sbxobj.cxx:838 > #11 0x00007ffff510386b in SbiRuntime::FindElement(SbxObject*, unsigned int, unsigned int, ErrCode, bool, bool) (this=0x2d6f400, pObj=0x2003400, nOp1=32773, nOp2=9, nNotFound=..., bLocal=false, bStatic=false) at basic/source/runtime/runtime.cxx:3709 > #12 0x00007ffff50f5a91 in SbiRuntime::StepRTL(unsigned int, unsigned int) (this=0x2d6f400, nOp1=32773, nOp2=9) at basic/source/runtime/runtime.cxx:4131 > #13 0x00007ffff50faef8 in SbiRuntime::Step() (this=0x2d6f400) at basic/source/runtime/runtime.cxx:830 [...] In frame #3 with aTypeName = "[]", > // Check the type > const Reference< XHierarchicalNameAccess >& xTypeAccess = getTypeProvider_Impl(); > Any aRet; > try > { > aRet = xTypeAccess->getByHierarchicalName( aTypeName ); > } > catch( const NoSuchElementException& e1 ) > { > StarBASIC::Error( ERRCODE_BASIC_EXCEPTION, > implGetExceptionMsg( e1, u"com.sun.star.container.NoSuchElementException" ) ); > return; > } doesn't hit the catch block because SequenceTypeDescription in cppuhelper/source/typemanager.cxx resolves a sequence type notation's "[]..." component part "..." only lazily. The best place to detect such a bad sequence type notation is probably the implementation of css.script.XTypeConverter::convertTo (frame #0), for which I'll provide a fix.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9074f5602a9b0b51349647f29d8537256217ebe7 tdf#148063: Avoid dereferencing potentially bad user-supplied TypeDescription It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.