https://llvm.org/bugs/show_bug.cgi?id=26289
Bug ID: 26289
Summary: lldb host crashes with allocation failure when
attaching to a remote android target
Product: lldb
Version: unspecified
Hardware: Other
OS: other
Status: NEW
Severity: release blocker
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: luke.drumm...@codeplay.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
Created attachment 15704
--> https://llvm.org/bugs/attachment.cgi?id=15704&action=edit
attempting to attach to a remote android process with all logging enabled
lldb as of r258122 is crashing during process attach to a remote Android x86_64
target due to a `std::bad_alloc` being raised during the process of loading
symbols.
## Short log (log enable lldb all is attached)
```
(lldb) log enable lldb process
(lldb) log enable lldb language
(lldb) log enable lldb expression
(lldb) platform select remote-android
Platform: remote-android
Connected: no
(lldb) platform connect connect://localhost:1234
Platform: remote-android
Triple: x86_64-*-linux
OS Version: 23.0.0 (3.10.0+)
Kernel: #24 PREEMPT Fri Oct 30 16:57:39 PDT 2015
Hostname: localhost
Connected: yes
WorkingDir: /
(lldb) process attach -p 2744
Process::SetPrivateState (connected)
Process::ControlPrivateStateThread (signal = 4)
Sending control event of type: 4.
Process::RunPrivateStateThread (arg = 0xb12b30, pid = 0) thread starting...
Process::WaitForEventsPrivate (timeout = (nil), event_sp)...
Process::RunPrivateStateThread (arg = 0xb12b30, pid = 0) got a control event: 4
Process::WaitForEventsPrivate (timeout = (nil), event_sp)...
Process::ShouldBroadcastEvent (0xb34290) => new state: connected, last
broadcast state: connected - YES
Process::HandlePrivateEvent (pid = 0) broadcasting new state connected (old
state unloaded) to hijacked
Process::SetPublicState (state = attaching, restarted = 0)
Process::WaitForEventsPrivate (timeout = (nil), event_sp)...
Process::AttachCompletionHandler::AttachCompletionHandler process=0xb12b30,
exec_count=0
Process::WaitForProcessToStop (timeout = (nil))
Process::WaitForStateChangedEvents (timeout = (nil), event_sp)...
Process::SetPublicState (state = connected, restarted = 0)
Process::WaitForStateChangedEvents (timeout = (nil), event_sp) => connected
Process::WaitForStateChangedEvents (timeout = (nil), event_sp)...
Process::SetPrivateState (stopped)
Process::SetPrivateState (stopped) stop_id = 1
Process::AttachCompletionHandler::PerformAction called with state stopped (5)
Process::AttachCompletionHandler::PerformAction state stopped: no more execs
expected to start, continuing with attach
Process::CompleteAttach()
Process::CompleteAttach replacing process architecture with DidAttach()
architecture: x86_64--linux-android
ProcessGDBRemote::GetLoadedModuleList
ProcessGDBRemote::GetLoadedModuleList
ProcessGDBRemote::GetLoadedModuleList
ProcessGDBRemote::GetLoadedModuleList
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
```
## Backtrace
```
* thread #4: tid = 9129, 0x00007f51a4374cc9 libc.so.6`gsignal + 57, name =
'intern-state', stop reason = signal SIGABRT
* frame #0: 0x00007f51a4374cc9 libc.so.6`gsignal + 57
frame #1: 0x00007f51a43780d8 libc.so.6`abort + 328
frame #2: 0x00007f51a4763535
libstdc++.so.6`__gnu_cxx::__verbose_terminate_handler() + 341
frame #3: 0x00007f51a47616d6 libstdc++.so.6`??? + 6
frame #4: 0x00007f51a4761703 libstdc++.so.6`std::terminate() + 19
frame #5: 0x00007f51a4761922 libstdc++.so.6`__cxa_throw + 114
frame #6: 0x00007f51a4761e0d libstdc++.so.6`operator new(unsigned long) +
125
frame #7: 0x00007f51a5683a82
liblldb.so.3.9.0`__gnu_cxx::new_allocator<unsigned
char>::allocate(this=0x00007f519efc1e40, __n=4720169055844,
(null)=0x0000000000000000) + 60 at new_allocator.h:104
frame #8: 0x00007f51a56836d7 liblldb.so.3.9.0`std::_Vector_base<unsigned
char, std::allocator<unsigned char> >::_M_allocate(this=0x00007f519efc1e40,
__n=4720169055844) + 47 at stl_vector.h:168
frame #9: 0x00007f51a592bb91 liblldb.so.3.9.0`std::_Vector_base<unsigned
char, std::allocator<unsigned char>
>::_M_create_storage(this=0x00007f519efc1e40, __n=4720169055844) + 35 at
stl_vector.h:181
frame #10: 0x00007f51a59294ae liblldb.so.3.9.0`std::_Vector_base<unsigned
char, std::allocator<unsigned char> >::_Vector_base(this=0x00007f519efc1e40,
__n=4720169055844, __a=0x00007f5194046908) + 58 at stl_vector.h:136
frame #11: 0x00007f51a668725f liblldb.so.3.9.0`std::vector<unsigned char,
std::allocator<unsigned char> >::vector(this=0x00007f519efc1e40,
__n=4720169055844, __value=0x00007f519efc1ebc, __a=0x00007f5194046908) + 47 at
stl_vector.h:283
frame #12: 0x00007f51a6696d59 liblldb.so.3.9.0`std::vector<unsigned char,
std::allocator<unsigned char> >::_M_fill_assign(this=0x00007f5194046908,
__n=4720169055844, __val=0x00007f519efc1ebc) + 79 at vector.tcc:223
frame #13: 0x00007f51a6696b8b liblldb.so.3.9.0`std::vector<unsigned char,
std::allocator<unsigned char> >::assign(this=0x00007f5194046908,
__n=4720169055844, __val=0x00007f519efc1ebc) + 43 at stl_vector.h:480
frame #14: 0x00007f51a669684f
liblldb.so.3.9.0`lldb_private::DataBufferHeap::DataBufferHeap(this=0x00007f5194046900,
n=4720169055844, ch='\0') + 121 at DataBufferHeap.cpp:30
frame #15: 0x00007f51a682822b
liblldb.so.3.9.0`lldb_private::ObjectFile::ReadMemory(process_sp=0x00007f519efc1f80,
addr=140038451027968, byte_size=4720169055844) + 105 at ObjectFile.cpp:435
frame #16: 0x00007f51a6a223c8
liblldb.so.3.9.0`ObjectFileELF::SetDataWithReadMemoryFallback(this=0x00007f5194047750,
dst=0x00007f519efc2290, offset=3968549781524, length=751619274320) + 200 at
ObjectFileELF.cpp:1756
frame #17: 0x00007f51a6a2eca3 liblldb.so.3.9.0`unsigned long
std::_Mem_fn<unsigned long (ObjectFileELF::*)(lldb_private::DataExtractor&,
unsigned long, unsigned long)>::operator(this=0x00007f51940468b0,
__object=0x00007f5194047750, (null)=0x00007f519efc2290,
(null)=0x00007f519efc2108,
(null)=0x00007f519efc2100)<lldb_private::DataExtractor&, unsigned long,
unsigned long, void>(ObjectFileELF*, lldb_private::DataExtractor&, unsigned
long&&, unsigned long&&) const + 167 at functional:601
frame #18: 0x00007f51a6a2de54 liblldb.so.3.9.0`unsigned long
std::_Bind<std::_Mem_fn<unsigned long
(ObjectFileELF::*)(lldb_private::DataExtractor&, unsigned long, unsigned long)>
(ObjectFileELF*, std::_Placeholder<1>, std::_Placeholder<2>,
std::_Placeholder<3>)>::__call<unsigned long, lldb_private::DataExtractor&,
unsigned long&&, unsigned long&&, 0ul, 1ul, 2ul, 3ul>(this=0x00007f51940468b0,
__args=0x00007f519efc20b0, (null)=_Index_tuple<0ul, 1ul, 2ul, 3ul> at
0x00007f519efc2080) + 206 at functional:1296
frame #19: 0x00007f51a6a2c6f7 liblldb.so.3.9.0`unsigned long
std::_Bind<std::_Mem_fn<unsigned long
(ObjectFileELF::*)(lldb_private::DataExtractor&, unsigned long, unsigned long)>
(ObjectFileELF*, std::_Placeholder<1>, std::_Placeholder<2>,
std::_Placeholder<3>)>::operator(this=0x00007f51940468b0,
(null)=0x00007f519efc2290, (null)=0x00007f519efc2108,
(null)=0x00007f519efc2100)<lldb_private::DataExtractor&, unsigned long,
unsigned long, unsigned long>(lldb_private::DataExtractor&, unsigned long&&,
unsigned long&&) + 115 at functional:1355
frame #20: 0x00007f51a6a2b2a5
liblldb.so.3.9.0`std::_Function_handler<unsigned long
(lldb_private::DataExtractor&, unsigned long, unsigned long),
std::_Bind<std::_Mem_fn<unsigned long
(ObjectFileELF::*)(lldb_private::DataExtractor&, unsigned long, unsigned long)>
(ObjectFileELF*, std::_Placeholder<1>, std::_Placeholder<2>,
std::_Placeholder<3>)> >::_M_invoke(__functor=0x00007f519efc2370,
__args#0=0x00007f519efc2290, __args#1=3968549781524, __args#2=751619274320) +
103 at functional:2057
frame #21: 0x00007f51a6a294a0 liblldb.so.3.9.0`std::function<unsigned long
(lldb_private::DataExtractor&, unsigned long, unsigned
long)>::operator(this=0x00007f519efc2370, __args#0=0x00007f519efc2290,
__args#1=3968549781524, __args#2=751619274320)(lldb_private::DataExtractor&,
unsigned long, unsigned long) const + 118 at functional:2471
frame #22: 0x00007f51a6a2190a
liblldb.so.3.9.0`ObjectFileELF::GetSectionHeaderInfo(section_headers=0x00007f5194047900,
set_data=0x00007f519efc2370, header=0x00007f5194047880,
uuid=0x00007f51940478c0, gnu_debuglink_file=0x00007f51940478d8,
gnu_debuglink_crc=0x00007f51940478e0, arch_spec=0x00007f5194047950)> const&,
elf::ELFHeader const&, lldb_private::UUID&, std::string&, unsigned int&,
lldb_private::ArchSpec&) + 1068 at ObjectFileELF.cpp:1599
frame #23: 0x00007f51a6a22295
liblldb.so.3.9.0`ObjectFileELF::ParseSectionHeaders(this=0x00007f5194047750) +
269 at ObjectFileELF.cpp:1736
frame #24: 0x00007f51a6a27ed7
liblldb.so.3.9.0`ObjectFileELF::GetArchitecture(this=0x00007f5194047750,
arch=0x00007f519efc24d0) + 129 at ObjectFileELF.cpp:3257
frame #25: 0x00007f51a6a1dfe8
liblldb.so.3.9.0`ObjectFileELF::CreateMemoryInstance(module_sp=0x00007f519efc2650,
data_sp=0x00007f519efc2640, process_sp=0x00007f519efc2710,
header_addr=140038451027968) + 320 at ObjectFileELF.cpp:488
frame #26: 0x00007f51a6827697
liblldb.so.3.9.0`lldb_private::ObjectFile::FindPlugin(module_sp=0x00007f519efc2650,
process_sp=0x00007f519efc2710, header_addr=140038451027968,
data_sp=0x00007f519efc2640) + 241 at ObjectFile.cpp:175
frame #27: 0x00007f51a66e7eb6
liblldb.so.3.9.0`lldb_private::Module::GetMemoryObjectFile(this=0x00007f5194046b50,
process_sp=0x00007f519efc2710, header_addr=140038451027968,
error=0x00007f519efc2700, size_to_read=512) + 474 at Module.cpp:368
frame #28: 0x00007f51a689b434
liblldb.so.3.9.0`lldb_private::Process::ReadModuleFromMemory(this=0x00000000027efdb0,
file_spec=0x00007f519403eec0, header_addr=140038451027968, size_to_read=512) +
356 at Process.cpp:2848
frame #29: 0x00007f51a6c9ae41
liblldb.so.3.9.0`lldb_private::DynamicLoader::LoadModuleAtAddress(this=0x00007f5194005720,
file=0x00007f519403eec0, link_map_addr=140038450237664,
base_addr=140038451027968, base_addr_is_offset=true) + 777 at
DynamicLoader.cpp:212
frame #30: 0x00007f51a69d69b9
liblldb.so.3.9.0`DynamicLoaderPOSIXDYLD::LoadAllCurrentModules(this=0x00007f5194005720)
+ 677 at DynamicLoaderPOSIXDYLD.cpp:521
frame #31: 0x00007f51a69d5102
liblldb.so.3.9.0`DynamicLoaderPOSIXDYLD::DidAttach(this=0x00007f5194005720) +
1432 at DynamicLoaderPOSIXDYLD.cpp:181
frame #32: 0x00007f51a689d4d8
liblldb.so.3.9.0`lldb_private::Process::CompleteAttach(this=0x00000000027efdb0)
+ 1406 at Process.cpp:3439
frame #33: 0x00007f51a689c5cc
liblldb.so.3.9.0`lldb_private::Process::AttachCompletionHandler::PerformAction(this=0x00000000027e9710,
event_sp=0x00007f519efc2e10) + 484 at Process.cpp:3190
frame #34: 0x00007f51a689f511
liblldb.so.3.9.0`lldb_private::Process::HandlePrivateEvent(this=0x00000000027efdb0,
event_sp=0x00007f519efc2e10) + 143 at Process.cpp:4180
frame #35: 0x00007f51a689fe4b
liblldb.so.3.9.0`lldb_private::Process::RunPrivateStateThread(this=0x00000000027efdb0,
is_secondary_thread=false) + 1191 at Process.cpp:4425
frame #36: 0x00007f51a689f99a
liblldb.so.3.9.0`lldb_private::Process::PrivateStateThread(arg=0x00007fff1c929cd0)
+ 48 at Process.cpp:4312
frame #37: 0x00007f51a667ebe7
liblldb.so.3.9.0`lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(arg=0x0000000002811e80)
+ 197 at HostNativeThreadBase.cpp:81
frame #38: 0x00007f51a4a0f182 libpthread.so.0`start_thread + 194
frame #39: 0x00007f51a443847d libc.so.6`clone + 109
```
The backtrace shows an absurdly large value being passed to allocators in frame
15/16 (4.2 TiB). This trace touches codepaths introduced in
[r258122](http://reviews.llvm.org/D16107). Before this revision, attach was
successful so I'm working on the assumption that the mentioned revision has
introduced a regression, or unearthed a previously unseen issue with the VDSO
loader. Note also that this bug is not triggered on android i686 (AFAICS)
Build info is also attached.
--
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
