llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.42k stars 12.16k forks source link

Calls to curl in lldb make debugging insanely slow #118427

Open jcelerier opened 19 hours ago

jcelerier commented 19 hours ago

When trying to debug my app it seems that lldb is making a curl call for every dynamic library loaded, and stalling roughly a second on each of them. In practice this means waiting roughly 5 minutes before my app even starts.

Stack traces gotten through profiling seem to indicate unordinate amount of time spend in openssl's certificates which brought me to this issue: https://github.com/openssl/openssl/issues/17064 which seems related ; nevertheless it seems most of the time is spent polling and not computing. CPU is "12th Gen Intel(R) Core(TM) i7-12700H"

If I disable debuginfod, things seem to go much much better (but debuginfod is nice to have).

The second screenshot seems to indicate that it tries to load debuginfo and wait until it got a response (or maybe a failure) to start looking for the next shared object's debuginfo, which does not seem too efficient. Ironically it seems that my distro doesn't have a debuginfo for liblldb.so.18.1.8 thus I cannot provide stack traces that are too useful :')

Image Image

llvmbot commented 19 hours ago

@llvm/issue-subscribers-lldb

Author: Jean-Michaël Celerier (jcelerier)

When trying to debug my app it seems that lldb is making a curl call for every dynamic library loaded, and stalling roughly a second on each of them. In practice this means waiting roughly 5 minutes before my app even starts. Stack traces gotten through profiling seem to indicate unordinate amount of time spend in openssl's certificates which brought me to this issue: https://github.com/openssl/openssl/issues/17064 which seems related ; nevertheless it seems most of the time is spent polling and not computing. CPU is "12th Gen Intel(R) Core(TM) i7-12700H" If I disable debuginfod, things seem to go much much better (but debuginfod is nice to have). The second screenshot seems to indicate that it tries to load debuginfo and wait until it got a response (or maybe a failure) to start looking for the next shared object's debuginfo, which does not seem too efficient. Ironically it seems that my distro doesn't have a debuginfo for liblldb.so.18.1.8 thus I cannot provide stack traces that are too useful :') ![Image](https://github.com/user-attachments/assets/f4894ea9-c7f0-4dd4-8e97-65bdd0327c5d) ![Image](https://github.com/user-attachments/assets/a377df8c-ea18-45d1-a71b-532e2fa1e026)
bulbazord commented 5 hours ago

debuginfod is the one using curl on behalf of LLDB, LLDB doesn't explicitly use curl. I'm not sure what we can do on the LLDB side to improve things (other than potentially requesting more than one module's debug info at a time).