Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

2017-01-20 Thread Jim Ingham via lldb-dev 
All the lldb.llvm.org web pages are taken from the www directory in the 
sources.  So just change it there and the web page will get updated.

The one you want is lldb-gdb.html.

Jim

> On Jan 20, 2017, at 4:44 PM, Eugene Birukov  wrote:
> 
> Sorry, never done that - where this HTML is located and what is the procedure 
> of updating it?
> 
> Sent from Outlook
> 
> 
> From: jing...@apple.com  on behalf of Jim Ingham 
> 
> Sent: Friday, January 20, 2017 4:35 PM
> To: Ted Woodward
> Cc: Eugene Birukov; Pavel Labath; LLDB; rd...@microsoft.com
> Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
>  
> If that works, can you add it to the lldb-gdb.html document?
> 
> Jim
> 
> > On Jan 20, 2017, at 3:57 PM, Ted Woodward via lldb-dev 
> >  wrote:
> > 
> > Try “image search-paths add” as a replacement for “set solib-search-path”
> >  
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> > Linux Foundation Collaborative Project
> >  
> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eugene 
> > Birukov via lldb-dev
> > Sent: Friday, January 20, 2017 12:35 PM
> > To: Pavel Labath 
> > Cc: rd...@microsoft.com; LLDB 
> > Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
> >  
> > Hello Pavel,
> >  
> > Thanks for the reply. Unfortunately I cannot share the core dump with you.
> >  
> > Yes, Rob has figured that LLDB does not find this shared library and that 
> > causes the problem. To understand what is going on here, I need to add one 
> > more detail that was missing from my original post: this is a cross-machine 
> > investigation. I.e. the core dump collected on one machine (CentOs) was 
> > sent to another
> > (Ubuntu) where I tried to open it.
> >  
> > LLDB opens the executable without paying attention that there is a core 
> > dump attached and tries to locate shared libraries. Apparently the ones 
> > that exist on my machine are not good, so it then looks in the directory 
> > with the executable itself. There is no way to "set solib-search-path" as 
> > we do on GDB and force it to look somewhere else. After we dumped all the 
> > shared libraries in the folder with the executable LLDB was able to open 
> > the dump. This is a bit inconvenient, but works as a workaround for now.
> >  
> > Sent from Outlook
> >  
> > 
> > From: Pavel Labath 
> > Sent: Friday, January 20, 2017 6:55 AM
> > To: Eugene Birukov
> > Cc: LLDB; rd...@microsoft.com
> > Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
> >  
> > Hello Eugene,
> > 
> > I have been aware of this problem for a while, but I haven't found a
> > really good solution so far, partially due to lack of a good repro
> > case -- I think your analysis has helped me with this, and I am
> > finally starting to piece together the sequence of events leading to
> > the crash. If you have a repro case you can send me, it would be even
> > better.
> > 
> > I don't really have an answer to your quesiton, but here are a couple
> > of observations (the details might be a bit sketchy - it's been a long
> > time since I looked at this):
> > - reading the section headers from memory should be a fallback.
> > Normally we try first to locate the file on disk and read data from
> > there. This was mainly added for the vdso "module", as that is not
> > really present on disk. One of the ways of fixing this crash could be
> > to figure out why we are not finding the c++abi binary on disk.
> > 
> > - we trust far too much the data we read from inferior memory. We
> > should be much more careful when doing things based on "untrusted"
> > data. Checking the memory maps as you suggest could be one idea.
> > Another option I am considering is teaching ReadMemory to allocate
> > data in (reasonably sized, say a couple of MB) chunks. Right now it
> > allocates the full buffer without even trying to read the memory. If
> > it instead tried to read data in smaller chunks it would error out due
> > to failure to read inferior memory long before it gets a chance to
> > exhaust own address space. (With a sufficiently large chunk, this
> > should not affect performance of normal reads).
> > 
> > hope that helps,
> > pl
> > 
> > 
> > 
> > On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev
> >  wrote:
> > > Hi,
> > >
> > >
> > > I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would
> > > greatly appreciate any advise how to deal with the problem or what else I
> > > should look at.
> > >
> > >
> > > The core dump was produced by GDB and GDB itself opens it without 
> > > problems.
> > >
> > >
> > > So, during loading the core we call
> > > DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
> > > modules and does some processing. In the course of actions, it calls the
> > > ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to
> > > load section headers and read string table.

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

2017-01-20 Thread Eugene Birukov via lldb-dev 
Sorry, never done that - where this HTML is located and what is the procedure 
of updating it?


Sent from Outlook



From: jing...@apple.com  on behalf of Jim Ingham 

Sent: Friday, January 20, 2017 4:35 PM
To: Ted Woodward
Cc: Eugene Birukov; Pavel Labath; LLDB; rd...@microsoft.com
Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

If that works, can you add it to the lldb-gdb.html document?

Jim

> On Jan 20, 2017, at 3:57 PM, Ted Woodward via lldb-dev 
>  wrote:
>
> Try “image search-paths add” as a replacement for “set solib-search-path”
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eugene 
> Birukov via lldb-dev
> Sent: Friday, January 20, 2017 12:35 PM
> To: Pavel Labath 
> Cc: rd...@microsoft.com; LLDB 
> Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
>
> Hello Pavel,
>
> Thanks for the reply. Unfortunately I cannot share the core dump with you.
>
> Yes, Rob has figured that LLDB does not find this shared library and that 
> causes the problem. To understand what is going on here, I need to add one 
> more detail that was missing from my original post: this is a cross-machine 
> investigation. I.e. the core dump collected on one machine (CentOs) was sent 
> to another
> (Ubuntu) where I tried to open it.
>
> LLDB opens the executable without paying attention that there is a core dump 
> attached and tries to locate shared libraries. Apparently the ones that exist 
> on my machine are not good, so it then looks in the directory with the 
> executable itself. There is no way to "set solib-search-path" as we do on GDB 
> and force it to look somewhere else. After we dumped all the shared libraries 
> in the folder with the executable LLDB was able to open the dump. This is a 
> bit inconvenient, but works as a workaround for now.
>
> Sent from Outlook
>
>
> From: Pavel Labath 
> Sent: Friday, January 20, 2017 6:55 AM
> To: Eugene Birukov
> Cc: LLDB; rd...@microsoft.com
> Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
>
> Hello Eugene,
>
> I have been aware of this problem for a while, but I haven't found a
> really good solution so far, partially due to lack of a good repro
> case -- I think your analysis has helped me with this, and I am
> finally starting to piece together the sequence of events leading to
> the crash. If you have a repro case you can send me, it would be even
> better.
>
> I don't really have an answer to your quesiton, but here are a couple
> of observations (the details might be a bit sketchy - it's been a long
> time since I looked at this):
> - reading the section headers from memory should be a fallback.
> Normally we try first to locate the file on disk and read data from
> there. This was mainly added for the vdso "module", as that is not
> really present on disk. One of the ways of fixing this crash could be
> to figure out why we are not finding the c++abi binary on disk.
>
> - we trust far too much the data we read from inferior memory. We
> should be much more careful when doing things based on "untrusted"
> data. Checking the memory maps as you suggest could be one idea.
> Another option I am considering is teaching ReadMemory to allocate
> data in (reasonably sized, say a couple of MB) chunks. Right now it
> allocates the full buffer without even trying to read the memory. If
> it instead tried to read data in smaller chunks it would error out due
> to failure to read inferior memory long before it gets a chance to
> exhaust own address space. (With a sufficiently large chunk, this
> should not affect performance of normal reads).
>
> hope that helps,
> pl
>
>
>
> On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev
>  wrote:
> > Hi,
> >
> >
> > I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would
> > greatly appreciate any advise how to deal with the problem or what else I
> > should look at.
> >
> >
> > The core dump was produced by GDB and GDB itself opens it without problems.
> >
> >
> > So, during loading the core we call
> > DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
> > modules and does some processing. In the course of actions, it calls the
> > ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to
> > load section headers and read string table. Well, it gets some garbage in
> > the section header struct and tries to allocate 1.5TB memory which causes
> > operator new throw.
> >
> >
> > So, why we get garbage?
> >
> >
> > The module in question is libc++abi.so.1:
> >
> >
> > 521 ModuleSP module_sp = LoadModuleAtAddress(I->file_spec,
> > I->link_addr, I->base_addr, true);
> >
> > (gdb) p I->file_spec
> >
> > $95 = {
> >
> >   m_directory = {
> >
> > m_string = 0x829

[lldb-dev] ELF header does not hold big modules

2017-01-20 Thread Eugene Birukov via lldb-dev 
Hello,


I have a core dump that LLDB cannot open because it contains more than 64K 
sections. The "readelf" utility gives me the output in the end of this message. 
It seems that the actual number of program headers and the index of string 
table section are written into very first section since they do not fit in 16 
bits.


The "natural" way to deal with this problem would be to change the types of 
fields in ELFHeader struct from 16 to 32 bits (or should I go all the way and  
do it 64? in case the core dump is bigger than 4GB...) and deal with the 
problem in a single place where we parse the header - the ELFHeader::Parse().


Objections? Suggestions? Advices?


Hmm... I am not sure that the DataExtractor we pass down there would let me 
read that much past in the file - I have impression that we give only first 512 
bytes there, but I might be mistaken...


Thanks,

Eugene


ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  CORE (Core file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x0
  Start of program headers:  64 (bytes into file)
  Start of section headers:  16880770624 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 65535 (106714)
  Size of section headers:   64 (bytes)
  Number of section headers: 0 (106716)
  Section header string table index: 65535 (106715)

Section Headers:
  [Nr] Name  Type Address   Offset
   Size  EntSize  Flags  Link  Info  Align
  [ 0]   NULL   
   0001a0dc    106715   106714 0
  [ 1] note0 NOTE   005b2ff0
   000b2e38     A   0 0 1
  [ 2] load  PROGBITS 6a40  00665e28
   1000     A   0 0 1
  [ 3] load  PROGBITS 6a401000  00666e28






Sent from Outlook
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

2017-01-20 Thread Jim Ingham via lldb-dev 
If that works, can you add it to the lldb-gdb.html document?

Jim

> On Jan 20, 2017, at 3:57 PM, Ted Woodward via lldb-dev 
>  wrote:
> 
> Try “image search-paths add” as a replacement for “set solib-search-path”
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eugene 
> Birukov via lldb-dev
> Sent: Friday, January 20, 2017 12:35 PM
> To: Pavel Labath 
> Cc: rd...@microsoft.com; LLDB 
> Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
>  
> Hello Pavel,
>  
> Thanks for the reply. Unfortunately I cannot share the core dump with you.
>  
> Yes, Rob has figured that LLDB does not find this shared library and that 
> causes the problem. To understand what is going on here, I need to add one 
> more detail that was missing from my original post: this is a cross-machine 
> investigation. I.e. the core dump collected on one machine (CentOs) was sent 
> to another
> (Ubuntu) where I tried to open it.
>  
> LLDB opens the executable without paying attention that there is a core dump 
> attached and tries to locate shared libraries. Apparently the ones that exist 
> on my machine are not good, so it then looks in the directory with the 
> executable itself. There is no way to "set solib-search-path" as we do on GDB 
> and force it to look somewhere else. After we dumped all the shared libraries 
> in the folder with the executable LLDB was able to open the dump. This is a 
> bit inconvenient, but works as a workaround for now.
>  
> Sent from Outlook
>  
> 
> From: Pavel Labath 
> Sent: Friday, January 20, 2017 6:55 AM
> To: Eugene Birukov
> Cc: LLDB; rd...@microsoft.com
> Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
>  
> Hello Eugene,
> 
> I have been aware of this problem for a while, but I haven't found a
> really good solution so far, partially due to lack of a good repro
> case -- I think your analysis has helped me with this, and I am
> finally starting to piece together the sequence of events leading to
> the crash. If you have a repro case you can send me, it would be even
> better.
> 
> I don't really have an answer to your quesiton, but here are a couple
> of observations (the details might be a bit sketchy - it's been a long
> time since I looked at this):
> - reading the section headers from memory should be a fallback.
> Normally we try first to locate the file on disk and read data from
> there. This was mainly added for the vdso "module", as that is not
> really present on disk. One of the ways of fixing this crash could be
> to figure out why we are not finding the c++abi binary on disk.
> 
> - we trust far too much the data we read from inferior memory. We
> should be much more careful when doing things based on "untrusted"
> data. Checking the memory maps as you suggest could be one idea.
> Another option I am considering is teaching ReadMemory to allocate
> data in (reasonably sized, say a couple of MB) chunks. Right now it
> allocates the full buffer without even trying to read the memory. If
> it instead tried to read data in smaller chunks it would error out due
> to failure to read inferior memory long before it gets a chance to
> exhaust own address space. (With a sufficiently large chunk, this
> should not affect performance of normal reads).
> 
> hope that helps,
> pl
> 
> 
> 
> On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev
>  wrote:
> > Hi,
> >
> >
> > I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would
> > greatly appreciate any advise how to deal with the problem or what else I
> > should look at.
> >
> >
> > The core dump was produced by GDB and GDB itself opens it without problems.
> >
> >
> > So, during loading the core we call
> > DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
> > modules and does some processing. In the course of actions, it calls the
> > ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to
> > load section headers and read string table. Well, it gets some garbage in
> > the section header struct and tries to allocate 1.5TB memory which causes
> > operator new throw.
> >
> >
> > So, why we get garbage?
> >
> >
> > The module in question is libc++abi.so.1:
> >
> >
> > 521 ModuleSP module_sp = LoadModuleAtAddress(I->file_spec,
> > I->link_addr, I->base_addr, true);
> >
> > (gdb) p I->file_spec
> >
> > $95 = {
> >
> >   m_directory = {
> >
> > m_string = 0x829a58 "... redacted ..."
> >
> >   },
> >
> >   m_filename = {
> >
> > m_string = 0x7cc9e8 "libc++abi.so.1"
> >
> >   },
> >
> >   m_is_resolved = false,
> >
> >   m_syntax = lldb_private::FileSpec::ePathSyntaxPosix
> >
> > }
> >
> >
> > The module header lives at address 0x7f699a27  and looks OK. The section
> > headers are supposed to be at offset 2495600 == 0x261470
> >
> >
> >

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

2017-01-20 Thread Ted Woodward via lldb-dev 
Try "image search-paths add" as a replacement for "set solib-search-path"

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eugene
Birukov via lldb-dev
Sent: Friday, January 20, 2017 12:35 PM
To: Pavel Labath 
Cc: rd...@microsoft.com; LLDB 
Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

 

Hello Pavel,

 

Thanks for the reply. Unfortunately I cannot share the core dump with you.

 

Yes, Rob has figured that LLDB does not find this shared library and that
causes the problem. To understand what is going on here, I need to add one
more detail that was missing from my original post: this is a cross-machine
investigation. I.e. the core dump collected on one machine (CentOs) was sent
to another

(Ubuntu) where I tried to open it.

 

LLDB opens the executable without paying attention that there is a core dump
attached and tries to locate shared libraries. Apparently the ones that
exist on my machine are not good, so it then looks in the directory with the
executable itself. There is no way to "set solib-search-path" as we do on
GDB and force it to look somewhere else. After we dumped all the shared
libraries in the folder with the executable LLDB was able to open the dump.
This is a bit inconvenient, but works as a workaround for now.

 

Sent from Outlook  

 

  _  

From: Pavel Labath mailto:lab...@google.com> >
Sent: Friday, January 20, 2017 6:55 AM
To: Eugene Birukov
Cc: LLDB; rd...@microsoft.com  
Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump 

 

Hello Eugene,

I have been aware of this problem for a while, but I haven't found a
really good solution so far, partially due to lack of a good repro
case -- I think your analysis has helped me with this, and I am
finally starting to piece together the sequence of events leading to
the crash. If you have a repro case you can send me, it would be even
better.

I don't really have an answer to your quesiton, but here are a couple
of observations (the details might be a bit sketchy - it's been a long
time since I looked at this):
- reading the section headers from memory should be a fallback.
Normally we try first to locate the file on disk and read data from
there. This was mainly added for the vdso "module", as that is not
really present on disk. One of the ways of fixing this crash could be
to figure out why we are not finding the c++abi binary on disk.

- we trust far too much the data we read from inferior memory. We
should be much more careful when doing things based on "untrusted"
data. Checking the memory maps as you suggest could be one idea.
Another option I am considering is teaching ReadMemory to allocate
data in (reasonably sized, say a couple of MB) chunks. Right now it
allocates the full buffer without even trying to read the memory. If
it instead tried to read data in smaller chunks it would error out due
to failure to read inferior memory long before it gets a chance to
exhaust own address space. (With a sufficiently large chunk, this
should not affect performance of normal reads).

hope that helps,
pl



On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev
mailto:lldb-dev@lists.llvm.org> > wrote:
> Hi,
>
>
> I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would
> greatly appreciate any advise how to deal with the problem or what else I
> should look at.
>
>
> The core dump was produced by GDB and GDB itself opens it without
problems.
>
>
> So, during loading the core we call
> DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
> modules and does some processing. In the course of actions, it calls the
> ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to
> load section headers and read string table. Well, it gets some garbage in
> the section header struct and tries to allocate 1.5TB memory which causes
> operator new throw.
>
>
> So, why we get garbage?
>
>
> The module in question is libc++abi.so.1:
>
>
> 521 ModuleSP module_sp = LoadModuleAtAddress(I->file_spec,
> I->link_addr, I->base_addr, true);
>
> (gdb) p I->file_spec
>
> $95 = {
>
>   m_directory = {
>
> m_string = 0x829a58 "... redacted ..."
>
>   },
>
>   m_filename = {
>
> m_string = 0x7cc9e8 "libc++abi.so.1"
>
>   },
>
>   m_is_resolved = false,
>
>   m_syntax = lldb_private::FileSpec::ePathSyntaxPosix
>
> }
>
>
> The module header lives at address 0x7f699a27  and looks OK. The
section
> headers are supposed to be at offset 2495600 == 0x261470
>
>
> $96 = (const elf::ELFHeader &) @0x953a78: {
>
>   e_ident = "\177ELF\002\001\001\000\000\000\000\000\000\000\000",
>
>   e_entry = 33392,
>
>   e_phoff = 64,
>
>   e_shoff = 2495600,
>
>   e_flags = 0,
>
>   e_version = 1,
>
>   e_type = 3,
>
>   e_machine = 62,
>
>   e

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Relase Candidate 1 has been tagged

2017-01-20 Thread Bernhard Rosenkränzer via lldb-dev 
Hi,
updated OpenMandriva packaging. Looks good, so far passes testing on all 4
supported arches (x86_32, x86_64, armv7hnl, aarch64) after fixing one build
issue in clang-tools-extra:

FAILED: lib64/libclangIncludeFixerPlugin.so.4.0.0
: && /usr/bin/clang++  -fPIC -Os  -pipe -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4  -fPIC
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dt
or -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time
-std=c++1y -fcolor-diagnostics -ffunction-sections -fdata-sections
-fno-common -Woverloaded-virtual -Wno-nested-anon-types -Os  -pipe -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4  -fPIC  -L/home/bero/abf/llvm/BUIL
D/llvm-4.0.0.src/build/lib64 -Wl,-z,defs   -Wl,-O3 -Wl,--gc-sections
-shared -Wl,-soname,libclangIncludeFixerPlugin.so.4.0 -o
lib64/libclangIncludeFixerPlugin.so.4.0.0
tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o
 lib64/libclangAST.so.4.0.0 lib64/libclangBasic.so.4.0.
0 lib64/libclangFrontend.so.4.0.0 lib64/libclangIncludeFixer.so.4.0.0
lib64/libclangParse.so.4.0.0 lib64/libclangSema.so.4.0.0
lib64/libclangTooling.so.4.0.0 lib64/libLLVMSupport.so.4.0.0 && :
tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:/home/bero/abf/llvm/BUILD/llvm-4.0.0.src/tools/clang/tools/extra/include-fixer/plugin/IncludeFixerPlugin.cpp:function
std::thread::thread > ()> ()>,
std::unique_ptr >
>::_Async_state_impl(std::_Bind_simple > ()>
()>&&)::{lambda()#1}>(std::__future_base::_Async_state_impl > ()> ()>,
std::unique_ptr >
>::_Async_state_impl(std::_Bind_simple > ()>
()>&&)::{lambda()#1}&&): error: undefined reference to 'pthread_create'
clang-4.0: error: linker command failed with exit code 1 (use -v to see
invocation)
ninja: build stopped: subcommand failed.

Patch for this issue is attached (but will likely break Windows builds -
probably needs a platform check added).

ttyl
bero

On 18 January 2017 at 16:45, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Dear testers,
>
> 4.0.0-rc1 was just tagged from the branch, with r292377.
>
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.
>
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the web site
> once their ready.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
--- llvm-4.0.0.src/tools/clang/tools/extra/include-fixer/plugin/CMakeLists.txt.omv~	2017-01-20 23:06:35.674775076 +0100
+++ llvm-4.0.0.src/tools/clang/tools/extra/include-fixer/plugin/CMakeLists.txt	2017-01-20 23:06:42.010838914 +0100
@@ -9,4 +9,5 @@ add_clang_library(clangIncludeFixerPlugi
   clangParse
   clangSema
   clangTooling
+  pthread
   )
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

2017-01-20 Thread Eugene Birukov via lldb-dev 
Hello Pavel,


Thanks for the reply. Unfortunately I cannot share the core dump with you.


Yes, Rob has figured that LLDB does not find this shared library and that 
causes the problem. To understand what is going on here, I need to add one more 
detail that was missing from my original post: this is a cross-machine 
investigation. I.e. the core dump collected on one machine (CentOs) was sent to 
another

(Ubuntu) where I tried to open it.


LLDB opens the executable without paying attention that there is a core dump 
attached and tries to locate shared libraries. Apparently the ones that exist 
on my machine are not good, so it then looks in the directory with the 
executable itself. There is no way to "set solib-search-path" as we do on GDB 
and force it to look somewhere else. After we dumped all the shared libraries 
in the folder with the executable LLDB was able to open the dump. This is a bit 
inconvenient, but works as a workaround for now.


Sent from Outlook



From: Pavel Labath 
Sent: Friday, January 20, 2017 6:55 AM
To: Eugene Birukov
Cc: LLDB; rd...@microsoft.com
Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

Hello Eugene,

I have been aware of this problem for a while, but I haven't found a
really good solution so far, partially due to lack of a good repro
case -- I think your analysis has helped me with this, and I am
finally starting to piece together the sequence of events leading to
the crash. If you have a repro case you can send me, it would be even
better.

I don't really have an answer to your quesiton, but here are a couple
of observations (the details might be a bit sketchy - it's been a long
time since I looked at this):
- reading the section headers from memory should be a fallback.
Normally we try first to locate the file on disk and read data from
there. This was mainly added for the vdso "module", as that is not
really present on disk. One of the ways of fixing this crash could be
to figure out why we are not finding the c++abi binary on disk.

- we trust far too much the data we read from inferior memory. We
should be much more careful when doing things based on "untrusted"
data. Checking the memory maps as you suggest could be one idea.
Another option I am considering is teaching ReadMemory to allocate
data in (reasonably sized, say a couple of MB) chunks. Right now it
allocates the full buffer without even trying to read the memory. If
it instead tried to read data in smaller chunks it would error out due
to failure to read inferior memory long before it gets a chance to
exhaust own address space. (With a sufficiently large chunk, this
should not affect performance of normal reads).

hope that helps,
pl



On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev
 wrote:
> Hi,
>
>
> I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would
> greatly appreciate any advise how to deal with the problem or what else I
> should look at.
>
>
> The core dump was produced by GDB and GDB itself opens it without problems.
>
>
> So, during loading the core we call
> DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
> modules and does some processing. In the course of actions, it calls the
> ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to
> load section headers and read string table. Well, it gets some garbage in
> the section header struct and tries to allocate 1.5TB memory which causes
> operator new throw.
>
>
> So, why we get garbage?
>
>
> The module in question is libc++abi.so.1:
>
>
> 521 ModuleSP module_sp = LoadModuleAtAddress(I->file_spec,
> I->link_addr, I->base_addr, true);
>
> (gdb) p I->file_spec
>
> $95 = {
>
>   m_directory = {
>
> m_string = 0x829a58 "... redacted ..."
>
>   },
>
>   m_filename = {
>
> m_string = 0x7cc9e8 "libc++abi.so.1"
>
>   },
>
>   m_is_resolved = false,
>
>   m_syntax = lldb_private::FileSpec::ePathSyntaxPosix
>
> }
>
>
> The module header lives at address 0x7f699a27  and looks OK. The section
> headers are supposed to be at offset 2495600 == 0x261470
>
>
> $96 = (const elf::ELFHeader &) @0x953a78: {
>
>   e_ident = "\177ELF\002\001\001\000\000\000\000\000\000\000\000",
>
>   e_entry = 33392,
>
>   e_phoff = 64,
>
>   e_shoff = 2495600,
>
>   e_flags = 0,
>
>   e_version = 1,
>
>   e_type = 3,
>
>   e_machine = 62,
>
>   e_ehsize = 64,
>
>   e_phentsize = 56,
>
>   e_phnum = 7,
>
>   e_shentsize = 64,
>
>   e_shnum = 38,
>
>   e_shstrndx = 35
>
> }
>
>
> LLDB tries to read the section headers from that address 0x7f699a27  +
> 0x261470 == 0x7F699A4D1470 without a second thought, but this number is a
> lie. The /proc//maps file shows it as belonging to something else:
>
>
> 7f699a27-7f699a2ba000 r-xp  fd:02 537796791
> .../libc++abi.so.1
> 7f699a2ba000-7f699a4b9000 ---p 0004a000 fd:02 537796791
> .../libc++abi.so.1
> 7f699a4b9000-7f699a4bb000 r--p 00049000 fd:02 5377

[lldb-dev] [Bug 31707] New: Settings breakpoints using absolute file path that contains symlinks does not work

2017-01-20 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=31707

Bug ID: 31707
   Summary: Settings breakpoints using absolute file path that
contains symlinks does not work
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: alexandru.croi...@qt.io
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Consider I have a C++ file at: /Users/alex/Dev/project/main.cpp

and I compiled the file there with:

clang++ -g -O0 ./main.cpp

Now if I try to set a breakpoint with:

br set -f /Users/alex/Dev/project/main.cpp -l 10

the breakpoint will work.
But if I try to set a breakpoint with:

br set -f /Volumes/Macintosh\ HD/Users/alex/Dev/project/main.cpp -l 10

the breakpoint will not work, because it differs from the DWARF written
filepath.

Machintosh HD is a symlink to /

$ ls -al /Volumes/
lrwxr-xr-x   1 root  admin  1 Dec 23 07:40 Macintosh HD -> /

Should lldb maybe consider using the canonical path to a given file, when
setting a breakpoint?


(lldb) version
lldb-360.99.0
  clang revision a41b64721d4be78870711cbb7b5af156a9e1f4ad
  llvm revision 3c45ea423a9e3d27eaf77af0639a73e0c56d9a35

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 31706] New: SBTarget::FindTypes does not find resolved function pointer types

2017-01-20 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=31706

Bug ID: 31706
   Summary: SBTarget::FindTypes does not find resolved function
pointer types
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: alexandru.croi...@qt.io
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 17872
  --> https://llvm.org/bugs/attachment.cgi?id=17872&action=edit
Example code which shows the issue regarding FindTypes

SBTarget::FindTypes does not find resolved function pointer types, which were
declared as function pointer typedefs.

Consider the code:

typedef struct _type {
  int value;
} MyType;
typedef void (*FunctionPointer)(MyType*);

void function(MyType* t) {
(void) t;
}

int main(int argc, char* argv[]) {
MyType t;
FunctionPointer fp = &function;
fp(&t);
return 0;
}

Compile with clang++ -O0 -g ./main.cpp
Run lldb ./a.out and go into python script mode, then:

>>> lldb.target.FindTypes("FunctionPointer").GetSize()
1

>>> lldb.target.FindTypes("void (*)(MyType*)").GetSize()
0


>>> lldb.target.FindTypes("void (*)(MyType *)").GetSize()
0

But if I do:
>>> for t in lldb.target.GetModuleAtIndex(0).GetTypes():
...   print t.GetName()

I get:

FunctionPointer
void (*)(MyType *)
MyType *
MyType
_type
void (MyType *)
main
char **
char *
char
int

which obviously contains "void (*)(MyType *)" which I have searched for
previously.

dwardump-ing the executable dSYM I can see DWARF data for the typedef, but not
for the underlying type of the typedef.

Is this a bug? Should FindTypes find resolved typedefs? Or is this intended
behavior?

(lldb) version
lldb-360.99.0
  clang revision a41b64721d4be78870711cbb7b5af156a9e1f4ad
  llvm revision 3c45ea423a9e3d27eaf77af0639a73e0c56d9a35

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 31704] New: SBModule::FindFirstType does not find a second namespaced typedef with the same name

2017-01-20 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=31704

Bug ID: 31704
   Summary: SBModule::FindFirstType does not find a second
namespaced typedef with the same name
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: alexandru.croi...@qt.io
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 17871
  --> https://llvm.org/bugs/attachment.cgi?id=17871&action=edit
Example code which shows the issue regarding FindFirstType

SBModule::FindFirstType has an issue with finding namespaced typedefs.
Consider the code:

class Foo {
public:
typedef bool MyType;
};

class Bar {
public:
typedef int MyType;
};

int main(int argc, char* argv[]) {
Foo::MyType foo;
Bar::MyType bar;
(void) foo;
(void) bar;
return 0;
}

Compile with clang++ -O0 -g ./main.cpp
Run with lldb ./a.out and go into python script mode

>>> lldb.target.FindTypes("MyType").GetSize()
2


>>> print lldb.target.FindFirstType("MyType")
typedef Foo::MyType

>>> print lldb.target.FindFirstType("Foo::MyType")
typedef Foo::MyType

>>> print lldb.target.FindFirstType("Bar::MyType")

As you can see, trying to find Bar::MyType fails, but if I iterate over
FindTypes result, I can find both.

(lldb) version
lldb-360.99.0
  clang revision a41b64721d4be78870711cbb7b5af156a9e1f4ad
  llvm revision 3c45ea423a9e3d27eaf77af0639a73e0c56d9a35

The issue seems to be inside lldb::TypeSP Module::FindFirstType(const
SymbolContext &sc, const ConstString &name, bool exact_match)
which passes "1" as the max_matches argument, and this gets propagated in a
wrong way inside the implementation, where essentially a list of the two types
is found, and the second type is not checked because the first type didn't
match.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

2017-01-20 Thread Pavel Labath via lldb-dev 
Hello Eugene,

I have been aware of this problem for a while, but I haven't found a
really good solution so far, partially due to lack of a good repro
case -- I think your analysis has helped me with this, and I am
finally starting to piece together the sequence of events leading to
the crash. If you have a repro case you can send me, it would be even
better.

I don't really have an answer to your quesiton, but here are a couple
of observations (the details might be a bit sketchy - it's been a long
time since I looked at this):
- reading the section headers from memory should be a fallback.
Normally we try first to locate the file on disk and read data from
there. This was mainly added for the vdso "module", as that is not
really present on disk. One of the ways of fixing this crash could be
to figure out why we are not finding the c++abi binary on disk.

- we trust far too much the data we read from inferior memory. We
should be much more careful when doing things based on "untrusted"
data. Checking the memory maps as you suggest could be one idea.
Another option I am considering is teaching ReadMemory to allocate
data in (reasonably sized, say a couple of MB) chunks. Right now it
allocates the full buffer without even trying to read the memory. If
it instead tried to read data in smaller chunks it would error out due
to failure to read inferior memory long before it gets a chance to
exhaust own address space. (With a sufficiently large chunk, this
should not affect performance of normal reads).

hope that helps,
pl



On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev
 wrote:
> Hi,
>
>
> I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would
> greatly appreciate any advise how to deal with the problem or what else I
> should look at.
>
>
> The core dump was produced by GDB and GDB itself opens it without problems.
>
>
> So, during loading the core we call
> DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
> modules and does some processing. In the course of actions, it calls the
> ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to
> load section headers and read string table. Well, it gets some garbage in
> the section header struct and tries to allocate 1.5TB memory which causes
> operator new throw.
>
>
> So, why we get garbage?
>
>
> The module in question is libc++abi.so.1:
>
>
> 521 ModuleSP module_sp = LoadModuleAtAddress(I->file_spec,
> I->link_addr, I->base_addr, true);
>
> (gdb) p I->file_spec
>
> $95 = {
>
>   m_directory = {
>
> m_string = 0x829a58 "... redacted ..."
>
>   },
>
>   m_filename = {
>
> m_string = 0x7cc9e8 "libc++abi.so.1"
>
>   },
>
>   m_is_resolved = false,
>
>   m_syntax = lldb_private::FileSpec::ePathSyntaxPosix
>
> }
>
>
> The module header lives at address 0x7f699a27  and looks OK. The section
> headers are supposed to be at offset 2495600 == 0x261470
>
>
> $96 = (const elf::ELFHeader &) @0x953a78: {
>
>   e_ident = "\177ELF\002\001\001\000\000\000\000\000\000\000\000",
>
>   e_entry = 33392,
>
>   e_phoff = 64,
>
>   e_shoff = 2495600,
>
>   e_flags = 0,
>
>   e_version = 1,
>
>   e_type = 3,
>
>   e_machine = 62,
>
>   e_ehsize = 64,
>
>   e_phentsize = 56,
>
>   e_phnum = 7,
>
>   e_shentsize = 64,
>
>   e_shnum = 38,
>
>   e_shstrndx = 35
>
> }
>
>
> LLDB tries to read the section headers from that address 0x7f699a27  +
> 0x261470 == 0x7F699A4D1470 without a second thought, but this number is a
> lie. The /proc//maps file shows it as belonging to something else:
>
>
> 7f699a27-7f699a2ba000 r-xp  fd:02 537796791
> .../libc++abi.so.1
> 7f699a2ba000-7f699a4b9000 ---p 0004a000 fd:02 537796791
> .../libc++abi.so.1
> 7f699a4b9000-7f699a4bb000 r--p 00049000 fd:02 537796791
> .../libc++abi.so.1
> 7f699a4bb000-7f699a4bc000 rw-p 0004b000 fd:02 537796791
> .../libc++abi.so.1
> 7f699a4bc000-7f699a52 r-xp  fd:00 202587414
> /usr/lib64/libssl.so.1.0.1e
> 7f699a52-7f699a71f000 ---p 00064000 fd:00 202587414
> /usr/lib64/libssl.so.1.0.1e
> 7f699a71f000-7f699a723000 r--p 00063000 fd:00 202587414
> /usr/lib64/libssl.so.1.0.1e
> 7f699a723000-7f699a72a000 rw-p 00067000 fd:00 202587414
> /usr/lib64/libssl.so.1.0.1e
>
> I.e. LLDB should verify the module boundaries and fall back to some other
> plan if the memory is not there.
>
>
> Now the question is - where would be the right place to do the fix?
>
>
> Thanks,
>
> Eugene
>
>
>
>
>
>
>
>
> Sent from Outlook
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

2017-01-20 Thread Mehdi Amini via lldb-dev 
Hi,

FYI, I added a Green dragon job to build and test (stage 1 only right now) the 
release branch: 
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA-release-4/ 


— 
Mehdi

> On Jan 18, 2017, at 7:45 AM, Hans Wennborg via llvm-dev 
>  wrote:
> 
> Dear testers,
> 
> 4.0.0-rc1 was just tagged from the branch, with r292377.
> 
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.
> 
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the web site
> once their ready.
> 
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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