链接jemalloc后在bthread中启动的pthread在结束时crash

[niukuo]

Describe the bug (描述bug)

To Reproduce (复现方法)

1. brpc server端
2. 链接了 jemalloc
3. usercode_in_pthread=false
4. 在 rpc method 代码中使用std::thread启动了新的线程并detach
5. 新启动的线程中会同步调用其它rpc服务。
6. 线程在结束时crash，stack在jemalloc清理tcache(应该和thread local storage有关)时一个pthread_unlock。
7. 设置usercode_in_pthread=true后到目前没有发现进程挂掉的情况

Expected behavior (期望行为)

Versions (各种版本)
OS: centos 5u7
Compiler: gcc-4.9.2
brpc:
protobuf: 2.4.1

Additional context/screenshots (更多上下文/截图)
coredump和stack暂时没有 如果需要可以复现一下。
在bthread文档中大概找了一下，猜测可能与stacktype有关。能否提供一些调查方向？

[niukuo]

以及，在bthread中启动pthread的正确姿势应该是怎样的。。。

[jamesge]

crash时server在退出进程么？
新启动的线程如果不做rpc，还会crash么？
新启动的线程可能引用失效的对象么？包括那个pthread_unlock的mutex

[niukuo]

1. crash时只有那个线程在退出，进程没有退出，正常提供服务。
2. 那个mutex是jemalloc内部的，暂时没有研究。
   后面修改了一些工作流程，暂时无法重现了。怀疑是我这边的用户代码有内存问题，暂时先关闭。

[niukuo]

原因找到了，是因为对栈上的对象执行了delete操作。
猜测是因为jemalloc将部分申请、释放内存的动作暂存在了thread cache中，线程退出时才归还到全局内存池中，触发crash。
brpc 链接 jemalloc 并不是crash的原因。

[jamesge]

这类问题可以看看跑asan是否能报出来。

[niukuo]

这类问题可以看看跑asan是否能报出来。

恩 这个是在链接了tcmalloc之后发现的 tcmalloc在删除栈上的对象时候会立即crash