https://github.com/jimingham approved this pull request.
Thanks for catching this. Keeping the module list locked too long is one of the easiest ways to produce deadlocks in lldb at present! I can't see a reason why the work done when lldb is notified of a new module should require that the module list be locked at the point where this module was loaded until the notification is complete. For the most part the notification reactions are things like adding breakpoints found in the new module, or seeing if it indicates the presence of one of the known runtimes - so specific to just the module_sp that was passed in. It shouldn't need to require that no more modules get loaded while it is doing that. So this looks like a good change to me. It would be great to get a test for this. The test I added does something like your repro conditions, but because it was specifically about python files in dSYM's it was a macOS only test. But you might be able to use the running parts without the dSYM parts to test this? https://github.com/llvm/llvm-project/pull/148774 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
