[lldb-dev] SBValues referencing deallocated memory

2019-11-26 Thread Lutz Justen via lldb-dev 
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 = 0x012d787c0010
(const char (*)[10]) &$1 = 0x012d787c0010

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
& process_sp, lldb_private::Status & error,
lldb_private::IRExecutionUnit::AllocationRecord & record) Line 1116 C++

_lldb.pyd!lldb_private::IRExecutionUnit::CommitAllocations(std::shared_ptr
& 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 & 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 & result_valobj_sp,
lldb_private::Status & error, unsigned int line_offset,
std::basic_string,std::allocator > *
fixed_expression, std::shared_ptr *
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 & result_valobj_sp,
const lldb_private::EvaluateExpressionOptions & options,
std::basic_string,std::allocator > *
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

[lldb-dev] LLDB sometimes escapes unicode characters, sometimes not

2020-03-23 Thread Lutz Justen via lldb-dev 
Hey,

We've noticed that LLDB sometimes escapes certain characters (e.g. in the
+128/negative range) of const char* strings and sometimes it doesn't. In
particular, this happens for unicode strings:

C++:
const char* str =  u8"😂";

LLDB:
(lldb) expr str
(const char *) $0 = 0x7ff662489d18 "â‰ĄÆ’ĂżĂ©"
(lldb) expr (const char*)str
(const char *) $1 = 0x7ff662489d18
"\xfff0\xff9f\xff98\xff82"

To my understanding, evaluating 'str' and '(const char*)str' should be the
same since str is already a const char*.

We've found that the code takes a different path at this location:
https://source.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/lldb/source/Core/FormatEntity.cpp;l=865;rcl=294541377

Any idea what's going on? We'd like to get the unescaped strings. Is it
possible to enforce this?

Thanks,

- Lutz

-- 

Dr. Lutz Justen

Software Engineer

ljus...@google.com


Google Germany GmbH

ABC-Str. 19


20354 Hamburg


GeschĂ€ftsfĂŒhrer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Diese E-Mail ist vertraulich. Falls sie diese fÀlschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und AnhÀnge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.


Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
wider und dient als Basis fĂŒr weitere GesprĂ€che. Er soll keine rechtlich
verbindliche Verpflichtung begrĂŒnden. Eine solche Verpflichtung wird allein
durch einen zwischen allen beteiligten Parteien abgeschlossenen,
schriftlichen Vertrag geschaffen.

The above terms reflect a potential business arrangement, are provided
solely as a basis for further discussion, and are not intended to be and do
not constitute a legally binding obligation. No legally binding obligations
will be created, implied, or inferred until an agreement in final form is
executed in writing by all parties involved.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB sometimes escapes unicode characters, sometimes not

2020-03-23 Thread Lutz Justen via lldb-dev 
Sorry, the link was internal. Here's the proper on:
https://github.com/llvm-mirror/lldb/blob/master/source/Core/FormatEntity.cpp#L861


On Mon, Mar 23, 2020 at 4:00 PM Lutz Justen  wrote:

> Hey,
>
> We've noticed that LLDB sometimes escapes certain characters (e.g. in the
> +128/negative range) of const char* strings and sometimes it doesn't. In
> particular, this happens for unicode strings:
>
> C++:
> const char* str =  u8"😂";
>
> LLDB:
> (lldb) expr str
> (const char *) $0 = 0x7ff662489d18 "â‰ĄÆ’ĂżĂ©"
> (lldb) expr (const char*)str
> (const char *) $1 = 0x7ff662489d18
> "\xfff0\xff9f\xff98\xff82"
>
> To my understanding, evaluating 'str' and '(const char*)str' should be the
> same since str is already a const char*.
>
> We've found that the code takes a different path at this location:
>
> https://source.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/lldb/source/Core/FormatEntity.cpp;l=865;rcl=294541377
>
> Any idea what's going on? We'd like to get the unescaped strings. Is it
> possible to enforce this?
>
> Thanks,
>
> - Lutz
>
> --
>
> Dr. Lutz Justen
>
> Software Engineer
>
> ljus...@google.com
>
>
> Google Germany GmbH
>
> ABC-Str. 19
> 
>
> 20354 Hamburg
> 
>
> GeschĂ€ftsfĂŒhrer: Paul Manicle, Halimah DeLaine Prado
>
> Registergericht und -nummer: Hamburg, HRB 86891
>
> Diese E-Mail ist vertraulich. Falls sie diese fÀlschlicherweise erhalten
> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
> löschen Sie alle Kopien und AnhÀnge davon und lassen Sie mich bitte wissen,
> dass die E-Mail an die falsche Person gesendet wurde.
>
> This e-mail is confidential. If you received this communication by
> mistake, please don't forward it to anyone else, please erase all copies
> and attachments, and please let me know that it has gone to the wrong
> person.
>
>
> Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
> wider und dient als Basis fĂŒr weitere GesprĂ€che. Er soll keine rechtlich
> verbindliche Verpflichtung begrĂŒnden. Eine solche Verpflichtung wird allein
> durch einen zwischen allen beteiligten Parteien abgeschlossenen,
> schriftlichen Vertrag geschaffen.
>
> The above terms reflect a potential business arrangement, are provided
> solely as a basis for further discussion, and are not intended to be and do
> not constitute a legally binding obligation. No legally binding obligations
> will be created, implied, or inferred until an agreement in final form is
> executed in writing by all parties involved.
>


-- 

Dr. Lutz Justen

Software Engineer

ljus...@google.com


Google Germany GmbH

ABC-Str. 19


20354 Hamburg


GeschĂ€ftsfĂŒhrer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Diese E-Mail ist vertraulich. Falls sie diese fÀlschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und AnhÀnge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.


Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
wider und dient als Basis fĂŒr weitere GesprĂ€che. Er soll keine rechtlich
verbindliche Verpflichtung begrĂŒnden. Eine solche Verpflichtung wird allein
durch einen zwischen allen beteiligten Parteien abgeschlossenen,
schriftlichen Vertrag geschaffen.

The above terms reflect a potential business arrangement, are provided
solely as a basis for further discussion, and are not intended to be and do
not constitute a legally binding obligation. No legally binding obligations
will be created, implied, or inferred until an agreement in final form is
executed in writing by all parties involved.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev