Skip to content

[lldb] The test TestCancelAttach.py hangs on Windows host with Linux target #115618

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
slydiman opened this issue Nov 9, 2024 · 2 comments
Open
Labels

Comments

@slydiman
Copy link
Contributor

slydiman commented Nov 9, 2024

Issue 1:
TestCancelAttach.py, line 33
The call self.target.AttachToProcessWithName(lldb.SBListener(), "LLDB-No-Such-Process", True, self.error) in the AttachThread never return in case of Windows host and Linux target.

Issue 2:
The test failed here

if thread.is_alive():
    self.fail("The attach thread is alive after timeout interval")

but the main thread will still wait for the AttachThread until timeout 10 min.

The issue 1 is most important.
The callstack is the following

m_events_condition.wait(lock);
lldb_private::Listener::GetEventInternal(const lldb_private::Timeout<std::ratio<1,1000000>> & timeout, lldb_private::Broadcaster * broadcaster, unsigned int event_type_mask, std::shared_ptr<lldb_private::Event> & event_sp) at \llvm-project\lldb\source\Utility\Listener.cpp(275)
lldb_private::Listener::GetEventForBroadcasterWithType(lldb_private::Broadcaster * broadcaster, unsigned int event_type_mask, std::shared_ptr<lldb_private::Event> & event_sp, const lldb_private::Timeout<std::ratio<1,1000000>> & timeout) at \llvm-project\lldb\source\Utility\Listener.cpp(300)
lldb_private::Process::GetStateChangedEvents(std::shared_ptr<lldb_private::Event> & event_sp, const lldb_private::Timeout<std::ratio<1,1000000>> & timeout, std::shared_ptr<lldb_private::Listener> hijack_listener_sp) at \llvm-project\lldb\source\Target\Process.cpp(980)
lldb_private::Process::WaitForProcessToStop(const lldb_private::Timeout<std::ratio<1,1000000>> & timeout, std::shared_ptr<lldb_private::Event> * event_sp_ptr, bool wait_always, std::shared_ptr<lldb_private::Listener> hijack_listener_sp, lldb_private::Stream * stream, bool use_run_lock, SelectMostRelevant select_most_relevant) at \llvm-project\lldb\source\Target\Process.cpp(690)
lldb_private::Target::Attach(lldb_private::ProcessAttachInfo & attach_info, lldb_private::Stream * stream) at \llvm-project\lldb\source\Target\Target.cpp(3551)
AttachToProcess(lldb_private::ProcessAttachInfo & attach_info, lldb_private::Target & target) at \llvm-project\lldb\source\API\SBTarget.cpp(94)
lldb::SBTarget::AttachToProcessWithName(lldb::SBListener & listener, const char * name, bool wait_for, lldb::SBError & error) at \llvm-project\lldb\source\API\SBTarget.cpp(519)
_wrap_SBTarget_AttachToProcessWithName(_object * self, _object * args) at \tools\lldb\bindings\python\LLDBWrapPython.cpp(65404)

Note process_sp = platform_sp->Attach(attach_info, GetDebugger(), this, error); at \llvm-project\lldb\source\Target\Target.cpp(3526)
runs gdbserver and puts vAttachWait command with LLDB-No-Such-Process to the event queue. But this packet never sent to the target (and no response). Something is wrong with listeners/broadcasters.

Unfortunately I cannot debug (compare) it on Linux host right now.

@slydiman slydiman added the lldb label Nov 9, 2024
@llvmbot
Copy link
Member

llvmbot commented Nov 9, 2024

@llvm/issue-subscribers-lldb

Author: Dmitry Vasilyev (slydiman)

Issue 1: TestCancelAttach.py, line 33 The call `self.target.AttachToProcessWithName(lldb.SBListener(), "LLDB-No-Such-Process", True, self.error)` in the AttachThread never return in case of Windows host and Linux target.

Issue 2:
The test failed here

if thread.is_alive():
    self.fail("The attach thread is alive after timeout interval")

but the main thread will still wait for the AttachThread until timeout 10 min.

The issue 1 is most important.
The callstack on local Windows is the following

return Status::FromErrorString("attach by name is not supported");
lldb_private::Process::DoAttachToProcessWithName(const char * process_name, const lldb_private::ProcessAttachInfo &amp; attach_info) at \llvm-project\lldb\include\lldb\Target\Process.h(1011)
lldb_private::Process::Attach(lldb_private::ProcessAttachInfo &amp; attach_info) at \llvm-project\lldb\source\Target\Process.cpp(2983)
lldb_private::PlatformWindows::Attach(lldb_private::ProcessAttachInfo &amp; attach_info, lldb_private::Debugger &amp; debugger, lldb_private::Target * target, lldb_private::Status &amp; error) at \llvm-project\lldb\source\Plugins\Platform\Windows\PlatformWindows.cpp(562)
lldb_private::Target::Attach(lldb_private::ProcessAttachInfo &amp; attach_info, lldb_private::Stream * stream) at \llvm-project\lldb\source\Target\Target.cpp(3526)
AttachToProcess(lldb_private::ProcessAttachInfo &amp; attach_info, lldb_private::Target &amp; target) at \llvm-project\lldb\source\API\SBTarget.cpp(94)
lldb::SBTarget::AttachToProcessWithName(lldb::SBListener &amp; listener, const char * name, bool wait_for, lldb::SBError &amp; error) at \llvm-project\lldb\source\API\SBTarget.cpp(519)
_wrap_SBTarget_AttachToProcessWithName(_object * self, _object * args) at \tools\lldb\bindings\python\LLDBWrapPython.cpp(65404)

The callstack in case of Windows host and Linux target is the following

m_events_condition.wait(lock);
lldb_private::Listener::GetEventInternal(const lldb_private::Timeout&lt;std::ratio&lt;1,1000000&gt;&gt; &amp; timeout, lldb_private::Broadcaster * broadcaster, unsigned int event_type_mask, std::shared_ptr&lt;lldb_private::Event&gt; &amp; event_sp) at \llvm-project\lldb\source\Utility\Listener.cpp(275)
lldb_private::Listener::GetEventForBroadcasterWithType(lldb_private::Broadcaster * broadcaster, unsigned int event_type_mask, std::shared_ptr&lt;lldb_private::Event&gt; &amp; event_sp, const lldb_private::Timeout&lt;std::ratio&lt;1,1000000&gt;&gt; &amp; timeout) at \llvm-project\lldb\source\Utility\Listener.cpp(300)
lldb_private::Process::GetStateChangedEvents(std::shared_ptr&lt;lldb_private::Event&gt; &amp; event_sp, const lldb_private::Timeout&lt;std::ratio&lt;1,1000000&gt;&gt; &amp; timeout, std::shared_ptr&lt;lldb_private::Listener&gt; hijack_listener_sp) at \llvm-project\lldb\source\Target\Process.cpp(980)
lldb_private::Process::WaitForProcessToStop(const lldb_private::Timeout&lt;std::ratio&lt;1,1000000&gt;&gt; &amp; timeout, std::shared_ptr&lt;lldb_private::Event&gt; * event_sp_ptr, bool wait_always, std::shared_ptr&lt;lldb_private::Listener&gt; hijack_listener_sp, lldb_private::Stream * stream, bool use_run_lock, SelectMostRelevant select_most_relevant) at \llvm-project\lldb\source\Target\Process.cpp(690)
lldb_private::Target::Attach(lldb_private::ProcessAttachInfo &amp; attach_info, lldb_private::Stream * stream) at \llvm-project\lldb\source\Target\Target.cpp(3551)
AttachToProcess(lldb_private::ProcessAttachInfo &amp; attach_info, lldb_private::Target &amp; target) at \llvm-project\lldb\source\API\SBTarget.cpp(94)
lldb::SBTarget::AttachToProcessWithName(lldb::SBListener &amp; listener, const char * name, bool wait_for, lldb::SBError &amp; error) at \llvm-project\lldb\source\API\SBTarget.cpp(519)
_wrap_SBTarget_AttachToProcessWithName(_object * self, _object * args) at \tools\lldb\bindings\python\LLDBWrapPython.cpp(65404)

Note process_sp = platform_sp-&gt;Attach(attach_info, GetDebugger(), this, error); at \llvm-project\lldb\source\Target\Target.cpp(3526)
runs gdbserver and puts vAttachWait command with LLDB-No-Such-Process to the event queue. But this packet never sent to the target. Something is wrong with listeners/broadcasters.

Unfortunately I cannot debug (compare) it on Linux host right now.

slydiman added a commit to slydiman/llvm-project that referenced this issue Nov 9, 2024
@slydiman
Copy link
Contributor Author

slydiman added a commit that referenced this issue Nov 11, 2024
Groverkss pushed a commit to iree-org/llvm-project that referenced this issue Nov 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants