Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

[Eugene Birukov via lldb-dev]

I believe using search path is not the right approach when opening a core dump. 
We do not need to search for modules: we know exactly what has been loaded from 
where when the application crashed. The only problem is that the machine was 
different, so we need to prepend sysroot and get them form there. Scanning 
search path chain and grabbing arbitrary files that happen to have matching 
name would confuse the debugger.

If nobody objects, I'll prepare this change in phabricator.

-Original Message-
From: Pavel Labath  
Sent: Monday, July 23, 2018 2:42 AM
To: Eugene Birukov 
Cc: LLDB 
Subject: Re: [lldb-dev] LLDB does not respect platform sysroot when loading 
core on Linux

Instead of "image search-paths add" you should be able to do a "settings append 
target.exec-search-paths /your/sysroot". That one should not require a running 
target or anything like that.

However, I agree that it would be nice for the platform sysroot to work out of 
the box. Particularly, as we can then use it to do other nice things (e.g. 
prevent matching of files in the main filesystem, so we can avoid the 
ld-linux-x86-64.so.2 problem you encountered).

For the patch, can you create a review on the LLVM phabricator 
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2Fdifferentialdata=02%7C01%7Ceugenebi%40microsoft.com%7Cccc0730e45e54303889a08d5f0809ff9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636679357598185483sdata=65R5UyPEArGn2q27sklUPc8bUEAOjPK2OBi91SMVuzM%3Dreserved=0>?
 We can discuss the approach there.

On Fri, 20 Jul 2018 at 23:55, Eugene Birukov via lldb-dev 
 wrote:
>
> I have a small fix – pass platform sysroot to ModuleList::GetSharedModule. 
> The fix works for me.
>
>
>
> What should I do to get it reviewed?
>
>
>
> Thanks,
>
> Eugene
>
>
>
> diff --git a/include/lldb/Core/ModuleList.h 
> b/include/lldb/Core/ModuleList.h
>
> index 4b637c9..3214291 100644
>
> --- a/include/lldb/Core/ModuleList.h
>
> +++ b/include/lldb/Core/ModuleList.h
>
> @@ -541,7 +541,8 @@ public:
>
>  const FileSpecList 
> *module_search_paths_ptr,
>
>  lldb::ModuleSP *old_module_sp_ptr,
>
>  bool *did_create_ptr,
>
> -bool always_create = false);
>
> +bool always_create = false,
>
> +const char* sysroot = nullptr);
>
>
>
>static bool RemoveSharedModule(lldb::ModuleSP _sp);
>
>
>
> diff --git a/source/Core/ModuleList.cpp b/source/Core/ModuleList.cpp
>
> index 3970052..f2db3bb 100644
>
> --- a/source/Core/ModuleList.cpp
>
> +++ b/source/Core/ModuleList.cpp
>
> @@ -707,7 +707,11 @@ Status ModuleList::GetSharedModule(const 
> ModuleSpec _spec,
>
> ModuleSP _sp,
>
> const FileSpecList 
> *module_search_paths_ptr,
>
> ModuleSP *old_module_sp_ptr,
>
> -   bool *did_create_ptr, bool always_create) 
> {
>
> +   bool *did_create_ptr, bool 
> + always_create,
>
> +   const char* sysroot) {
>
> +  // Make sure no one else can try and get or create a module while 
> + this
>
> +  // function is actively working on it by doing an extra lock on the
>
> +  // global mutex list.
>
>ModuleList _module_list = GetSharedModuleList();
>
>std::lock_guard guard(
>
>shared_module_list.m_modules_mutex);
>
> @@ -726,9 +730,6 @@ Status ModuleList::GetSharedModule(const 
> ModuleSpec _spec,
>
>const FileSpec _file_spec = module_spec.GetFileSpec();
>
>const ArchSpec  = module_spec.GetArchitecture();
>
>
>
> -  // Make sure no one else can try and get or create a module while 
> this
>
> -  // function is actively working on it by doing an extra lock on the
>
> -  // global mutex list.
>
>if (!always_create) {
>
>  ModuleList matching_module_list;
>
>  const size_t num_matching_modules =
>
> @@ -762,7 +763,11 @@ Status ModuleList::GetSharedModule(const 
> ModuleSpec _spec,
>
>if (module_sp)
>
>  return error;
>
>
>
> -  module_sp.reset(new Module(module_spec));
>
> +  auto resolved_module_spec(module_spec);
>
> +  if (sysroot != nullptr)
>
> +resolved_module_spec.GetFileSpec().PrependPathComponent(sysroot);
>
> +
>
> +  module_sp.reset(new Module(resolved_module_spec));
>
>// Make sure there are a module and an object file since we can 
> specify
>
>// a

Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

[Eugene Birukov via lldb-dev]

I have a small fix - pass platform sysroot to ModuleList::GetSharedModule. The 
fix works for me.

What should I do to get it reviewed?

Thanks,
Eugene

diff --git a/include/lldb/Core/ModuleList.h b/include/lldb/Core/ModuleList.h
index 4b637c9..3214291 100644
--- a/include/lldb/Core/ModuleList.h
+++ b/include/lldb/Core/ModuleList.h
@@ -541,7 +541,8 @@ public:
 const FileSpecList *module_search_paths_ptr,
 lldb::ModuleSP *old_module_sp_ptr,
 bool *did_create_ptr,
-bool always_create = false);
+bool always_create = false,
+const char* sysroot = nullptr);

   static bool RemoveSharedModule(lldb::ModuleSP _sp);

diff --git a/source/Core/ModuleList.cpp b/source/Core/ModuleList.cpp
index 3970052..f2db3bb 100644
--- a/source/Core/ModuleList.cpp
+++ b/source/Core/ModuleList.cpp
@@ -707,7 +707,11 @@ Status ModuleList::GetSharedModule(const ModuleSpec 
_spec,
ModuleSP _sp,
const FileSpecList *module_search_paths_ptr,
ModuleSP *old_module_sp_ptr,
-   bool *did_create_ptr, bool always_create) {
+   bool *did_create_ptr, bool always_create,
+   const char* sysroot) {
+  // Make sure no one else can try and get or create a module while this
+  // function is actively working on it by doing an extra lock on the
+  // global mutex list.
   ModuleList _module_list = GetSharedModuleList();
   std::lock_guard guard(
   shared_module_list.m_modules_mutex);
@@ -726,9 +730,6 @@ Status ModuleList::GetSharedModule(const ModuleSpec 
_spec,
   const FileSpec _file_spec = module_spec.GetFileSpec();
   const ArchSpec  = module_spec.GetArchitecture();

-  // Make sure no one else can try and get or create a module while this
-  // function is actively working on it by doing an extra lock on the
-  // global mutex list.
   if (!always_create) {
 ModuleList matching_module_list;
 const size_t num_matching_modules =
@@ -762,7 +763,11 @@ Status ModuleList::GetSharedModule(const ModuleSpec 
_spec,
   if (module_sp)
 return error;

-  module_sp.reset(new Module(module_spec));
+  auto resolved_module_spec(module_spec);
+  if (sysroot != nullptr)
+resolved_module_spec.GetFileSpec().PrependPathComponent(sysroot);
+
+  module_sp.reset(new Module(resolved_module_spec));
   // Make sure there are a module and an object file since we can specify
   // a valid file path with an architecture that might not be in that file.
   // By getting the object file we can guarantee that the architecture matches
diff --git a/source/Target/Platform.cpp b/source/Target/Platform.cpp
index 5d60bb7..19161cc 100644
--- a/source/Target/Platform.cpp
+++ b/source/Target/Platform.cpp
@@ -225,13 +225,14 @@ Status Platform::GetSharedModule(const ModuleSpec 
_spec,
   if (IsHost())
 return ModuleList::GetSharedModule(
 module_spec, module_sp, module_search_paths_ptr, old_module_sp_ptr,
-did_create_ptr, false);
+did_create_ptr, false, m_sdk_sysroot.AsCString());

   return GetRemoteSharedModule(module_spec, process, module_sp,
[&](const ModuleSpec ) {
  Status error = ModuleList::GetSharedModule(
  spec, module_sp, module_search_paths_ptr,
- old_module_sp_ptr, did_create_ptr, false);
+ old_module_sp_ptr, did_create_ptr, false,
+ m_sdk_sysroot.AsCString());
  if (error.Success() && module_sp)
module_sp->SetPlatformFileSpec(
spec.GetFileSpec());

From: lldb-dev 
mailto:lldb-dev-boun...@lists.llvm.org>> On 
Behalf Of Eugene Birukov via lldb-dev
Sent: Friday, July 20, 2018 12:21 PM
To: Ted Woodward 
mailto:ted.woodw...@codeaurora.org>>; 
lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] LLDB does not respect platform sysroot when loading 
core on Linux


  1.  Shouldn't platform trick work?
  2.  This doesn't work too. "image" command is rejected if I don't have the 
target created. But if I issue it after I got target, the module list gets 
practically empty. Only the modules I have exactly matching between my machine 
and the target are left.

Another problem: ld-linux-x86-64.so.2 has matched from my machine, but this is 
actually a different file.

(lldb) image search-paths add / /tmp/debugcore.3WyoW4/lib2/
error: invalid target

(lldb) target create -c core bin/executable
Core file ... (x86_64) was loaded.
(lldb) target mod list
[  0] EB

Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

[Eugene Birukov via lldb-dev]

ore.3WyoW4/bin/executable
[  1] BBCFB8B3-D0D8-9B97-9231-645196845E00-CB55E7D0
/opt/x/bin/../lib/libc++.so.1
[  2] AF1A7705-DAC0-8661-7411-8DEFE8281C64-AED273A9
/opt/x/bin/../lib/libc++abi.so.1
[  3] 5D7B6259-5522-75A3-C17B-D4C3FD05F5A6-BF40CAA5
/lib64/ld-linux-x86-64.so.2
(lldb)

Thanks,
Eugene

From: Ted Woodward 
Sent: Friday, July 20, 2018 12:01 PM
To: Eugene Birukov ; lldb-dev@lists.llvm.org
Subject: RE: [lldb-dev] LLDB does not respect platform sysroot when loading 
core on Linux

Instead of setting the sysroot, try the command
image search-paths add / /path/to/remote/shared/libraries/

That adds to the list that the dynamic loader uses to map shared object paths.

It uses a simple text substitution, so in the above case,
/usr/lib/libc.so
Becomes
/path/to/remote/shared/libraries/usr/lib/libc.so

Matching up trailing slashes is critical, as I learned the hard way!

Ted

--
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, July 20, 2018 1:13 PM
To: lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
Subject: [lldb-dev] LLDB does not respect platform sysroot when loading core on 
Linux

Hello,

I would appreciate advise how to fix this correctly...

I have a core dump from somebody's RHEL Linux and I am trying to open it on my 
Ubuntu. I have all the shared libraries from the target sitting under my local 
directory. So, GDB happily opens the core after I issue "set sysroot 
/path/to/local/root", but LLDB release_60 fails to do it.

I follow instructions from Greg's Clayton mail 
http://lists.llvm.org/pipermail/lldb-dev/2016-January/009236.html<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Flldb-dev%2F2016-January%2F009236.html=02%7C01%7Ceugenebi%40microsoft.com%7C0e095f7f9acd4f9dfa6408d5ee733146%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636677100876922006=DacHWP%2Bprfj9gEzF6j1x0syIf%2F29Wa1YoZ5eIcxZplg%3D=0>
 :

(lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
(lldb) 

Under debugger, I see that LLDB successfully created Platform object with 
m_sdk_root set to my path and the Target uses it as its platform:


(gdb) p target_sp->m_platform_sp->m_sdk_sysroot

$42 = {

  m_string = 0x80e070 "/tmp/debugcore.3WyoW4/lib2"

}

But this value is not used when it comes to 
DynamicLoaderPOSIXDYLD::LoadAllCurrentModules.

(gdb) bt

#0  lldb_private::ModuleList::GetSharedModule (module_spec=..., 
module_sp=std::shared_ptr (empty) 0x0,

module_search_paths_ptr=0x83ad60, old_module_sp_ptr=0x7fffbb50, 
did_create_ptr=0x7fffbb07,

always_create=false) at 
/home/eugene/llvm/tools/lldb/source/Core/ModuleList.cpp:710

#1  0x7fffedc2d130 in lldb_private::Platformoperator()(const lldb_private::ModuleSpec &) const 
(__closure=0x8581b0, spec=...)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:234

#2  0x7fffedc34ff2 in std::_Function_handler >::_M_invoke(const std::_Any_data &, const 
lldb_private::ModuleSpec &) (__functor=..., __args#0=...) at 
/usr/include/c++/5/functional:1857

#3  0x7fffedc37978 in std::function::operator()(lldb_private::ModuleSpec const&) 
const (this=0x7fffba80, __args#0=...) at /usr/include/c++/5/functional:2267

#4  0x7fffedc3375a in 
lldb_private::Platform::GetRemoteSharedModule(lldb_private::ModuleSpec const&, 
lldb_private::Process*, std::shared_ptr&, 
std::function const&, 
bool*) (this=0x839330, module_spec=..., process=0x84d310, 
module_sp=std::shared_ptr (empty) 0x0,

module_resolver=..., did_create_ptr=0x7fffbb07)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:1628

#5  0x7fffedc2d2cd in lldb_private::Platform::GetSharedModule 
(this=0x839330, module_spec=...,

process=0x84d310, module_sp=std::shared_ptr (empty) 0x0, 
module_search_paths_ptr=0x83ad60,

old_module_sp_ptr=0x7fffbb50, did_create_ptr=0x7fffbb07)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:240

#6  0x7fffedc9957c in lldb_private::Target::GetSharedModule (this=0x846960, 
module_spec=..., error_ptr=0x0)

at /home/eugene/llvm/tools/lldb/source/Target/Target.cpp:1952

#7  0x7fffef8e0d11 in lldb_private::DynamicLoader::LoadModuleAtAddress 
(this=0x9a0a70, file=...,

link_map_addr=139700267943784, base_addr=139700263510016, 
base_addr_is_offset=true)

at /home/eugene/llvm/tools/lldb/source/Core/DynamicLoader.cpp:171

#8  0x7fffedd8fb55 in DynamicLoaderPOSIXDYLD::LoadAllCurrentModules 
(this=0x9a0a70)

at 
/home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:537

#9  0x7fffedd8de52 in DynamicLoaderPOSIXDYLD::DidAttach (th

[lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

[Eugene Birukov via lldb-dev]

Hello,

I would appreciate advise how to fix this correctly...

I have a core dump from somebody's RHEL Linux and I am trying to open it on my 
Ubuntu. I have all the shared libraries from the target sitting under my local 
directory. So, GDB happily opens the core after I issue "set sysroot 
/path/to/local/root", but LLDB release_60 fails to do it.

I follow instructions from Greg's Clayton mail 
http://lists.llvm.org/pipermail/lldb-dev/2016-January/009236.html :

(lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
(lldb) 

Under debugger, I see that LLDB successfully created Platform object with 
m_sdk_root set to my path and the Target uses it as its platform:


(gdb) p target_sp->m_platform_sp->m_sdk_sysroot

$42 = {

  m_string = 0x80e070 "/tmp/debugcore.3WyoW4/lib2"

}

But this value is not used when it comes to 
DynamicLoaderPOSIXDYLD::LoadAllCurrentModules.

(gdb) bt

#0  lldb_private::ModuleList::GetSharedModule (module_spec=..., 
module_sp=std::shared_ptr (empty) 0x0,

module_search_paths_ptr=0x83ad60, old_module_sp_ptr=0x7fffbb50, 
did_create_ptr=0x7fffbb07,

always_create=false) at 
/home/eugene/llvm/tools/lldb/source/Core/ModuleList.cpp:710

#1  0x7fffedc2d130 in lldb_private::Platformoperator()(const lldb_private::ModuleSpec &) const 
(__closure=0x8581b0, spec=...)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:234

#2  0x7fffedc34ff2 in std::_Function_handler >::_M_invoke(const std::_Any_data &, const 
lldb_private::ModuleSpec &) (__functor=..., __args#0=...) at 
/usr/include/c++/5/functional:1857

#3  0x7fffedc37978 in std::function::operator()(lldb_private::ModuleSpec const&) 
const (this=0x7fffba80, __args#0=...) at /usr/include/c++/5/functional:2267

#4  0x7fffedc3375a in 
lldb_private::Platform::GetRemoteSharedModule(lldb_private::ModuleSpec const&, 
lldb_private::Process*, std::shared_ptr&, 
std::function const&, 
bool*) (this=0x839330, module_spec=..., process=0x84d310, 
module_sp=std::shared_ptr (empty) 0x0,

module_resolver=..., did_create_ptr=0x7fffbb07)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:1628

#5  0x7fffedc2d2cd in lldb_private::Platform::GetSharedModule 
(this=0x839330, module_spec=...,

process=0x84d310, module_sp=std::shared_ptr (empty) 0x0, 
module_search_paths_ptr=0x83ad60,

old_module_sp_ptr=0x7fffbb50, did_create_ptr=0x7fffbb07)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:240

#6  0x7fffedc9957c in lldb_private::Target::GetSharedModule (this=0x846960, 
module_spec=..., error_ptr=0x0)

at /home/eugene/llvm/tools/lldb/source/Target/Target.cpp:1952

#7  0x7fffef8e0d11 in lldb_private::DynamicLoader::LoadModuleAtAddress 
(this=0x9a0a70, file=...,

link_map_addr=139700267943784, base_addr=139700263510016, 
base_addr_is_offset=true)

at /home/eugene/llvm/tools/lldb/source/Core/DynamicLoader.cpp:171

#8  0x7fffedd8fb55 in DynamicLoaderPOSIXDYLD::LoadAllCurrentModules 
(this=0x9a0a70)

at 
/home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:537

#9  0x7fffedd8de52 in DynamicLoaderPOSIXDYLD::DidAttach (this=0x9a0a70)

at 
/home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:171

#10 0x7fffedc476d9 in lldb_private::Process::LoadCore (this=0x84d310)

at /home/eugene/llvm/tools/lldb/source/Target/Process.cpp:2853

I simply do not see any reference to sysroot in the GetSharedModule() code. 
What is there - it is only scanning module_search_paths_ptr looking for file. 
This would not work because the scan ignores the directory part of the module: 
it takes the next path from the list and appends the file name. What I need 
instead - take m_sdk_sysroot from Platform and append the full module - 
including directory - to it.

Unfortunately, GetSharedModule() is a static method and does not have any clue 
what is current platform or current target. So, should I pass another argument 
down there with sysroot or what? I have correct platform object at frame 4.

Thanks,
Eugene


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

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

[Eugene Birukov via lldb-dev]

Yes, that's what happens to all 3 fields. I already fixed LLDB, Pavel reviewed 
the change.


Sent from Outlook<http://aka.ms/weboutlook>



From: Greg Clayton <gclay...@apple.com>
Sent: Thursday, February 2, 2017 2:31 PM
To: Eugene Birukov
Cc: Pavel Labath; LLDB
Subject: Re: [lldb-dev] ELF header does not hold big modules

Found this on the web:


e_shnum
This member holds the number of entries in the section header
table. Thus the product of e_shentsize and e_shnum gives the section
header table's size in bytes. If a file has no section header table,
e_shnum holds the value zero.

If the number of sections is greater than or equal to SHN_LORESERVE
(0xff00), this member has the value zero and the actual number of
section header table entries is contained in the sh_size field of
the section header at index 0. (Otherwise, the sh_size member of the
initial entry contains 0.)


See the second paragraph. I am guessing the same thing would need to happen for 
program headers? I would check the various ELF file parsers in LLVM and see if 
they handle this correctly?

Greg

On Jan 23, 2017, at 3:26 PM, Eugene Birukov via lldb-dev 
<lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>> wrote:

> By "all" I presume you mean "all fields that refer to section counts or 
> indexes".

Correct. I mean exactly 3 fields: e_phnum, e_shnum, and e_shstrndx that could 
be redirected to section #0.

Sent from Outlook<http://aka.ms/weboutlook>



From: Pavel Labath <lab...@google.com<mailto:lab...@google.com>>
Sent: Monday, January 23, 2017 2:04 AM
To: Eugene Birukov
Cc: LLDB
Subject: Re: ELF header does not hold big modules

Hello Eugene,

On 21 January 2017 at 00:42, Eugene Birukov 
<eugen...@hotmail.com<mailto:eugen...@hotmail.com>> wrote:
> 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?

Sounds like a plan. By "all" I presume you mean "all fields that refer
to section counts or indexes". I don't see a reason the change the
size of the e.g. e_type field. I think going 32 bit will be enough,
particularly as the "fallback" field you are reading this from is only
32 bit wide anyway, and so you would still have to touch this if we
ever cross that boundary. (And we are really talking about 4 billion
sections, not a 4GB core file, right?)


> 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...

The reason we initially read only the first few bytes of the file, is
to be able to make a quick decision as to whether this is likely to be
a valid elf file (see call to ObjectFileELF::MagicBytesMatch in
GetModuleSpecifications). After that, we extend the buffer to the
whole file. It looks like this currently happens before parsing the
ELF header, but I don't see a reason why  it would have to stay that
way.

cheers,
pavel
___
lldb-dev mailing list
lldb-dev@lists.llvm.org<mailto: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] ELF header does not hold big modules

[Eugene Birukov via lldb-dev]

> By "all" I presume you mean "all fields that refer to section counts or 
> indexes".


Correct. I mean exactly 3 fields: e_phnum, e_shnum, and e_shstrndx that could 
be redirected to section #0.


Sent from Outlook



From: Pavel Labath 
Sent: Monday, January 23, 2017 2:04 AM
To: Eugene Birukov
Cc: LLDB
Subject: Re: ELF header does not hold big modules

Hello Eugene,

On 21 January 2017 at 00:42, Eugene Birukov  wrote:
> 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?

Sounds like a plan. By "all" I presume you mean "all fields that refer
to section counts or indexes". I don't see a reason the change the
size of the e.g. e_type field. I think going 32 bit will be enough,
particularly as the "fallback" field you are reading this from is only
32 bit wide anyway, and so you would still have to touch this if we
ever cross that boundary. (And we are really talking about 4 billion
sections, not a 4GB core file, right?)


> 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...

The reason we initially read only the first few bytes of the file, is
to be able to make a quick decision as to whether this is likely to be
a valid elf file (see call to ObjectFileELF::MagicBytesMatch in
GetModuleSpecifications). After that, we extend the buffer to the
whole file. It looks like this currently happens before parsing the
ELF header, but I don't see a reason why  it would have to stay that
way.

cheers,
pavel
___
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

[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<http://aka.ms/weboutlook>



From: jing...@apple.com <jing...@apple.com> on behalf of Jim Ingham 
<jing...@apple.com>
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 
> <lldb-dev@lists.llvm.org> 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 <lab...@google.com>
> Cc: rd...@microsoft.com; LLDB <lldb-dev@lists.llvm.org>
> 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 <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
> <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
> > 

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

[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

[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<http://aka.ms/weboutlook>



From: Pavel Labath <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
<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_ehsize = 64,
>
>   e_phentsize = 56,
>
>   e_phnum = 7,
>
>   e_shentsize = 64,
>
>   e_shnum = 38,
>
>   e_shstrndx = 35
>
> }
>
>
> LLDB tries to rea

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

[Eugene Birukov via lldb-dev]

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

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

[Eugene Birukov via lldb-dev]

 Outlook<http://aka.ms/weboutlook>



From: Pavel Labath <lab...@google.com<mailto:lab...@google.com>>
Sent: Thursday, December 8, 2016 3:19 AM
To: Eugene Birukov

Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04

Thanks for the info. I agree with your assessment, it definitely looks like a 
kernel bug.

I don't know how to trigger a kernel core dump. I have done a bit of kernel 
debugging/development, but it mainly consisted of adding a bunch of printf's 
and watching the dmesg output. I think we should contact the linux kernel 
mailing list (LKML.org) with this problem. I've had pretty good success with 
this in the past. The one contact I have there is Oleg Nesterov 
<o...@redhat.com<mailto:o...@redhat.com>>. He's quite a ptrace expert, and was 
able to fix my bug in a day when I contacted him with a not-too-unsimilar 
problem to yours (although this does sound more complicated, I suspect some 
interaction between ptrace and virtual memory manager).

Before we do that, we may want to reduce the scope of the problem a bit. From 
your description is sounds like un-predicability comes from the tracee side, 
and once it gets to a bad state, all tracer writes to the affected area will 
hang. In that case, it should be possible to take lldb out of the equation, and 
instead write a trivial app, which takes a pid and an address, and does a 
PTRACE_ATTACH + a bunch of PTRACE_POKEDATA to the given address. I think this 
would be enough to get kernel folks interested, as it clearly demonstrates it's 
not lldb being funny, and they may direct us how to debug this further. I have 
adapted one of my test apps to do this (attached). Could you try this out on 
your system?

pl




On 8 December 2016 at 00:57, Eugene Birukov 
<eugen...@hotmail.com<mailto:eugen...@hotmail.com>> wrote:

Some additional info.

I stepped through individual instructions… It hangs in syscall

37  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee21b <ptrace+43>:  48 63 70 08 movslq 0x8(%rax),%rsi
(gdb)
38  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee21f <ptrace+47>:  48 8b 50 10 mov0x10(%rax),%rdx
(gdb)
45  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee223 <ptrace+51>:  89 ff   mov%edi,%edi
(gdb)
36  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee225 <ptrace+53>:  48 89 44 24 c8  mov%rax,-0x38(%rsp)
(gdb)
45  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee22a <ptrace+58>:  4c 0f 47 50 18  cmova  0x18(%rax),%r10
   0x7fcac11ee22f <ptrace+63>:  b8 65 00 00 00  mov$0x65,%eax
(gdb)
0x7fcac11ee22f  45  in ../sysdeps/unix/sysv/linux/ptrace.c
   0x7fcac11ee22a <ptrace+58>:  4c 0f 47 50 18  cmova  0x18(%rax),%r10
=> 0x7fcac11ee22f <ptrace+63>:  b8 65 00 00 00  mov$0x65,%eax
(gdb)
38  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee234 <ptrace+68>:  c7 44 24 b8 18 00 00 00 movl   
$0x18,-0x48(%rsp)
(gdb)
45  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee23c <ptrace+76>:  0f 05   syscall
   0x7fcac11ee23e <ptrace+78>:  48 3d 00 f0 ff ff   cmp
$0xf000,%rax
   0x7fcac11ee244 <ptrace+84>:  77 2a   ja 0x7fcac11ee270 
<ptrace+128>
(gdb)


Also, user vs. kernel times are about 1:1000 ratio according to proc/pid/stat:


# cat /proc/21809/stat

21809 (lldb-server) R 21780 21809 21809 0 -1 4194304 1175 1709 0 0 18 18398 4 0 
20 0 1 0 1602761 48611328 2102 18446744073709551615 4194304 11143636 
140733729492144 140733729487496 140187105837630 262144 65537 4096 65537 0 0 0 
17 1 0 0 0 0 0 13244688 13945048 29155328 140733729499314 140733729499429 
140733729499429 140733729501128 0


Eugene


Sent from Outlook<http://aka.ms/weboutlook>



From: Eugene Birukov <eugen...@hotmail.com<mailto:eugen...@hotmail.com>>
Sent: Wednesday, December 7, 2016 1:15 PM
To: Pavel Labath; Eugene Birukov

Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04


And yes - I suspect kernel bug because we did not see it on 15.10 but on 16.04 
I have several people reporting it. In one case it would repro on 3 out of 4 
kind of "identical" machines.


I do not have simple repro, but I can find victim VM that we do not care much 
about. Is there a way to cause Linux kernel core dump there?


Sent from Outlook<http://aka.ms/weboutlook>



From: lldb-dev 
<lldb-dev-boun...@lists.llvm.org<mailto:lldb-dev-boun...@lists.llvm.org>> on 
behalf of Eugene Birukov via lldb-dev 
<lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>>
Sent: Wednesday, December 7, 2016 11:36 AM
To: Pavel Labat

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

[Eugene Birukov via lldb-dev]

success with 
this in the past. The one contact I have there is Oleg Nesterov 
<o...@redhat.com<mailto:o...@redhat.com>>. He's quite a ptrace expert, and was 
able to fix my bug in a day when I contacted him with a not-too-unsimilar 
problem to yours (although this does sound more complicated, I suspect some 
interaction between ptrace and virtual memory manager).

Before we do that, we may want to reduce the scope of the problem a bit. From 
your description is sounds like un-predicability comes from the tracee side, 
and once it gets to a bad state, all tracer writes to the affected area will 
hang. In that case, it should be possible to take lldb out of the equation, and 
instead write a trivial app, which takes a pid and an address, and does a 
PTRACE_ATTACH + a bunch of PTRACE_POKEDATA to the given address. I think this 
would be enough to get kernel folks interested, as it clearly demonstrates it's 
not lldb being funny, and they may direct us how to debug this further. I have 
adapted one of my test apps to do this (attached). Could you try this out on 
your system?

pl




On 8 December 2016 at 00:57, Eugene Birukov 
<eugen...@hotmail.com<mailto:eugen...@hotmail.com>> wrote:

Some additional info.

I stepped through individual instructions… It hangs in syscall

37  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee21b <ptrace+43>:  48 63 70 08 movslq 0x8(%rax),%rsi
(gdb)
38  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee21f <ptrace+47>:  48 8b 50 10 mov0x10(%rax),%rdx
(gdb)
45  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee223 <ptrace+51>:  89 ff   mov%edi,%edi
(gdb)
36  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee225 <ptrace+53>:  48 89 44 24 c8  mov%rax,-0x38(%rsp)
(gdb)
45  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee22a <ptrace+58>:  4c 0f 47 50 18  cmova  0x18(%rax),%r10
   0x7fcac11ee22f <ptrace+63>:  b8 65 00 00 00  mov$0x65,%eax
(gdb)
0x7fcac11ee22f  45  in ../sysdeps/unix/sysv/linux/ptrace.c
   0x7fcac11ee22a <ptrace+58>:  4c 0f 47 50 18  cmova  0x18(%rax),%r10
=> 0x7fcac11ee22f <ptrace+63>:  b8 65 00 00 00  mov$0x65,%eax
(gdb)
38  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee234 <ptrace+68>:  c7 44 24 b8 18 00 00 00 movl   
$0x18,-0x48(%rsp)
(gdb)
45  in ../sysdeps/unix/sysv/linux/ptrace.c
=> 0x7fcac11ee23c <ptrace+76>:  0f 05   syscall
   0x7fcac11ee23e <ptrace+78>:  48 3d 00 f0 ff ff   cmp
$0xf000,%rax
   0x7fcac11ee244 <ptrace+84>:  77 2a   ja 0x7fcac11ee270 
<ptrace+128>
(gdb)


Also, user vs. kernel times are about 1:1000 ratio according to proc/pid/stat:


# cat /proc/21809/stat

21809 (lldb-server) R 21780 21809 21809 0 -1 4194304 1175 1709 0 0 18 18398 4 0 
20 0 1 0 1602761 48611328 2102 18446744073709551615 4194304 11143636 
140733729492144 140733729487496 140187105837630 262144 65537 4096 65537 0 0 0 
17 1 0 0 0 0 0 13244688 13945048 29155328 140733729499314 140733729499429 
140733729499429 140733729501128 0


Eugene


Sent from Outlook<http://aka.ms/weboutlook>



From: Eugene Birukov <eugen...@hotmail.com<mailto:eugen...@hotmail.com>>
Sent: Wednesday, December 7, 2016 1:15 PM
To: Pavel Labath; Eugene Birukov

Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04


And yes - I suspect kernel bug because we did not see it on 15.10 but on 16.04 
I have several people reporting it. In one case it would repro on 3 out of 4 
kind of "identical" machines.


I do not have simple repro, but I can find victim VM that we do not care much 
about. Is there a way to cause Linux kernel core dump there?


Sent from Outlook<http://aka.ms/weboutlook>



From: lldb-dev 
<lldb-dev-boun...@lists.llvm.org<mailto:lldb-dev-boun...@lists.llvm.org>> on 
behalf of Eugene Birukov via lldb-dev 
<lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>>
Sent: Wednesday, December 7, 2016 11:36 AM
To: Pavel Labath
Cc: LLDB
Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04


> could you get a backtrace of lldb-server when it is in the "stuck"

state (just attach with lldb/gdb after it hangs and do "bt")?


You wish [☹]  The lldb-server does not react to any signals including SIGSTOP, 
so gdb just hangs forever.


> If you can get me reasonably detailed repro steps, I can try to investigate


Unfortunately I do not have repro myself. It happens semi-randomly on some 
machines and I need to borrow the machine with the problem. Here are some 
details from my records:

  *   It is pretty big piece of RX memory, /proc//maps 

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

[Eugene Birukov via lldb-dev]

> could you get a backtrace of lldb-server when it is in the "stuck"

state (just attach with lldb/gdb after it hangs and do "bt")?


You wish [☹]  The lldb-server does not react to any signals including SIGSTOP, 
so gdb just hangs forever.


> If you can get me reasonably detailed repro steps, I can try to investigate


Unfortunately I do not have repro myself. It happens semi-randomly on some 
machines and I need to borrow the machine with the problem. Here are some 
details from my records:

  *   It is pretty big piece of RX memory, /proc//maps shows this:
409701000-40b49c000 r-xp  00:00 0
  *   Writing into some locations within that VMA works
  *   When it repros, it is pretty consistent, but changing in the target may 
shift it - i.e. make no repro or fail at different address.

> are you able to still reproduce the bug with logging enabled?


Yes. Here are a few last lines from the log:

1481139040.768961000 0x7fff253c9780 Communication::Write (src = 0x7fff253c8f48, 
src_len = 7) connection = 0x24a6bd0
1481139040.768963000 0x24a6bd0 ConnectionFileDescriptor::Write (src = 
0x7fff253c8f48, src_len = 7)
1481139040.768973000 0x24a6cc0 Socket::Write() (socket = 6, src = 
0x7fff253c8f48, src_len = 7, flags = 0) => 7 (error = (null))
1481139040.768976000 0x24a6bd0 ConnectionFileDescriptor::Write(fd = 6, src = 
0x7fff253c8f48, src_len = 7) => 7 (error = (null))
1481139040.768979000 0x7fff253c9780 Communication::Read (dst = 0x7fff253c7140, 
dst_len = 8192, timeout = 0 usec) connection = 0x24a6bd0
1481139040.768982000 0x24a6bd0 ConnectionFileDescriptor::BytesAvailable 
(timeout_usec = 0)
1481139040.768984000 0x24a6bd0 ConnectionFileDescriptor::BytesAvailable()  
::select (nfds=7, fds={6, 4}, NULL, NULL, timeout=0x7fff253c6d80)...
1481139040.768986000 0x24a6bd0 ConnectionFileDescriptor::BytesAvailable()  
::select (nfds=7, fds={6, 4}, NULL, NULL, timeout=0x7fff253c6d80) => 0, error = 
(null)
1481139090.788317000 0x7fff253c9780 Communication::Read (dst = 0x7fff253c7140, 
dst_len = 8192, timeout = 0 usec) connection = 0x24a6bd0
1481139090.788356000 0x24a6bd0 ConnectionFileDescriptor::BytesAvailable 
(timeout_usec = 0)
1481139090.788364000 0x24a6bd0 ConnectionFileDescriptor::BytesAvailable()  
::select (nfds=7, fds={6, 4}, NULL, NULL, timeout=0x7fff253c6d80)...
1481139090.788368000 0x24a6bd0 ConnectionFileDescriptor::BytesAvailable()  
::select (nfds=7, fds={6, 4}, NULL, NULL, timeout=0x7fff253c6d80) => 1, error = 
(null)
1481139090.788378000 0x24a6cc0 Socket::Read() (socket = 6, src = 
0x7fff253c7140, src_len = 25, flags = 0) => 25 (error = (null))
1481139090.788382000 0x24a6bd0 ConnectionFileDescriptor::Read()  fd = 6, dst = 
0x7fff253c7140, dst_len = 8192) => 25, error = (null)
1481139090.788395000 NativeProcessLinux::WriteMemory(0x409d5a7d0, 0x25271d0, 4)
1481139090.788409000 NativeProcessLinux::ReadMemory using process_vm_readv to 
read 8 bytes from inferior address 0x409d5a7d0: Success
1481139090.788414000 PTRACE_POKEDATA [1][0][0][0][57][41][54][41]


Thanks,

Eugene


Sent from Outlook<http://aka.ms/weboutlook>



From: Pavel Labath <lab...@google.com>
Sent: Wednesday, December 7, 2016 2:34 AM
To: Eugene Birukov
Cc: LLDB
Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04

Hello Eugene,

this sounds troubling, and I'd like to get to the bottom of this. If
you can get me a bit more information about this, I believe we can
figure it out:

- could you get a backtrace of lldb-server when it is in the "stuck"
state (just attach with lldb/gdb after it hangs and do "bt")? I want
to see the where is it spinning, as I don't see any obvious infinite
loop there.

- are you able to still reproduce the bug with logging enabled? If so,
I'd like to see the log file to understand this better. (You can
enable logging by starting lldb-server with: --log-file XXX.log
--log-channels "lldb all:linux all". If you're starting it via lldb
client you can set the LLDB_DEBUGSERVER_LOG_FILE and
LLDB_SERVER_LOG_CHANNELS environment vars to achieve this)

- If you can get me reasonably detailed repro steps, I can try to
investigate (I am fine with the first step being "install ubuntu 16.04
in virtualbox")

On 6 December 2016 at 23:41, Eugene Birukov via lldb-dev
<lldb-dev@lists.llvm.org> wrote:
> Hi,
> 1. I believe that lldb-server spins inside ptrace. I put breakpoint on the
> highlighted line, and it does not hit. If I put breakpoint on line before,
> it hits but lldb-server hangs.

Do you mean actually inside the ptrace(2) syscall? Your description
would certainly fit that, but that sounds scary, as it would mean a
kernel bug. If that's the case, then we have to start looking in the
kernel. I have some experience with that, but If we can boil this down
to a simple use case, we can also ask the kernel ptrace folks for
help.


>

[lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

[Eugene Birukov via lldb-dev]

Hi,


I am running Linux Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-51-generic x86_64) in 
virtual machine.


When I am trying to write memory in my process, sometimes it works but 
sometimes lldb-server goes unresponsive. It spins with 100% CPU utilization and 
does not respond to any signals except SIGKILL.


I tried to debug it, but under debugger everything works perfectly :). Here are 
a couple observations:


1. I believe that lldb-server spins inside ptrace. I put breakpoint on the 
highlighted line, and it does not hit. If I put breakpoint on line before, it 
hits but lldb-server hangs.


Error

NativeProcessLinux::PtraceWrapper(int req, lldb::pid_t pid, void *addr, void 
*data, size_t data_size, long *result)

{

Error error;

long int ret;


Log *log (ProcessPOSIXLog::GetLogIfAllCategoriesSet (POSIX_LOG_PTRACE));


PtraceDisplayBytes(req, data, data_size);


errno = 0;

if (req == PTRACE_GETREGSET || req == PTRACE_SETREGSET)

ret = ptrace(static_cast<__ptrace_request>(req), static_cast< 
::pid_t>(pid), *(unsigned int *)addr, data);

else

ret = ptrace(static_cast<__ptrace_request>(req), static_cast< 
::pid_t>(pid), addr, data);


if (ret == -1)

error.SetErrorToErrno();

2. It seems that hang is caused by the client trying to read response too fast. 
I mean, if I step through the client code it works - i.e. there is significant 
delay between client writing into pipe and issuing ::select to wait for 
response.


Any advice how to deal with the situation except putting random sleeps in 
random places?


Thanks,

Eugene


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] File::Read does not read everything

[Eugene Birukov via lldb-dev]

Sorry for noob's question: what is "phabricator"?

Sure, I will do it as soon as I understand what you want me to do :)


Sent from Outlook<http://aka.ms/weboutlook>



From: Zachary Turner <ztur...@google.com>
Sent: Monday, October 17, 2016 5:01 PM
To: Eugene Birukov; Greg Clayton
Cc: LLDB
Subject: Re: [lldb-dev] File::Read does not read everything

Can you upload a diff (with context) to phabricator and add lldb-commits as a 
subscriber and myself / Greg as reviewers?

On Mon, Oct 17, 2016 at 4:59 PM Eugene Birukov via lldb-dev 
<lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>> wrote:

Here is what I am running now:


diff --git a/source/Host/common/File.cpp b/source/Host/common/File.cpp
index 89587a9..a4ac25e 100644
--- a/source/Host/common/File.cpp
+++ b/source/Host/common/File.cpp
@@ -771,21 +771,34 @@ File::Read (void *buf, size_t _bytes, off_t )
 int fd = GetDescriptor();
 if (fd != kInvalidDescriptor)
 {
-ssize_t bytes_read = -1;
-do
+size_t bytes_left = num_bytes;
+num_bytes = 0;
+char *pos = (char*)buf;
+while (bytes_left > 0)
 {
-bytes_read = ::pread (fd, buf, num_bytes, offset);
-} while (bytes_read < 0 && errno == EINTR);
+ssize_t bytes_read = -1;
+do
+{
+bytes_read = ::pread (fd, pos, bytes_left, offset);
+} while (bytes_read < 0 && errno == EINTR);

-if (bytes_read < 0)
-{
-num_bytes = 0;
-error.SetErrorToErrno();
-}
-else
-{
-offset += bytes_read;
-num_bytes = bytes_read;
+if (bytes_read < 0)
+{
+num_bytes = 0;
+error.SetErrorToErrno();
+break;
+}
+else if (bytes_read == 0)
+{
+break;
+}
+else
+{
+offset += bytes_read;
+num_bytes += bytes_read;
+bytes_left -= bytes_read;
+pos += bytes_read;
+}
 }
 }
 else




Sent from Outlook<http://aka.ms/weboutlook>



From: Greg Clayton <gclay...@apple.com<mailto:gclay...@apple.com>>
Sent: Monday, October 17, 2016 12:39 PM
To: Eugene Birukov
Cc: LLDB
Subject: Re: [lldb-dev] File::Read does not read everything

It is probably best to make the code loop as long as "bytes_reads > 0" and we 
haven't read "num_bytes" yet. The darwin kernel has a INT32_MAX read size which 
gets set to MAX_READ_SIZE, but we need to do that because if you try to read 
more than that it reads nothing. So MAX_READ_SIZE is more for the case where 
the read will outright fail if given a byte size that is too large. Feel free 
to submit a patch that can keep calling pread correctly in a loop as long as 
bytes_read > 0.

Greg

> On Oct 17, 2016, at 12:20 PM, Eugene Birukov via lldb-dev 
> <lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>> wrote:
>
> Hello,
>
> I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is 
> located on Windows file share mounted on Linux via mount.cifs. I see that we 
> successfully allocated memory and are trying to fill it in one read. 
> Unfortunately pread returns 2GiB and we never check for short read here.
>
> I think we could combine this code with previous block "#if defined 
> (MAX_READ_SIZE)" if we simply check for short read here (bytes_read too 
> small) and loop until all the buffer is filled.
>
> Thanks,
> Eugene
>
> #ifndef _WIN32
> int fd = GetDescriptor();
> if (fd != kInvalidDescriptor)
> {
> ssize_t bytes_read = -1;
> do
> {
> bytes_read = ::pread (fd, buf, num_bytes, offset);
> } while (bytes_read < 0 && errno == EINTR);
>
> if (bytes_read < 0)
> {
> num_bytes = 0;
> error.SetErrorToErrno();
> }
> else
> {
> offset += bytes_read;
> num_bytes = bytes_read;
> }
> }
>
> Sent from Outlook
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org<mailto: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] File::Read does not read everything

[Eugene Birukov via lldb-dev]

Here is what I am running now:


diff --git a/source/Host/common/File.cpp b/source/Host/common/File.cpp
index 89587a9..a4ac25e 100644
--- a/source/Host/common/File.cpp
+++ b/source/Host/common/File.cpp
@@ -771,21 +771,34 @@ File::Read (void *buf, size_t _bytes, off_t )
 int fd = GetDescriptor();
 if (fd != kInvalidDescriptor)
 {
-ssize_t bytes_read = -1;
-do
+size_t bytes_left = num_bytes;
+num_bytes = 0;
+char *pos = (char*)buf;
+while (bytes_left > 0)
 {
-bytes_read = ::pread (fd, buf, num_bytes, offset);
-} while (bytes_read < 0 && errno == EINTR);
+ssize_t bytes_read = -1;
+do
+{
+bytes_read = ::pread (fd, pos, bytes_left, offset);
+} while (bytes_read < 0 && errno == EINTR);

-if (bytes_read < 0)
-{
-num_bytes = 0;
-error.SetErrorToErrno();
-}
-else
-{
-offset += bytes_read;
-num_bytes = bytes_read;
+if (bytes_read < 0)
+{
+num_bytes = 0;
+error.SetErrorToErrno();
+break;
+}
+else if (bytes_read == 0)
+{
+break;
+}
+else
+{
+offset += bytes_read;
+num_bytes += bytes_read;
+bytes_left -= bytes_read;
+pos += bytes_read;
+}
 }
 }
 else




Sent from Outlook<http://aka.ms/weboutlook>



From: Greg Clayton <gclay...@apple.com>
Sent: Monday, October 17, 2016 12:39 PM
To: Eugene Birukov
Cc: LLDB
Subject: Re: [lldb-dev] File::Read does not read everything

It is probably best to make the code loop as long as "bytes_reads > 0" and we 
haven't read "num_bytes" yet. The darwin kernel has a INT32_MAX read size which 
gets set to MAX_READ_SIZE, but we need to do that because if you try to read 
more than that it reads nothing. So MAX_READ_SIZE is more for the case where 
the read will outright fail if given a byte size that is too large. Feel free 
to submit a patch that can keep calling pread correctly in a loop as long as 
bytes_read > 0.

Greg

> On Oct 17, 2016, at 12:20 PM, Eugene Birukov via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
>
> Hello,
>
> I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is 
> located on Windows file share mounted on Linux via mount.cifs. I see that we 
> successfully allocated memory and are trying to fill it in one read. 
> Unfortunately pread returns 2GiB and we never check for short read here.
>
> I think we could combine this code with previous block "#if defined 
> (MAX_READ_SIZE)" if we simply check for short read here (bytes_read too 
> small) and loop until all the buffer is filled.
>
> Thanks,
> Eugene
>
> #ifndef _WIN32
> int fd = GetDescriptor();
> if (fd != kInvalidDescriptor)
> {
> ssize_t bytes_read = -1;
> do
> {
> bytes_read = ::pread (fd, buf, num_bytes, offset);
> } while (bytes_read < 0 && errno == EINTR);
>
> if (bytes_read < 0)
> {
> num_bytes = 0;
> error.SetErrorToErrno();
> }
> else
> {
> offset += bytes_read;
> num_bytes = bytes_read;
> }
> }
>
> 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

[lldb-dev] File::Read does not read everything

[Eugene Birukov via lldb-dev]

Hello,


I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is located 
on Windows file share mounted on Linux via mount.cifs. I see that we 
successfully allocated memory and are trying to fill it in one read. 
Unfortunately pread returns 2GiB and we never check for short read here.


I think we could combine this code with previous block "#if defined 
(MAX_READ_SIZE)" if we simply check for short read here (bytes_read too small) 
and loop until all the buffer is filled.


Thanks,

Eugene


#ifndef _WIN32
int fd = GetDescriptor();
if (fd != kInvalidDescriptor)
{
ssize_t bytes_read = -1;
do
{
bytes_read = ::pread (fd, buf, num_bytes, offset);
} while (bytes_read < 0 && errno == EINTR);

if (bytes_read < 0)
{
num_bytes = 0;
error.SetErrorToErrno();
}
else
{
offset += bytes_read;
num_bytes = bytes_read;
}
}


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] Memory corruption due to Symtab::AddSymbol growth

[Eugene Birukov via lldb-dev]

Hi,
I am looking through LLDB code... Another dangerous operation is 
Symtab::Finalize() that just swaps the array. This is especially bad since it 
will defeat something like quick-and-dirty hack of preallocating a huge vector 
upfront.
My first impulse to fix that (maybe just temporary to get me unblocked) was 
neuter that Finalize() and replace vector with dequeue. But unfortunately there 
are places when we take address to the first element and assume the rest of 
memory is contiguous - say, we call ::bsearch() on it. 
Apparently, allocating each symbol separately and replacing the vector of 
elements with the vector of (smart) pointers would work, but it will hurt 
performance and probably cause the change touching lots of code...
So, any insights how to fix it? 
Thanks,Eugene

From: eugen...@hotmail.com
To: lldb-dev@lists.llvm.org
Subject: Memory corruption due to Symtab::AddSymbol growth
Date: Fri, 20 May 2016 12:37:15 -0700




Hi,
I am running into memory corruption in LLDB 3.8 release candidate on Linux 
Ubuntu 15.10. I am trying to access stack frame and the symbol on this frame is 
corrupted. Here is what I figured out:
"StackFrame" has field "m_sc" of type "SymbolContext""SymbolContext" has field 
"symbol" which is "Symbol*" pointer 
Now, when AddSymbol needs to grow its storage, the std::vector allocates new 
memory and makes  these "symbol" pointers dangling.Here is the call stack:
#0  0x7274188c in lldb_private::SymbolContextScope::~SymbolContextScope 
(this=0x12b5a58, __in_chrg=)at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Symbol/SymbolContextScope.h:75#1  
0x7289f78a in lldb_private::Symbol::~Symbol (this=0x12b5a58, 
__in_chrg=)at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Symbol/Symbol.h:21#2  
0x728b72e8 in std::_Destroy (__pointer=0x12b5a58) 
at /usr/include/c++/5/bits/stl_construct.h:93#3  0x728b5a9d in 
std::_Destroy_aux::__destroy (__first=0x12b5a58, 
__last=0x12c1710)at /usr/include/c++/5/bits/stl_construct.h:103#4  
0x728b3e41 in std::_Destroy (__first=0x12af710, 
__last=0x12c1710)at /usr/include/c++/5/bits/stl_construct.h:126#5  
0x728b241b in std::_Destroy (__first=0x12af710, __last=0x12c1710)at 
/usr/include/c++/5/bits/stl_construct.h:151#6  0x728b2a2f in 
std::vector::_M_emplace_back_aux 
(this=0x9f6688) at /usr/include/c++/5/bits/vector.tcc:436#7  0x728b143d 
in std::vector::push_back (this=0x9f6688, __x=...)at 
/usr/include/c++/5/bits/stl_vector.h:923#8  0x728ab0c0 in 
lldb_private::Symtab::AddSymbol (this=0x9f6680, symbol=...)at 
/home/eugenebi/llvm/tools/lldb/source/Symbol/Symtab.cpp:70#9  
0x72acba21 in ObjectFileELF::ResolveSymbolForAddress (this=0x9f6310, 
so_addr=..., verify_unique=false)at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2881#10
 0x7273cc50 in lldb_private::Module::ResolveSymbolContextForAddress 
(this=0x9f5cb0, so_addr=..., resolve_scope=72, sc=...,
resolve_tail_call_address=false) at 
/home/eugenebi/llvm/tools/lldb/source/Core/Module.cpp:568#11 0x72b31f04 
in lldb_private::RegisterContextLLDB::InitializeZerothFrame (this=0x98687c0)
at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:180#12
 0x72b31a34 in lldb_private::RegisterContextLLDB::RegisterContextLLDB 
(this=0x98687c0, thread=...,next_frame=std::shared_ptr (empty) 0x0, 
sym_ctx=..., frame_number=0, unwind_lldb=...)at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:82#13
 0x72b2bb7a in lldb_private::UnwindLLDB::AddFirstFrame (this=0x1ee82b0) 
   at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:97#14
 0x72b2cd01 in lldb_private::UnwindLLDB::DoGetFrameInfoAtIndex 
(this=0x1ee82b0, idx=0, cfa=@0x7fffc270: 18446744073709551615,
pc=@0x7fffc268: 18446744073709551615) at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:422#15
 0x729ac64b in lldb_private::Unwind::GetFrameInfoAtIndex 
(this=0x1ee82b0, frame_idx=0, cfa=@0x7fffc270: 18446744073709551615,
pc=@0x7fffc268: 18446744073709551615) at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Target/Unwind.h:78#16 
0x729aa4a9 in lldb_private::StackFrameList::GetFramesUpTo 
(this=0x9868250, end_idx=0)at 
/home/eugenebi/llvm/tools/lldb/source/Target/StackFrameList.cpp:308#17 
0x729ab150 in lldb_private::StackFrameList::GetFrameAtIndex 
(this=0x9868250, idx=0)at 
/home/eugenebi/llvm/tools/lldb/source/Target/StackFrameList.cpp:546#18 
0x729775fa in lldb_private::Thread::GetStackFrameAtIndex 
(this=0x7ff6a805d4f0, idx=0)at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Target/Thread.h:539#19 

Re: [lldb-dev] SBProcess::Detach kills target

[Eugene Birukov via lldb-dev]

OK, I got the picture, thanks a lot!
 > What is it that you are trying to do anyway?

Well, target termination during detach is unexpected, so my customers might get 
confused. Fortunately I am in control of the target program too, so I'll just 
ignore SIGHUP for the time being.
Thanks,Eugene

> From: lab...@google.com
> Date: Thu, 31 Mar 2016 09:16:06 +0100
> Subject: Re: [lldb-dev] SBProcess::Detach kills target
> To: eugen...@hotmail.com
> CC: lldb-dev@lists.llvm.org
> 
> We are not sending the SIGHUP, it is automatically getting sent by the
> OS when the master end of the pty gets closed. The reason you are not
> seeing this in the attach scenario is that we do not intercept
> inferior stdio in this case (it's not possible, or desirable, since
> the process is already running). This is also the reason
> SBProcess.GetSTDOUT does not return anything in the attach scenario. I
> am not familiar with the details of the Mac implementation and I
> cannot tell you why is this not happening there.
> I guess one way to fix this would be to have a special mode of
> starting the inferior without a controlling terminal, but I am not
> sure if this would be a generally useful feature. What is it that you
> are trying to do anyway?
> 
> pl
> 
> On 30 March 2016 at 23:03, Eugene Birukov  wrote:
> > Just a wild guess - is this SIGHUP because stdin/stdout are broken? I.e. the
> > debugger closes its pty's on detach and that causes the signal?
> > What is the behavior on MAC?
> >
> > 
> > To: lab...@google.com
> > Date: Wed, 30 Mar 2016 14:49:33 -0700
> > CC: lldb-dev@lists.llvm.org
> > Subject: Re: [lldb-dev] SBProcess::Detach kills target
> > From: lldb-dev@lists.llvm.org
> >
> >
> > Right, my bad. The problem was that when debugger detaches the stdio does
> > not go anywhere so I failed to see my printf.
> >
> > Still, is this how it is supposed to be? I naively assume that if we don't
> > send SIGHUP in attach scenario we should not send it in launch scenario too.
> >
> > Thanks,
> > Eugene
> >
> >> From: lab...@google.com
> >> Date: Wed, 30 Mar 2016 10:22:33 +0100
> >> Subject: Re: [lldb-dev] SBProcess::Detach kills target
> >> To: eugen...@hotmail.com
> >> CC: jing...@apple.com; lldb-dev@lists.llvm.org
> >>
> >> So I have made a small test program (which does nothing but spin in a
> >> loop), and indeed it is the SIGHUP that kills it after detach. If the
> >> test program blocks the signal, then it continues running even after
> >> detach:
> >> $ cat a.c
> >> #include 
> >> #include 
> >>
> >> int main() {
> >> signal(SIGHUP, SIG_IGN);
> >> for (;;) sleep(1);
> >> }
> >> $ cc a.c -g
> >> $ ps -A | grep a.out
> >> $ ~/ll/build/dbg/bin/lldb ./a.out
> >> (lldb) target create "./a.out"
> >> Current executable set to './a.out' (x86_64).
> >> (lldb) b 6
> >> Breakpoint 1: where = a.out`main + 19 at a.c:6, address =
> >> 0x00400590
> >> (lldb) r
> >> Process 13416 launched: './a.out' (x86_64)
> >> Process 13416 stopped
> >> * thread #1: tid = 13416, 0x00400590 a.out`main + 19 at a.c:6,
> >> name = 'a.out', stop reason = breakpoint 1.1
> >> frame #0: 0x00400590 a.out`main + 19 at a.c:6
> >> 3
> >> 4 int main() {
> >> 5 signal(SIGHUP, SIG_IGN);
> >> -> 6 for (;;) sleep(1);
> >> 7 }
> >> (lldb) detach
> >> Process 13416 detached
> >> (lldb) q
> >> $ ps -A | grep a.out
> >> 13416 ? 00:00:00 a.out
> >>
> >>
> >> On 29 March 2016 at 18:38, Eugene Birukov  wrote:
> >> > I believe this is not SIGHUP on debugger exit. I am using my own C++
> >> > program
> >> > that calls into LLDB API. So, this program is still alive after calling
> >> > SBProcess::Detach() but the target dies. Also, the target intercepts
> >> > SIGHUP
> >> > to do cleanup before exiting. I put printf there, it was not hit.
> >> The fact whether your program is alive irrelevant. What matters is
> >> that by cleaning up the process structure, we will also close the
> >> master end of the pty used for inferior communication, and this is
> >> what causes the SIGHUP. For that reason you also cannot use a printf
> >> to do diagnostics as the output has nowhere to go. Note that lldb's
> >> behavior here will be different from gdb as gdb does not do stdio
> >> redirection, and has the inferior share the pty with the debugger (in
> >> which case your program will die when you close the terminal window).
> >>
> >> >
> >> > I tried interactive LLDB, the target is not there:
> >> >
> >> > Process 49145 stopped
> >> > * thread #1: tid = 49145, ..., stop reason = signal SIGSTOP
> >> > frame #0: 0x76a5bbed libc.so.6 at syscall-template.S:81
> >> > (lldb) detach
> >> > Process 49145 detached
> >> > (lldb) q
> >> > eugene@EUGENEBI-L1:~/tmp$ ps
> >> > PID TTY TIME CMD
> >> > 30714 pts/17 00:00:00 bash
> >> > 49259 pts/17 00:00:00 ps
> >> Note that the inferior will not show up here even if it exists, as ps
> >> will only list the processes with the same tty, but at 

Re: [lldb-dev] SBProcess::Detach kills target

[Eugene Birukov via lldb-dev]

Just a wild guess - is this SIGHUP because stdin/stdout are broken? I.e. the 
debugger closes its pty's on detach and that causes the signal?What is the 
behavior on MAC?

To: lab...@google.com
Date: Wed, 30 Mar 2016 14:49:33 -0700
CC: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] SBProcess::Detach kills target
From: lldb-dev@lists.llvm.org




Right, my bad. The problem was that when debugger detaches the stdio does not 
go anywhere so I failed to see my printf.
Still, is this how it is supposed to be? I naively assume that if we don't send 
SIGHUP in attach scenario we should not send it in launch scenario too.
Thanks,Eugene

> From: lab...@google.com
> Date: Wed, 30 Mar 2016 10:22:33 +0100
> Subject: Re: [lldb-dev] SBProcess::Detach kills target
> To: eugen...@hotmail.com
> CC: jing...@apple.com; lldb-dev@lists.llvm.org
> 
> So I have made a small test program (which does nothing but spin in a
> loop), and indeed it is the SIGHUP that kills it after detach. If the
> test program blocks the signal, then it continues running even after
> detach:
> $ cat a.c
> #include 
> #include 
> 
> int main() {
> signal(SIGHUP, SIG_IGN);
> for (;;) sleep(1);
> }
> $ cc a.c -g
> $ ps -A | grep a.out
> $ ~/ll/build/dbg/bin/lldb ./a.out
> (lldb) target create "./a.out"
> Current executable set to './a.out' (x86_64).
> (lldb) b 6
> Breakpoint 1: where = a.out`main + 19 at a.c:6, address = 0x00400590
> (lldb) r
> Process 13416 launched: './a.out' (x86_64)
> Process 13416 stopped
> * thread #1: tid = 13416, 0x00400590 a.out`main + 19 at a.c:6,
> name = 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400590 a.out`main + 19 at a.c:6
>3
>4   int main() {
>5  signal(SIGHUP, SIG_IGN);
> -> 6  for (;;) sleep(1);
>7   }
> (lldb) detach
> Process 13416 detached
> (lldb) q
> $ ps -A | grep a.out
>  13416 ?00:00:00 a.out
> 
> 
> On 29 March 2016 at 18:38, Eugene Birukov  wrote:
> > I believe this is not SIGHUP on debugger exit. I am using my own C++ program
> > that calls into LLDB API. So, this program is still alive after calling
> > SBProcess::Detach() but the target dies. Also, the target intercepts SIGHUP
> > to do cleanup before exiting. I put printf there, it was not hit.
> The fact whether your program is alive irrelevant. What matters is
> that by cleaning up the process structure, we will also close the
> master end of the pty used for inferior communication, and this is
> what causes the SIGHUP. For that reason you also cannot use a printf
> to do diagnostics as the output has nowhere to go. Note that lldb's
> behavior here will be different from gdb as gdb does not do stdio
> redirection, and has the inferior share the pty with the debugger (in
> which case your program will die when you close the terminal window).
> 
> >
> > I tried interactive LLDB, the target is not there:
> >
> > Process 49145 stopped
> > * thread #1: tid = 49145, ..., stop reason = signal SIGSTOP
> > frame #0: 0x76a5bbed libc.so.6 at syscall-template.S:81
> > (lldb) detach
> > Process 49145 detached
> > (lldb) q
> > eugene@EUGENEBI-L1:~/tmp$ ps
> >   PID TTY  TIME CMD
> > 30714 pts/17   00:00:00 bash
> > 49259 pts/17   00:00:00 ps
> Note that the inferior will not show up here even if it exists, as ps
> will only list the processes with the same tty, but at this point the
> inferior process has no tty.
> 
> Good luck with your investigations.
> 
> pl
  

___
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] SBProcess::Detach kills target

[Eugene Birukov via lldb-dev]

Right, my bad. The problem was that when debugger detaches the stdio does not 
go anywhere so I failed to see my printf.
Still, is this how it is supposed to be? I naively assume that if we don't send 
SIGHUP in attach scenario we should not send it in launch scenario too.
Thanks,Eugene

> From: lab...@google.com
> Date: Wed, 30 Mar 2016 10:22:33 +0100
> Subject: Re: [lldb-dev] SBProcess::Detach kills target
> To: eugen...@hotmail.com
> CC: jing...@apple.com; lldb-dev@lists.llvm.org
> 
> So I have made a small test program (which does nothing but spin in a
> loop), and indeed it is the SIGHUP that kills it after detach. If the
> test program blocks the signal, then it continues running even after
> detach:
> $ cat a.c
> #include 
> #include 
> 
> int main() {
> signal(SIGHUP, SIG_IGN);
> for (;;) sleep(1);
> }
> $ cc a.c -g
> $ ps -A | grep a.out
> $ ~/ll/build/dbg/bin/lldb ./a.out
> (lldb) target create "./a.out"
> Current executable set to './a.out' (x86_64).
> (lldb) b 6
> Breakpoint 1: where = a.out`main + 19 at a.c:6, address = 0x00400590
> (lldb) r
> Process 13416 launched: './a.out' (x86_64)
> Process 13416 stopped
> * thread #1: tid = 13416, 0x00400590 a.out`main + 19 at a.c:6,
> name = 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400590 a.out`main + 19 at a.c:6
>3
>4   int main() {
>5  signal(SIGHUP, SIG_IGN);
> -> 6  for (;;) sleep(1);
>7   }
> (lldb) detach
> Process 13416 detached
> (lldb) q
> $ ps -A | grep a.out
>  13416 ?00:00:00 a.out
> 
> 
> On 29 March 2016 at 18:38, Eugene Birukov  wrote:
> > I believe this is not SIGHUP on debugger exit. I am using my own C++ program
> > that calls into LLDB API. So, this program is still alive after calling
> > SBProcess::Detach() but the target dies. Also, the target intercepts SIGHUP
> > to do cleanup before exiting. I put printf there, it was not hit.
> The fact whether your program is alive irrelevant. What matters is
> that by cleaning up the process structure, we will also close the
> master end of the pty used for inferior communication, and this is
> what causes the SIGHUP. For that reason you also cannot use a printf
> to do diagnostics as the output has nowhere to go. Note that lldb's
> behavior here will be different from gdb as gdb does not do stdio
> redirection, and has the inferior share the pty with the debugger (in
> which case your program will die when you close the terminal window).
> 
> >
> > I tried interactive LLDB, the target is not there:
> >
> > Process 49145 stopped
> > * thread #1: tid = 49145, ..., stop reason = signal SIGSTOP
> > frame #0: 0x76a5bbed libc.so.6 at syscall-template.S:81
> > (lldb) detach
> > Process 49145 detached
> > (lldb) q
> > eugene@EUGENEBI-L1:~/tmp$ ps
> >   PID TTY  TIME CMD
> > 30714 pts/17   00:00:00 bash
> > 49259 pts/17   00:00:00 ps
> Note that the inferior will not show up here even if it exists, as ps
> will only list the processes with the same tty, but at this point the
> inferior process has no tty.
> 
> Good luck with your investigations.
> 
> pl
  ___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to enumerate stopped threads in C++ API?

[Eugene Birukov via lldb-dev]

Thanks a lot! We'll try to profile what is going on, I'll let you know if we 
find something.Skipping locks if possible is always nice. I'll look into 
getting collection approach.
Eugene

> Subject: Re: [lldb-dev] How to enumerate stopped threads in C++ API?
> From: gclay...@apple.com
> Date: Thu, 3 Mar 2016 12:41:16 -0800
> CC: lldb-dev@lists.llvm.org; rd...@microsoft.com
> To: eugen...@hotmail.com
> 
> Each call into the lldb::SB* API will take a target lock and possible a 
> process read/write lock. 
> 
> We do have a SBThreadCollection class that we can use. Feel free to add an 
> API like this to SBProcess:
> 
> 
> class SBProcess
> {
> SBThreadCollection GetThreads();
> };
> 
> class SBThreadCollection
> {
> SBThreadCollection GetThreadsWithStopReasons();
> };
> 
> 
> The current API on process SBProcess::GetNumThreads() and 
> SBProcess::GetThreadAtIndex() might have issues if you are doing things like 
> evaluating an expression on another thread where you might request the number 
> of threads and get 10, but then an expression runs on another thread and 
> there are now maybe 8 or 12 threads, and then you call 
> SBProcess::GetThreadAtIndex() and it might return you results that are 
> different that what you wanted. If we return all threads at once, we won't 
> run into this issue. Then you can have SBThreadCollection add a new methods 
> to return a new list for all threads with stop reasons.
> 
> That being said, hundreds of threads should not cause a huge bottleneck for 
> single stop, but if you doing it many many many times it could be. 
> 
> Greg Clayton
> 
> > On Mar 3, 2016, at 9:54 AM, Eugene Birukov via lldb-dev 
> > <lldb-dev@lists.llvm.org> wrote:
> > 
> > Hi,
> > 
> > I am working on a custom debugger on Linux and I am using LLDB C++ API for 
> > that. So far, from the functionality point of view the life is good, but I 
> > am running into severe performance issue.
> > 
> > The problem is that the target application has literally hundreds of 
> > threads, and when the target process stops, I need to identify all the 
> > threads that have non-trivial stop reason. So, I am doing something like 
> > that:
> > 
> > // Loop over threads
> > int numThreads = m_Process.GetNumThreads();
> > for (int threadIndex = 0; threadIndex < numThreads; ++threadIndex)
> > {
> > // Inspect the thread state
> > sbThread = m_Process.GetThreadAtIndex(threadIndex);
> > stopReason = sbThread.GetStopReason();
> > ...
> > 
> > 
> > Well, this loop turns out to be a bottleneck. 
> > 
> > So, is there any way to find all the stopped threads without iterating over 
> > the whole world?
> > 
> > Thanks,
> > Eugene
> > 
> > 
> > ___
> > 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

[lldb-dev] How to load core on a different machine?

[Eugene Birukov via lldb-dev]

Hi,
I am using LLDB-3.7 on Ubuntu Linux.
I have a core dump file and all shared libraries from my server but I want to 
investigate them on a dev box. But I fail to correctly load it in LLDB - it 
shows wrong stacks. I.e. I am looking for something equivalent to GDB commands 
"set solib-absolute-prefix" and "set solib-search-path".
I tried to play with "target modules search-paths insert", but I cannot use it 
if there is no target and I cannot load core after I have a target - not sure 
what this command is intended to do...
Now, what I really need to do - it is load core in my custom debugger that uses 
C++ API. Here I made some progress:Create target with NULL file nameLoad core 
using SBTarget::LoadCore()Manually load all executables - the initial a.out and 
all the shared libraries using SBTarget::AddModule() and 
SBTarget::SetModuleLoadAddress()This kind of works, but there are two 
problems:How would I find the list of modules and addresses to load from the 
core file? Currently I did it by loading core in the debugger on the server, 
but this is not acceptable for production run...LLDB correctly prints stacks 
and resolves symbols, but I cannot disassembly any code - the ReadMemory retuns 
all zeroes from code addresses.
Any help would be greatly appreciated.
Thanks,Eugene ___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Is there a way to inspect signaled stack?

[Eugene Birukov via lldb-dev]

Hi,
I am running on Ubuntu Linux. I am using a custom debugger built upon LLDB C++ 
API using version 3.7.
The target program issues a lot of "legitimate" SIGSEGV signals that it handles 
itself. Its signal handler runs on a separate stack (it uses sigaltstack() and 
SA_ONSTACK). Now, sometimes a bug in the program causes SIGSEGV that the 
handler cannot deal with and it crashes. Now, when I load the core, I see stack 
frames for the signal handler stack, but what I really need are frames for the 
signaled stack. 
Of course, I have access to siginfo_t and ucontext_t, so I can try to use some 
unwind library, but that approach is far from ideal - the LLDB already has the 
unwinder. So, what should I do to get the set of SBFrame's that I can query 
about local variables, etc.? I mean, something like .cxr command in Windbg 
would be really handy... 
Thanks,Eugene ___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

[Eugene Birukov via lldb-dev]

Will do!

> From: lab...@google.com
> Date: Tue, 13 Oct 2015 09:40:28 +0100
> Subject: Re: [lldb-dev] Thread resumes with stale signal after executing 
> InferiorCallMmap
> To: eugen...@hotmail.com
> CC: lldb-dev@lists.llvm.org; jing...@apple.com
> 
> Sure, fair enough.
> 
> If you have made a small repro case already though, it would be great
> if you could file a bug about it, so we don't forget it.
> 
> pl
> 
> On 12 October 2015 at 23:23, Eugene Birukov  wrote:
> > I tried to repro it using standard LLDB client on a simple program that I
> > could share. Well, the problem does not exactly repro as in my case - i.e.
> > the signal is not re-delivered to the thread. But LLDB does get confused
> > state: the program continues but at the same time lldb shows its prompt as
> > if the program were stopped. I.e. the recovery from signal during expression
> > evaluation is buggy. Sorry, I am not sure that I will have time to look into
> > it deeper - it is not a blocker for me at this time.
> >
> >> From: lab...@google.com
> >> Date: Mon, 12 Oct 2015 13:25:45 +0100
> >> Subject: Re: [lldb-dev] Thread resumes with stale signal after executing
> >> InferiorCallMmap
> >> To: eugen...@hotmail.com
> >> CC: lldb-dev@lists.llvm.org; jing...@apple.com
> >>
> >> On 8 October 2015 at 17:08, Eugene Birukov  wrote:
> >> > Yes, that's exactly what I see, thanks a lot!
> >> You're wellcome.
> >>
> >> >
> >> > Does it explain why I see SIGILL reappear when I let process continue
> >> > after
> >> > mmap execution? I.e. do I need to look into this more?
> >> No. That could still be a bug somewhere. Feel free to look into it..
> >>
> >> pl
  ___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

[Eugene Birukov via lldb-dev]

Even on Linux call to InferiorCallMmap does not fail consistently. In many 
cases it survives. I just happened to have 100% repro on this specific 
breakpoint in my specific problem. I.e. the burden of investigation is on me, 
since I cannot share my program. 
But I am not looking at this SIG_ILL yet. Whatever the problem is with mmap - 
the client must not carry this signal past expression evaluation. I.e. I 
believe that we can construct any arbitrary function that causes signal, call 
it from evaluate expression, and then continue would fail. I suspect that this 
problem might be applicable to any POSIX platform.
As it turned out, my initial analysis was incorrect. m_resume_signal is 
calculated from StopInfo::m_value (now I wonder why do we need two fields for 
that?). And after mmap call, m_stop_info on the thread is null. So, my current 
theory is that there is an event with SIG_ILL that is stuck in the broadcaster 
and is picked up and processed much later.

> Subject: Re: [lldb-dev] Thread resumes with stale signal after executing 
> InferiorCallMmap
> From: jing...@apple.com
> Date: Wed, 7 Oct 2015 15:08:18 -0700
> CC: lldb-dev@lists.llvm.org
> To: eugen...@hotmail.com
> 
> Does it only happen for InferiorCallMmap, or does an expression evaluation 
> that crashes in general set a bad signal on resume?  I don't see this 
> behavior in either case on OS X, so it may be something in the Linux support. 
>  Be interesting to figure out why it behaves this way on Linux, so whatever 
> we do we're implementing it consistently.
> 
> Jim
> 
> 
> 
> > On Oct 7, 2015, at 12:03 PM, Eugene Birukov via lldb-dev 
> > <lldb-dev@lists.llvm.org> wrote:
> > 
> > Hi,
> >  
> > I am using LLDB 3.7.0 C++ API. My program stops at a certain breakpoint and 
> > if I call SBFrame::EvaluateExpression() there, when I let it go it 
> > terminates with SIG_ILL on an innocent thread. I dug up into this, and 
> > there seems to be two independent problems there, this mail is about the 
> > second one.
> >  
> > • EvaluateExpression() calls Process::CanJIT() which in turn executes 
> > mmap() on the inferior. This mmap gets SIG_ILL because execution starts at 
> > address which is 2 bytes before the very first mmap instruction. I am still 
> > looking why LLDB server decided to do that - I am pretty sure that the 
> > client asked to set the program counter to correct value.
> > • So, the thread execution terminates and the signal is recorded on 
> > Thread::m_resume_signal. This field is not cleared during 
> > Thread::RestoreThreadStateFromCheckpoint() and fires when I resume the 
> > program after breakpoint.
> >  
> > So, what would be the best way to deal with the situation? Should I add 
> > "resume signal" field to ThreadStateCheckpoint? Or would StopInfo be a 
> > better place for that? Or something else?
> >  
> > Thanks,
> > Eugene
> > ___
> > 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

[lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

[Eugene Birukov via lldb-dev]

Hi,
 
I am using LLDB 3.7.0 C++ API. My program stops at a certain breakpoint and if 
I call SBFrame::EvaluateExpression() there, when I let it go it terminates with 
SIG_ILL on an innocent thread. I dug up into this, and there seems to be two 
independent problems there, this mail is about the second one.
 
EvaluateExpression() calls Process::CanJIT() which in turn executes mmap() on 
the inferior. This mmap gets SIG_ILL because execution starts at address which 
is 2 bytes before the very first mmap instruction. I am still looking why LLDB 
server decided to do that - I am pretty sure that the client asked to set the 
program counter to correct value.So, the thread execution terminates and the 
signal is recorded on Thread::m_resume_signal. This field is not cleared during 
Thread::RestoreThreadStateFromCheckpoint() and fires when I resume the program 
after breakpoint. 
So, what would be the best way to deal with the situation? Should I add "resume 
signal" field to ThreadStateCheckpoint? Or would StopInfo be a better place for 
that? Or something else?
 
Thanks,
Eugene
  ___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev