centos7 lldb 调试netcore应用的内存泄漏和死循环示例(dump文件调试)
clrthreads -live 先看看还在运行的线程有那些。然后通过thread select 线程编号（lldb命令）。来切换到当前线程。线程编号不是列表种的id字段，而是最前面一行的id。lldb 可以通过thread list命令来列举所有线程。
剩下的工作就是体力活动拉，一个一个看，一个一个分析。
比如，我们切换到线程3看一看他当前的堆栈信息
clrstack命令可以查看当前线程在托管代码种的堆栈信息。
dumstack则可以看到非托管代码种的堆栈信息
thread backtrace lldb查看堆栈信息的命令。
线程3，能看到当前栈在非托管代码中（libcoreclr.so!TwoWayPipe::WaitForConnection），看方法名字也能猜到干嘛的，不太像我们的目标。
另外，linux下面
ps -T -p 32728 命令可以查看到进行下线程的基本情况
top -H -p 32728 更happy。
所以在排查高cpu问题的时候能提供许多便利性，反而比内存问题要来得方便很多。（图中的pid等数据不是一致性的。因为在写blog的时候图片是多次截取的。）
所以在dump包的时候可以记录下来高cpu的线程id，然后通过thread select 找到对应的线程编号。在然后直接切换过去看一看就完事拉。
所以 thread select 30
clrstack看一看，嗯！当前线程在 linxu_dump_lldb.Controllers.ValuesController+<>c.<begin_cpu>b__1_0() [C:\Users\czd89\source\repos\ConsoleApp4\linxu_dump_lldb\Controllers\ValuesController.cs @ 31]。
看一看当前栈上面都有一些上面参数
CLRStack [-a] [-l] [-p]；-p:看参数，-l：看局部变量，-a：=-l+-p；
当然，我们的代码是异步的，也没有捕获任何action里面的变量，所以这里的这个参数，以及参数里面的属性啥都没有。
从dll反编译代码也能和我们lldb看到的东西一一对以上。
