Closed Michael137 closed 2 weeks ago
This was reported by a test-suite run in a local ASAN/UBSAN build on my M1:
================================================================= ==69533==ERROR: AddressSanitizer: stack-use-after-scope on address 0x000106b68e50 at pc 0x00011cacfaa4 bp 0x00016b8c7ff0 sp 0x00016b8c7fe8 READ of size 8 at 0x000106b68e50 thread T0 #0 0x11cacfaa0 in lldb_private::ValueObject::GetChildAtNamePath(llvm::ArrayRef<llvm::StringRef>) ValueObject.cpp:471 #1 0x11ce85908 in lldb_private::formatters::NSTimeZoneSummaryProvider(lldb_private::ValueObject&, lldb_private::Stream&, lldb_private::TypeSummaryOptions const&) Cocoa.cpp:157 #2 0x11c51bad0 in lldb_private::CXXFunctionSummaryFormat::FormatObject(lldb_private::ValueObject*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, lldb_private::TypeSummaryOptions const&) TypeSummary.cpp:129 #3 0x11cad2eb4 in lldb_private::ValueObject::GetSummaryAsCString(lldb_private::TypeSummaryImpl*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, lldb_private::TypeSummaryOptions const&) ValueObject.cpp:691 #4 0x11cad2b18 in lldb_private::ValueObject::GetSummaryAsCString(lldb_private::TypeSummaryImpl*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, lldb::LanguageType) ValueObject.cpp:648 #5 0x11c528d38 in lldb_private::ValueObjectPrinter::GetValueSummaryError(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, std::__1::basic_strin g<char, std::__1::char_traits<char>, std::__1::allocator<char>>&) ValueObjectPrinter.cpp:402 #6 0x11c526604 in lldb_private::ValueObjectPrinter::PrintValueAndSummaryIfNeeded(bool&, bool&) ValueObjectPrinter.cpp:420 #7 0x11c524748 in lldb_private::ValueObjectPrinter::PrintValueObject() ValueObjectPrinter.cpp:91 #8 0x11cae7a10 in lldb_private::ValueObject::Dump(lldb_private::Stream&, lldb_private::DumpValueObjectOptions const&) ValueObject.cpp:2826 #9 0x11d9ed628 in CommandObjectFrameVariable::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) CommandObjectFrame.cpp:679 #10 0x11c67f3e4 in lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) CommandObject.cpp:826 #11 0x11c65f9d4 in lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, bool) CommandInterpreter.cpp:2101 #12 0x11bdb72a8 in lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBExecutionContext&, lldb::SBCommandReturnObject&, bool) SBCommandInterpreter.cpp:194 #13 0x11bdb6a00 in lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBCommandReturnObject&, bool) SBCommandInterpreter.cpp:176 #14 0x11c1612e8 in _wrap_SBCommandInterpreter_HandleCommand(_object*, _object*) LLDBWrapPython.cpp:16926
I'm not sure why this doesn't show up in the public ASAN bot, but binding a temporary initializer-list to a non-owning ArrayRef like this isn't safe.
ArrayRef
This was reported by a test-suite run in a local ASAN/UBSAN build on my M1:
I'm not sure why this doesn't show up in the public ASAN bot, but binding a temporary initializer-list to a non-owning
ArrayRef
like this isn't safe.