weingithub
weingithub
DiskFPSet.mergeNewEntries: 4614382410918267818 is already on disk. DiskFPSet.mergeNewEntries: 9223371957314111308 is already on disk. did anyone have any suggetion?? my version is 1.8, and I already disable profiling
堆栈 (gdb) bt #0 0x00007f101947b4ab in raise () from /lib64/libpthread.so.0 #1 0x0000559813aa1cfa in handle_fatal_signal(int) () #2 #3 0x00007f1016bbf1f7 in raise () from /lib64/libc.so.6 #4 0x00007f1016bc08e8 in abort () from /lib64/libc.so.6...
我看了下handle_pre_vote_request中的代码处理，没有判断server_id是否在当前的_conf成员列表中。因此，节点就有可能给一个 刚启动，还没有通过add_peer加到组里面的节点投票。不知道当时是基于什么考虑没有加这个限制呢？？
**Describe the bug (描述bug)** bvar的延时统计的数据，在界面打开时的实时数值，与每秒curl获取的值的内容不同。 然后实时数据与我通过打开bvar_dump获取到的值也不相同 **To Reproduce (复现方法)** 正常跑bvar统计即可 **Expected behavior (期望行为)** 界面上的实时更新的数值与curl获取到的数值相同 **Versions (各种版本)** OS: Compiler: brpc: protobuf: **Additional context/screenshots (更多上下文/截图)** 比如实时获取里面，有从200us到10ms的数值，但是通过curl看的话，没有10ms的值，只有1-2毫秒的那种。不知道是不是我使用的方式不对。
**Describe the bug (描述bug)** 创建子进程，然后在子进程中调用start_brpc_server 接口，之后出现brpc::Acceptor::StartAccept和brpc::Acceptor::BeforeRecycle之间构成死锁，curl访问该监听端口，卡住。详情见如下堆栈 **To Reproduce (复现方法)** 1.创建子进程，然后在子进程中调用start_brpc_server 接口 2.杀掉子进程，父进程会有个监听线程，监听到子进程挂掉之后，又拉起子进程（之后会重复步骤1的过程）。 **Expected behavior (期望行为)** 子进程启动之后，端口能正常监听 **Versions (各种版本)** OS: 基于linux内核3.10.0的自定义系统 Compiler: gcc 4.7 brpc: 2019年fork过去的版本 protobuf: **Additional context/screenshots (更多上下文/截图)** (gdb)...
**Describe the bug (描述bug)** bthread定时器等待了12秒都没得到执行，触发了程序检查bthread卡住的assert，而在程序生成core的过程中又恢复了。 **To Reproduce (复现方法)** 在正常业务中，创建pthread线程和bthread定时器，在pthread线程中定时检查定时器的更新时间。超过一段时间未更新，则assert **Expected behavior (期望行为)** 程序不会触发bthread卡住的assert **Versions (各种版本)** OS: centosx Compiler: gcc brpc: protobuf: **Additional context/screenshots (更多上下文/截图)** 想问下，一个是如何定位这种bthread卡住一段时间的这种问题？如何查看当时的运行截面？之前遇到过使用pstack去dump查看，结果 bthread似乎又被恢复了。我这个也类似这种现象，bthread不知道因为什么原因卡住了，然后又恢复了。