[lldb-dev] Missing Value Formats for wchar_t* and char16_t*

2018-07-27 Thread Ben Ruthig via lldb-dev
Hi,

The list of Var Formats supported  by
LLDB appears to be missing ones for wchar_t* and char16_t data types.  I am
aware that LLDB includes built in summary providers for said types, however
the application in question uses some magic with a custom Data* to allow
the underlying data type to be defined dynamically at run time.  Thus, LLDB
is not able to infer that the actual data type is a wchar_t* and the
desired summary provider is not used.

I just wanted to see if there was already a way to accomplish this or if
not, whether a patch to address this would be welcome?

Is it possible to bind my own Named Summary to the same serializer used by
the built in wchar_t* summary provider?

Thanks,
Ben
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] Missing Value Formats for wchar_t* and char16_t*

2018-08-10 Thread Ben Ruthig via lldb-dev
Friendly ping on this?

On Fri, Jul 27, 2018 at 11:49 AM Ben Ruthig  wrote:

> Hi,
>
> The list of Var Formats supported  by
> LLDB appears to be missing ones for wchar_t* and char16_t data types.  I am
> aware that LLDB includes built in summary providers for said types, however
> the application in question uses some magic with a custom Data* to allow
> the underlying data type to be defined dynamically at run time.  Thus, LLDB
> is not able to infer that the actual data type is a wchar_t* and the
> desired summary provider is not used.
>
> I just wanted to see if there was already a way to accomplish this or if
> not, whether a patch to address this would be welcome?
>
> Is it possible to bind my own Named Summary to the same serializer used by
> the built in wchar_t* summary provider?
>
> Thanks,
> Ben
>


-- 
"Sometimes I've believed as many as six impossible things before breakfast"
- Alice in Wonderland
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] Stackoverflow crash when evaluating an invalid expression

2019-02-28 Thread Ben Ruthig via lldb-dev
Hello all,

I am currently investigating an issue where LLDB is crashing due to a stack
overflow when attempting to evaluate an expression.  I have seen the same
issue in 6.0.1 and have reproduced it in 7.0.1.  Any help to diagnose and
fix would be greatly appreciated as I am trying to meet a release deadline
early next week!

The facts:
- The expression being evaluated is not a valid expression in the C++
domain. For example the expression is a datatype like 'Foobar'.  (For
reasons unexplained I am constrained to supporting this use case.)
- The crash occurs when using the C++ LLDB API but not when trying to
evaluate the expression via the LLDB shell or the LLDB Python script
shell.  However, when doing 'expr Foobar' there is no output and the
operation is completely silent.  It is similar when trying to do
'lldb.frame.EvaluateExpression("Foobar")'
in the Python shell as well.  I would expect to get some error output or an
SbValue in an error state but no such luck.
- I was able to capture a stack trace (attached) and it seems to be a
recursive loop bottoming out.  For brevity two 'loops' of stacktrace are
included here:

3387.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
clang::RecordDecl * D) Line 2965C++
3388.  liblldb.dll!`anonymous
namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
3389.  liblldb.dll!`anonymous
namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext &
Context, const clang::CXXRecordDecl * Class) Line 172C++
3390.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
clang::RecordDecl * D) Line 2965C++
3391.  liblldb.dll!`anonymous
namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
3392.  liblldb.dll!`anonymous
namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext &
Context, const clang::CXXRecordDecl * Class) Line 172C++
3393.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
clang::RecordDecl * D) Line 2965C++

Help please :S

Thanks,
Ben
...
3384.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
clang::RecordDecl * D) Line 2965C++
3385.  liblldb.dll!`anonymous 
namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
3386.  liblldb.dll!`anonymous 
namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext & 
Context, const clang::CXXRecordDecl * Class) Line 172C++
3387.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
clang::RecordDecl * D) Line 2965C++
3388.  liblldb.dll!`anonymous 
namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
3389.  liblldb.dll!`anonymous 
namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext & 
Context, const clang::CXXRecordDecl * Class) Line 172C++
3390.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
clang::RecordDecl * D) Line 2965C++
3391.  liblldb.dll!`anonymous 
namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
3392.  liblldb.dll!`anonymous 
namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext & 
Context, const clang::CXXRecordDecl * Class) Line 172C++
3393.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
clang::RecordDecl * D) Line 2965C++
3394.  liblldb.dll!`anonymous 
namespace'::CGRecordLowering::CGRecordLowering(clang::CodeGen::CodeGenTypes & 
Types, const clang::RecordDecl * D, bool Packed) Line 220C++
3395.  liblldb.dll!clang::CodeGen::CodeGenTypes::ComputeRecordLayout(const 
clang::RecordDecl * D, llvm::StructType * Ty) Line 726C++
3396.  
liblldb.dll!clang::CodeGen::CodeGenTypes::ConvertRecordDeclType(const 
clang::RecordDecl * RD) Line 709C++
3397.  
liblldb.dll!clang::CodeGen::CodeGenTypes::ConvertRecordDeclType(const 
clang::RecordDecl * RD) Line 705C++
3398.  
liblldb.dll!clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType T) Line 
390C++
3399.  
liblldb.dll!clang::CodeGen::CodeGenTypes::ConvertTypeForMem(clang::QualType T) 
Line 88C++
3400.  
liblldb.dll!clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType T) Line 
518C++
3401.  liblldb.dll!`anonymous 
namespace'::X86_64ABIInfo::classifyArgumentType(clang::QualType Ty, unsigned 
int freeIntRegs, unsigned int & neededInt, unsigned int & neededSSE, bool 
isNamedArg) Line 3394C++
3402.  liblldb.dll!`anonymous 
namespace'::X86_64ABIInfo::computeInfo(clang::CodeGen::CGFunctionInfo & FI) 
Line 3591C++
3403.  
liblldb.dll!clang::CodeGen::CodeGenTypes::arrangeLLVMFunctionInfo(clang::CanQual
 resultType, bool instanceMethod, bool chainCall, 
llvm::ArrayRef > argTypes, 
clang::FunctionType::ExtInfo info, 
llvm::ArrayRef paramInfos, 
clang::CodeGen::RequiredArgs required) Line 769C++
3404.  liblldb.dll!arrangeLLVMFunctionInfo(clang::CodeGen::CodeGenTypes & 
CGT, bool instanceMethod, llvm::SmallVectorImpl > & 
prefix, clang::C

Re: [lldb-dev] Stackoverflow crash when evaluating an invalid expression

2019-03-07 Thread Ben Ruthig via lldb-dev
Hey Raphael,

Yes, you did advise me to drop a D->dumpColor() call in to
getASTRecordLayout().  For frustrating reasons I still haven't been able to
capture those logs but when I do I will report back.

Thanks so much for your help and quick response!

Ben

On Thu, Mar 7, 2019 at 12:56 PM Raphael Isemann  wrote:

> Hi Ben,
>
> I think I already answered this last week:
> http://lists.llvm.org/pipermail/lldb-dev/2019-February/014789.html
>
> I don't think you'll get an answer here without posting the
> problematic source or giving any more information as I described in my
> mail.
>
> Cheers,
> - Raphael
>
> Am Do., 7. März 2019 um 18:13 Uhr schrieb Ben Ruthig via lldb-dev
> :
> >
> > Hello all,
> >
> > I am currently investigating an issue where LLDB is crashing due to a
> stack overflow when attempting to evaluate an expression.  I have seen the
> same issue in 6.0.1 and have reproduced it in 7.0.1.  Any help to diagnose
> and fix would be greatly appreciated as I am trying to meet a release
> deadline early next week!
> >
> > The facts:
> > - The expression being evaluated is not a valid expression in the C++
> domain. For example the expression is a datatype like 'Foobar'.  (For
> reasons unexplained I am constrained to supporting this use case.)
> > - The crash occurs when using the C++ LLDB API but not when trying to
> evaluate the expression via the LLDB shell or the LLDB Python script
> shell.  However, when doing 'expr Foobar' there is no output and the
> operation is completely silent.  It is similar when trying to do
> 'lldb.frame.EvaluateExpression("Foobar")' in the Python shell as well.  I
> would expect to get some error output or an SbValue in an error state but
> no such luck.
> > - I was able to capture a stack trace (attached) and it seems to be a
> recursive loop bottoming out.  For brevity two 'loops' of stacktrace are
> included here:
> >
> > 3387.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
> clang::RecordDecl * D) Line 2965C++
> > 3388.  liblldb.dll!`anonymous
> namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
> > 3389.  liblldb.dll!`anonymous
> namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext &
> Context, const clang::CXXRecordDecl * Class) Line 172C++
> > 3390.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
> clang::RecordDecl * D) Line 2965C++
> > 3391.  liblldb.dll!`anonymous
> namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
> > 3392.  liblldb.dll!`anonymous
> namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext &
> Context, const clang::CXXRecordDecl * Class) Line 172C++
> > 3393.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
> clang::RecordDecl * D) Line 2965C++
> >
> > Help please :S
> >
> > Thanks,
> > Ben
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>


-- 
"Sometimes I've believed as many as six impossible things before breakfast"
- Alice in Wonderland
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] Stackoverflow crash when evaluating an invalid expression

2019-03-07 Thread Ben Ruthig via lldb-dev
Ah I see what happened.  My original e-mail was delayed because it was too
large but it was recently accepted by a moderator.

On Thu, Mar 7, 2019 at 1:19 PM Ben Ruthig  wrote:

> Hey Raphael,
>
> Yes, you did advise me to drop a D->dumpColor() call in to
> getASTRecordLayout().  For frustrating reasons I still haven't been able to
> capture those logs but when I do I will report back.
>
> Thanks so much for your help and quick response!
>
> Ben
>
> On Thu, Mar 7, 2019 at 12:56 PM Raphael Isemann 
> wrote:
>
>> Hi Ben,
>>
>> I think I already answered this last week:
>> http://lists.llvm.org/pipermail/lldb-dev/2019-February/014789.html
>>
>> I don't think you'll get an answer here without posting the
>> problematic source or giving any more information as I described in my
>> mail.
>>
>> Cheers,
>> - Raphael
>>
>> Am Do., 7. März 2019 um 18:13 Uhr schrieb Ben Ruthig via lldb-dev
>> :
>> >
>> > Hello all,
>> >
>> > I am currently investigating an issue where LLDB is crashing due to a
>> stack overflow when attempting to evaluate an expression.  I have seen the
>> same issue in 6.0.1 and have reproduced it in 7.0.1.  Any help to diagnose
>> and fix would be greatly appreciated as I am trying to meet a release
>> deadline early next week!
>> >
>> > The facts:
>> > - The expression being evaluated is not a valid expression in the C++
>> domain. For example the expression is a datatype like 'Foobar'.  (For
>> reasons unexplained I am constrained to supporting this use case.)
>> > - The crash occurs when using the C++ LLDB API but not when trying to
>> evaluate the expression via the LLDB shell or the LLDB Python script
>> shell.  However, when doing 'expr Foobar' there is no output and the
>> operation is completely silent.  It is similar when trying to do
>> 'lldb.frame.EvaluateExpression("Foobar")' in the Python shell as well.  I
>> would expect to get some error output or an SbValue in an error state but
>> no such luck.
>> > - I was able to capture a stack trace (attached) and it seems to be a
>> recursive loop bottoming out.  For brevity two 'loops' of stacktrace are
>> included here:
>> >
>> > 3387.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
>> clang::RecordDecl * D) Line 2965C++
>> > 3388.  liblldb.dll!`anonymous
>> namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
>> > 3389.  liblldb.dll!`anonymous
>> namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext &
>> Context, const clang::CXXRecordDecl * Class) Line 172C++
>> > 3390.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
>> clang::RecordDecl * D) Line 2965C++
>> > 3391.  liblldb.dll!`anonymous
>> namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
>> > 3392.  liblldb.dll!`anonymous
>> namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext &
>> Context, const clang::CXXRecordDecl * Class) Line 172C++
>> > 3393.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
>> clang::RecordDecl * D) Line 2965C++
>> >
>> > Help please :S
>> >
>> > Thanks,
>> > Ben
>> >
>> >
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
>
> --
> "Sometimes I've believed as many as six impossible things before
> breakfast" - Alice in Wonderland
>


-- 
"Sometimes I've believed as many as six impossible things before breakfast"
- Alice in Wonderland
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev