[lldb-dev] SBValues referencing deallocated memory
Raphael “Teemperor” Isemann via lldb-dev
lldb-dev at lists.llvm.org
Tue Nov 26 23:47:33 PST 2019
This can also be reproduced in the command line like this:
(lldb) expr "foo"
(const char [4]) $0 = "foo"
(lldb) expr "bar"
(const char [4]) $1 = "bar"
(lldb) expr $0
(const char [4]) $0 = “bar”
This however works just fine:
(lldb) expr char c[] = "foo"; c
(char [4]) $0 = "foo"
(lldb) expr char c[] = "bar"; c
(char [4]) $1 = "bar"
(lldb) expr $0
(char [4]) $0 = “foo”
I don’t know the related code so well, but from what I remember we have a storage mechanism for persistent variables that we fill up (in the ‘Materializer’ IIRC). We probably just copy the pointer itself to this storage but not the memory it points to. I guess we could tweak that logic to detect pointers that point into memory LLDB allocated and then either extract the necessary memory into our storage or keep the related sections around.
Anyway, I filed https://bugs.llvm.org/show_bug.cgi?id=44155 <https://bugs.llvm.org/show_bug.cgi?id=44155> and I will ask around what solution people would prefer once thanksgiving is over.
> On 26. Nov 2019, at 15:40, Lutz Justen via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>
> Hi,
>
> We're running into a problem where a Python SBValue references stale memory. It can be reproduced by evaluating an expression with a constant string:
>
> var1 = frame.EvaluateExpression("\"ABCDEFGEH\"")
> var2 = frame.EvaluateExpression("\"123456789\"")
> print(var1.GetSummary())
> print(var2.GetSummary())
>
> This will print
>
> "123456789"
> "123456789"
>
> and not as you would expect
>
> "ABCDEFGEH"
> "123456789"
>
> If you print the addresses,
>
> print(var1.AddressOf())
> print(var2.AddressOf())
>
> they're the same, e.g.
>
> (const char (*)[10]) &$0 = 0x0000012d787c0010
> (const char (*)[10]) &$1 = 0x0000012d787c0010
>
> Walking through the code, it seems like the SBValues (var1 and var2) point to deallocated memory. The memory is allocated and owned by ClangUserExpression and deallocated by its destructor, but the SBValues are clinging to the address (see callstacks below).
>
> What's the best approach to deal with this? Could the ownership somehow be transferred to the SBValue? Any pointers?
>
> Thanks,
>
> - Lutz
>
>
> ********* CALLSTACK FOR ALLOCATION OF THE CONSTANT STRING *********
>
> > _lldb.pyd!lldb_private::AllocatedMemoryCache::AllocateMemory(unsigned __int64 byte_size, unsigned int permissions, lldb_private::Status & error) Line 373 C++
> _lldb.pyd!lldb_private::Process::AllocateMemory(unsigned __int64 size, unsigned int permissions, lldb_private::Status & error) Line 2560 C++
> _lldb.pyd!lldb_private::IRMemoryMap::Malloc(unsigned __int64 size, unsigned char alignment, unsigned int permissions, lldb_private::IRMemoryMap::AllocationPolicy policy, bool zero_memory, lldb_private::Status & error) Line 389 C++
> _lldb.pyd!lldb_private::IRExecutionUnit::CommitOneAllocation(std::shared_ptr<lldb_private::Process> & process_sp, lldb_private::Status & error, lldb_private::IRExecutionUnit::AllocationRecord & record) Line 1116 C++
> _lldb.pyd!lldb_private::IRExecutionUnit::CommitAllocations(std::shared_ptr<lldb_private::Process> & process_sp) Line 1125 C++
> _lldb.pyd!lldb_private::IRExecutionUnit::GetRunnableInfo(lldb_private::Status & error, unsigned __int64 & func_addr, unsigned __int64 & func_end) Line 363 C++
> _lldb.pyd!lldb_private::ClangExpressionParser::PrepareForExecution(unsigned __int64 & func_addr, unsigned __int64 & func_end, std::shared_ptr<lldb_private::IRExecutionUnit> & execution_unit_sp, lldb_private::ExecutionContext & exe_ctx, bool & can_interpret, lldb_private::ExecutionPolicy execution_policy) Line 1221 C++
> _lldb.pyd!lldb_private::ClangUserExpression::Parse(lldb_private::DiagnosticManager & diagnostic_manager, lldb_private::ExecutionContext & exe_ctx, lldb_private::ExecutionPolicy execution_policy, bool keep_result_in_memory, bool generate_debug_info) Line 554 C++
> _lldb.pyd!lldb_private::UserExpression::Evaluate(lldb_private::ExecutionContext & exe_ctx, const lldb_private::EvaluateExpressionOptions & options, llvm::StringRef expr, llvm::StringRef prefix, lldb_private::SharingPtr<lldb_private::ValueObject> & result_valobj_sp, lldb_private::Status & error, unsigned int line_offset, std::basic_string<char,std::char_traits<char>,std::allocator<char> > * fixed_expression, std::shared_ptr<lldb_private::Module> * jit_module_sp_ptr, lldb_private::ValueObject * ctx_obj) Line 258 C++
> _lldb.pyd!lldb_private::Target::EvaluateExpression(llvm::StringRef expr, lldb_private::ExecutionContextScope * exe_scope, lldb_private::SharingPtr<lldb_private::ValueObject> & result_valobj_sp, const lldb_private::EvaluateExpressionOptions & options, std::basic_string<char,std::char_traits<char>,std::allocator<char> > * fixed_expression, lldb_private::ValueObject * ctx_obj) Line 2406 C++
> _lldb.pyd!lldb_private::ValueObject::CreateValueObjectFromExpression(llvm::StringRef name, llvm::StringRef expression, const lldb_private::ExecutionContext & exe_ctx, const lldb_private::EvaluateExpressionOptions & options) Line 3136 C++
> _lldb.pyd!lldb::SBValue::CreateValueFromExpression(const char * name, const char * expression, lldb::SBExpressionOptions & options) Line 725 C++
> _lldb.pyd!lldb::SBValue::CreateValueFromExpression(const char * name, const char * expression) Line 712 C++
> _lldb.pyd!_wrap_SBValue_CreateValueFromExpression__SWIG_0(_object * __formal, _object * args) Line 71739 C++
> _lldb.pyd!_wrap_SBValue_CreateValueFromExpression(_object * self, _object * args) Line 71839 C++
>
> ********* CALLSTACK FOR DEALLOCATION OF THE CONSTANT STRING *********
>
> > _lldb.pyd!lldb_private::AllocatedBlock::FreeBlock(unsigned __int64 addr) Line 318 C++
> _lldb.pyd!lldb_private::AllocatedMemoryCache::DeallocateMemory(unsigned __int64 addr) Line 407 C++
> _lldb.pyd!lldb_private::Process::DeallocateMemory(unsigned __int64 ptr) Line 2613 C++
> _lldb.pyd!lldb_private::IRMemoryMap::Free(unsigned __int64 process_address, lldb_private::Status & error) Line 475 C++
> _lldb.pyd!lldb_private::IRMemoryMap::~IRMemoryMap() Line 36 C++
> _lldb.pyd!lldb_private::IRExecutionUnit::~IRExecutionUnit() Line 495 C++
> _lldb.pyd!lldb_private::IRExecutionUnit::`scalar deleting destructor'(unsigned int) C++
> _lldb.pyd!lldb_private::LLVMUserExpression::~LLVMUserExpression() Line 65 C++
> _lldb.pyd!lldb_private::ClangUserExpression::`scalar deleting destructor'(unsigned int) C++
> _lldb.pyd!std::_Ref_count_base::_Decref() Line 848 C++
> _lldb.pyd!lldb_private::UserExpression::Evaluate(lldb_private::ExecutionContext & exe_ctx, const lldb_private::EvaluateExpressionOptions & options, llvm::StringRef expr, llvm::StringRef prefix, lldb_private::SharingPtr<lldb_private::ValueObject> & result_valobj_sp, lldb_private::Status & error, unsigned int line_offset, std::basic_string<char,std::char_traits<char>,std::allocator<char> > * fixed_expression, std::shared_ptr<lldb_private::Module> * jit_module_sp_ptr, lldb_private::ValueObject * ctx_obj) Line 384 C++
> _lldb.pyd!lldb_private::Target::EvaluateExpression(llvm::StringRef expr, lldb_private::ExecutionContextScope * exe_scope, lldb_private::SharingPtr<lldb_private::ValueObject> & result_valobj_sp, const lldb_private::EvaluateExpressionOptions & options, std::basic_string<char,std::char_traits<char>,std::allocator<char> > * fixed_expression, lldb_private::ValueObject * ctx_obj) Line 2406 C++
> _lldb.pyd!lldb_private::ValueObject::CreateValueObjectFromExpression(llvm::StringRef name, llvm::StringRef expression, const lldb_private::ExecutionContext & exe_ctx, const lldb_private::EvaluateExpressionOptions & options) Line 3136 C++
> _lldb.pyd!lldb::SBValue::CreateValueFromExpression(const char * name, const char * expression, lldb::SBExpressionOptions & options) Line 725 C++
> _lldb.pyd!lldb::SBValue::CreateValueFromExpression(const char * name, const char * expression) Line 712 C++
> _lldb.pyd!_wrap_SBValue_CreateValueFromExpression__SWIG_0(_object * __formal, _object * args) Line 71739 C++
> _lldb.pyd!_wrap_SBValue_CreateValueFromExpression(_object * self, _object * args) Line 71839 C++
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20191127/22ae0de4/attachment-0001.html>
More information about the lldb-dev
mailing list