memory leak if binding failed

[zouyonghao]

Describe the bug (描述bug)
memory leak when binding failed

To Reproduce (复现方法)
bind a used port

Expected behavior (期望行为)

Versions (各种版本)
OS: Ubuntu 18.04
Compiler: clang + ASan
brpc: 0.9.0
protobuf: 3.0.0

Additional context/screenshots (更多上下文/截图)

E0428 03:47:30.283096 117030 /home/zyh/incubator-brpc/src/brpc/server.cpp:956] Fail to listen 0.0.0.0:8301
E0428 03:47:30.283232 117030 /home/zyh/braft/example/atomic/server.cpp:508] Fail to start Server


=================================================================
==117030==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 1 object(s) allocated from:
    #0 0x6d14ad in operator new(unsigned long) (/home/zyh/braft/example/atomic/atomic_server+0x6d14ad)
    #1 0xca1961 in brpc::Server::StartInternal(in_addr const&, brpc::PortRange const&, brpc::ServerOptions const*) /home/zyh/incubator-brpc/src/brpc/server.cpp:783
    #2 0xca330e in brpc::Server::Start(butil::EndPoint const&, brpc::ServerOptions const*) /home/zyh/incubator-brpc/src/brpc/server.cpp:1063
    #3 0xca34b2 in brpc::Server::Start(int, brpc::ServerOptions const*) /home/zyh/incubator-brpc/src/brpc/server.cpp:1081
    #4 0x6d5038 in main /home/zyh/braft/example/atomic/server.cpp:507:16
    #5 0x7fa2b2449bf6 in __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310

SUMMARY: AddressSanitizer: 56 byte(s) leaked in 1 allocation(s).

[Lhfcws]

---

// add for UT
    void ReleaseKeytableForUT() {
       // 
        delete _saved_keytable_pool;
        _saved_keytable_pool = NULL;
    }

如果是进程结束或者 UT 结束，可以显示调用 server.ReleaseKeytableForUT(); ，会清掉这个泄露的 keytable_pool 。我的版本是内部改过一些的版本，_saved_keytable_pool 是 destroy keytable 时候赋值的，如果没有这个方法的可以自己加下。

---

更新：并发下强制释放还是会有问题，一是会有 core，二是即使等待若干ms和 yield 多次也还是会有概率泄露（也取决于 case 的并发复杂程度）。
纯粹依赖 brpc 项目的 ASAN 检测的还是建议采用 lsan suppression 禁掉 brpc 检测。走源码编译的在 lsan suppression file 里加上一行：

leak:brpc::Server::StartInternal

[wwbmmm]

server.ReleaseKeytableForUT();

这个方法是哪来的，源码里没找到呀

[Lhfcws]

server.ReleaseKeytableForUT();

这个方法是哪来的，源码里没找到呀

我修改了下描述。“我的版本是内部改过一些的版本，如果没有这个方法的可以自己加下。”

[zouyonghao]

Thanks @Lhfcws
So according to your comments, the leak is true, but we can ignore it, right?

Is there a better elegant way to solve this, like smart pointer or something else?

[Lhfcws]

Thanks @Lhfcws So according to your comments, the leak is true, but we can ignore it, right?

Is there a better elegant way to solve this, like smart pointer or something else?

Obviously smart pointer can solve this issue functionally, but I have no idea how it may affect the performance. Maybe some other maintainers or core developers could tell us the tradeoff when they decide to leave this mem-leak issue ignored.

[zouyonghao]

Based on this issue, may I request a CVE for this issue? It'll help end-users know that they should update and benefit our research.

[chenBright]

With #2858 , there are two ways to ignore designated memory leaks of Server：

1. Build bRPC with ASan or LSan，this memory leak will be automatically ignored.
2. Use annotation(ANNOTATE_SCOPED_MEMORY_LEAK) to instruct LSan to ignore this memory leaks, like

brpc::Server server;
{
    ANNOTATE_SCOPED_MEMORY_LEAK;
    server.Start(...);
}

[zouyonghao]

Thank you! @chenBright