调试

我们相信，调试体验也是一个框架很重要的一部分。

rpc

我们通过/inspect/...、/prof等地址对外暴露了一系列基于HTTP协议的调试接口：

出于安全考虑，上述接口不应当对外网暴露。如果服务需要对外网暴露，通常我们推荐在对外的反向代理（如nginx）上过滤相关的URI前缀。

如果修改反代配置不方便，也可以通过Server::Options::no_builtin_pages统一关闭，但是这会让整个程序成为“黑盒”，我们通常不推荐这么做。

另外。如果对于内网也有过滤需求，可以通过使用HttpFilter的方式，如通过注册某些鉴权的HttpFilter来过滤未授权的用户对上述调试接口的访问。需要注意的是这可能会令通过curl等命令行方式调试进程变得困难。

目前基于用户态调度的框架在调试体验上普遍较为欠缺，这儿列出了一些常见的问题。

对于协程类框架，同义问题为“枚举挂起的协程”，技术上属于相同问题。

目前协程类框架多未提供此种能力，因此对于未知原因导致挂起的上下文难以调试。（2019年末状况）

我们提供了GDB插件，引入了新的list-fibers命令，可以用于枚举所有当前未在执行状态的fibers。具体使用及技术细节可见gdb-plugin.md。

brpc也提供了类似的GDB插件。

Sanitizers对于追踪代码中崩溃时不在现场的bug往往有很好的效果。但是对于基于用户态调度（无论是有栈协程还是fiber）的库而言，直接使用sanitizers往往会以程序崩溃告终。

目前无论协程类或是基于fiber类的框架，多未提供此种能力。（2019年末状况）

flare有必要的和sanitizers之间的协作，目前对sanitizers提供了一定的支持。