如何最快找出复杂代码运行时的函数调用流程

 

概述

最近在使用freeswitch测试发送DTMF码的时候，碰到一个函数调用流程的问题。

fs本身的模块较多，注册回调函数也比较多且复杂，有时候看到一条日志，却不知道流程的发起端在哪里。

通常我们在梳理代码调用流程的时候有几种方法。

1，    梳理源代码流程，代码太复杂的时候效果差。
2，    在调用函数中打印日志，代码太复杂的时候效果差。
3，    通过backtrace函数追踪当前堆栈，改动多，细节多。
4，    gdb调试，命令复杂难记。

今天突然想到一个偷懒的办法，比上面几种方法都要快速简单。

环境

centos7

freeswitch 1.6.19

gcc version 4.8.5

起源

fs的日志如下，简单来看，在dialplan中调用了sleep之后，rtp流程开始发送DTMF。

EXECUTE sofia/external/[email protected]:5080 sleep(5000)

2022-06-17 14:42:54.890047 [DEBUG] switch_rtp.c:5237 Send start packet for [1] ts=160 dur=160/160/2000 seq=8238 lw=160

但是rtp的调用过程隔的太远，源代码看了好久也没看出来所以然，主要是菜。

修改源代码

首先找到“switch_rtp.c:5237”的位置，修改源代码，增加一行断言判定。

switch_assert(FALSE);

重新对fs编译安装。

测试

启动fs，并执行测试命令，日志如下。

[email protected]> originate {originator_codec=PCMA,origination_caller_id_number=0755110}sofia/external/sip:[email protected]:5080 1001 XML ext_test

…

EXECUTE sofia/external/[email protected]:5080 sleep(5000)

freeswitch: src/switch_rtp.c:5236: do_2833: Assertion `0' failed.

Aborted

哈，和设想的一样，fs程序coredump了

core堆栈

在bin目录下找到core文件

-rw-------. 1 root root 71778304 Jun 17 15:24 core.14650

使用gdb打开core文件，并显示堆栈。

sudo gdb freeswitch core.14650

…

(gdb) bt

#0  0x00007f0b9e371387 in raise () from /lib64/libc.so.6

#1  0x00007f0b9e372a78 in abort () from /lib64/libc.so.6

#2  0x00007f0b9e36a1a6 in __assert_fail_base () from /lib64/libc.so.6

#3  0x00007f0b9e36a252 in __assert_fail () from /lib64/libc.so.6

#4  0x00007f0ba0e8be2a in do_2833 ([email protected]=0x7f0b1c012d98) at src/switch_rtp.c:5236

#5  0x00007f0ba0e8d4fb in rtp_common_read ([email protected]=0x7f0b1c012d98, [email protected]=0x7f0b34040aa4 "", [email protected]=0x7f0b34040ac8, [email protected]=0x7f0b34040ab8, [email protected]=0) at src/switch_rtp.c:7321

#6  0x00007f0ba0e8e59f in switch_rtp_zerocopy_read_frame (rtp_session=0x7f0b1c012d98, [email protected]=0x7f0b34040a60, [email protected]=0) at src/switch_rtp.c:7617

#7  0x00007f0ba0e41990 in switch_core_media_read_frame ([email protected]=0x7f0b3402f3b8, [email protected]=0x7f0b482795d8, [email protected]=0, [email protected]=0, [email protected]=SWITCH_MEDIA_TYPE_AUDIO) at src/switch_core_media.c:2219

#8  0x00007f0b984f1298 in sofia_read_frame (session=0x7f0b3402f3b8, frame=0x7f0b482795d8, flags=0, stream_id=0) at mod_sofia.c:1044

#9  0x00007f0ba0e2a5d6 in switch_core_session_read_frame ([email protected]=0x7f0b3402f3b8, [email protected]=0x7f0b482795d8, [email protected]=0, [email protected]=0) at src/switch_core_io.c:188

#10 0x00007f0ba0ec426d in switch_ivr_sleep ([email protected]=0x7f0b3402f3b8, [email protected]=5000, [email protected]=SWITCH_TRUE, [email protected]=0x7f0b48279850) at src/switch_ivr.c:294

#11 0x00007f0b7273d5c4 in sleep_function (session=0x7f0b3402f3b8, data=<optimized out>) at mod_dptools.c:2288

#12 0x00007f0ba0e2472b in switch_core_session_exec ([email protected]=0x7f0b3402f3b8, [email protected]=0x1ccfcd8, [email protected]=0x7f0b34053240 "5000") at src/switch_core_session.c:2802

#13 0x00007f0ba0e24cb9 in switch_core_session_execute_application_get_flags ([email protected]=0x7f0b3402f3b8, app=0x7f0b34053238 "sleep", arg=0x7f0b34053240 "5000", [email protected]=0x0) at src/switch_core_session.c:2672

#14 0x00007f0ba0e28ae4 in switch_core_standard_on_execute (session=0x7f0b3402f3b8) at src/switch_core_state_machine.c:353

#15 switch_core_session_run (session=0x7f0b3402f3b8) at src/switch_core_state_machine.c:650

#16 0x00007f0ba0e21f7e in switch_core_session_thread (thread=<optimized out>, obj=0x7f0b3402f3b8) at src/switch_core_session.c:1648

#17 0x00007f0ba0e1dc73 in switch_core_session_thread_pool_worker (thread=0x7f0b3404f340, obj=<optimized out>) at src/switch_core_session.c:1711

#18 0x00007f0ba10d8b10 in dummy_worker (opaque=0x7f0b3404f340) at threadproc/unix/thread.c:151

#19 0x00007f0b9ede5ea5 in start_thread () from /lib64/libpthread.so.0

#20 0x00007f0b9e439b0d in clone () from /lib64/libc.so.6

(gdb)

啧啧，清晰的函数调用流程，一览无余。

总结

fs的模块比较多，代码调用链大都比较长，涉及到媒体方面流程更是复杂难以跟踪。

剑走偏锋，独辟蹊径。

空空如常

求真得真