mgorny added a comment. In D127500#3595605 <https://reviews.llvm.org/D127500#3595605>, @labath wrote:
> I've ran into the "dynamic uninitialization order fiasco" problem as well. > I'm wondering if, instead of the trick (which is pretty neat, but still a > trick) with the limbo member variable, we could add something like the > `asyncio.loop.call_soon` function in python to our MainLoop class. So, > instead of immediately calling the exited callback (and possibly others as > well), the process class would schedule the call to be made upon return to > the top-level loop. > > What do you think about that? Not sure if I follow you. If you mean delaying the whole callback logic, I don't think that would change anything — the problem is that the object gets destroyed in the middle of it. If you mean delaying just the part where it's removed from `m_debugged_processes`, then I suppose that could work. ================ Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1196 + if (!bool(m_extensions_supported & + NativeProcessProtocol::Extension::multiprocess)) + assert(!m_stdio_handle_up); ---------------- labath wrote: > I don't think this is right. I believe the important distinction is whether > we have non-stop mode enabled or not, because in all-stop mode we are not > able to send stdio while stopped, regardless of how many processes we're > debugging. Well, the code exploded in all-stop mode as well because in order to kill multiple processes, we effectively resume them all. I suppose there could be a way around it (synchronously killing one process after another and waiting for everything to happen) but I'm not convinced this is really worth the added complexity. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D127500/new/ https://reviews.llvm.org/D127500 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
