hsueh-yh opened a new issue, #2486: URL: https://github.com/apache/brpc/issues/2486
**Describe the bug (描述bug)** 用bcc工具[funclatency](https://github.com/iovisor/bcc/blob/master/tools/funclatency.py)观察服务里某个函数的耗时时，发现会触发服务SIGILL信号，导致服务异常退出，且稳定复现。 该工具观察函数耗时是通过[uprobe/uretprobe](https://docs.kernel.org/trace/kprobes.html)来实现的，其中uretprobe会**修改栈上的函数返回地址**，所以怀疑跟bthread用户态切换栈有关。 Go服务也存在类似问题[issue](https://github.com/iovisor/bcc/issues/1320#issuecomment-325149456)，是因为Go服务会对栈进行扩缩容等操作导致栈内存移动，但是bthread的栈内存应该不会有扩缩容等移动栈内存的操作。 **To Reproduce (复现方法)** 参照[funclatency_example](https://github.com/iovisor/bcc/blob/master/tools/funclatency_example.txt)观察brpc服务的用户态函数耗时就可以触发。或者使用其他依赖uretprobe的工具。 **Expected behavior (期望行为)** 期望brpc服务可以正常使用uretprobe/kretprobe **Versions (各种版本)** OS: centos7 Compiler: gcc7.3 brpc: protobuf: **Additional context/screenshots (更多上下文/截图)** 服务报SIGILL的现场：  进程的内存分布 （cat /proc/pid/maps | grep uprobes） uprobes的内存块首地址，也就是uprobes桩函数的首地址，是 0x00007fffffffe000，**非法指令的地址正好是它的后一字节！**  现场描述： 1. 服务执行到0x00007fffffffe001地址时遇到非法指令，该地址应该是压在栈上的函数返回地址，且是被uretprobe修改过的。 2. 正常uprobes会在进入函数时，就把函数返回地址修改为uprobes内存块的首地址0x00007fffffffe000，而且通过gdb观察栈内存，在进入函数时也确实修改对了。 3. 函数执行完后，开始执行返回地址对应的指令，这时返回地址变成了0x00007fffffffe001（往后移了1字节） 所以问题应该出在函数处理过程中，在函数处理过程中，栈上的函数返回地址又被修改了。 这期间可能存在bthread调度，因为函数内部可能会创建bthread，或者调用bthread::Mutex锁间接触发切换。 求助社区大佬有没有遇到类似问题的，或者有什么解决思路？感谢！ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
