測試環境twemproxy程序突然出core退出，記錄一下gdb分析過程
解析 coredump檔案
bt -- 列印crash時的堆疊
# gdb /root/proxy/bin/twemproxy /tmp/cordump.file
(gdb) bt
#0 0x00007f9f3b0d4337 in ssignal () from /lib64/libc.so.6
#1 0x00007f9f3b0d5a28 in abort () from /lib64/libc.so.6
#2 0x000000000041e27b in nc_assert (cond=cond@entry=0x44ea8a "pr->type == msg_req_redis_del", file=file@entry=0x44ea18 "nc_redis.c",
line=line@entry=2387, panic=panic@entry=1) at nc_util.c:353
#3 0x0000000000428065 in redis_pre_coalesce (r=0x22aaf30) at nc_redis.c:2387
#4 0x000000000041443b in rsp_forward (msg=0x22aaf30, s_conn=0x2b36690, ctx=0x1c33570) at nc_response.c:289
#5 rsp_recv_done (ctx=0x1c33570, conn=0x2b36690, msg=0x22aaf30, nmsg=) at nc_response.c:345
#6 0x0000000000410926 in msg_parsed (msg=0x22aaf30, conn=0x2b36690, ctx=0x1c33570) at nc_message.c:803
#7 msg_parse (msg=0x22aaf30, conn=0x2b36690, ctx=0x1c33570) at nc_message.c:841
#8 msg_recv_chain (msg=0x22aaf30, conn=0x2b36690, ctx=0x1c33570) at nc_message.c:896
#9 msg_recv (ctx=0x1c33570, conn=0x2b36690) at nc_message.c:973
#10 0x000000000040ba44 in core_recv (conn=0x2b36690, ctx=0x1c33570) at nc_core.c:247
#11 core_core (ctx=0x1c33570, conn=0x2b36690, events=1) at nc_core.c:385
#12 0x000000000040bcbc in core_loop (ctx=ctx@entry=0x1c33570) at nc_core.c:446
#13 0x0000000000402b48 in nc_run (nci=0x65a0e0 ) at nc.c:709
#14 main (argc=, ar**=0x7fff5f1ee568) at nc.c:763
(gdb) frame 3
#3 0x0000000000428065 in redis_pre_coalesce (r=0x22aaf30) at nc_redis.c:2387
2387 nc_redis.c: no such file or directory.
(gdb) p *pr
$1 = }, s_tqe = }, m_tqe = }, id = 2984568133, peer = 0x22aaf30, owner = 0x28cb430, tmo_rbe = , mhdr = , mlen = 4357, state = 0, depth = 0,
pos = 0x0, token = 0x0, parser = 0x423030 , result = msg_parse_ok, fragment = 0x428270 ,
add_auth = 0x4284c0 , failure = 0x427f20 , reply = 0x428890 ,
pre_coalesce = 0x427f60 , post_coalesce = 0x428340 , mbuf_get = 0x40d960 ,
type = msg_req_redis_mset, keys = 0x1f9f450, vlen = 0, end = 0x0, narg_start = 0x0, narg_end = 0x0, narg = 12, rnarg = 0, rnargs = , rlen = 0, integer = 0, frag_owner = 0x2834e10, nfrag = 0, frag_id = 134161, nfrag_done = 0, frag_seq = 0x0, err = 0,
error = 0, ferror = 0, request = 1, quit = 0, noreply = 0, noforward = 0, done = 1, fdone = 0, swallow = 0, redis = 1, mseterr = 0,
ticket = 0, concurrent = 0, param_err = 0, start_tv = , send_server_tv = , recv_server_tv = , dump_len = 0,
dump_data = "del spring:session:expirations:1599718440000 w_limit:loandistribution call('pexpire', keys[1], ar**[2]); else return nil; end", forward_server = }
然後結合著函式一起看
可以看到，列印出來的pr->type 為 msg_req_redis_mset，但是卻走到了mget和del型別指令的預解析流程中
接下來就得具體看**看上層邏輯為這麼走到了這一層
GDB除錯core檔案小記
1.如果不走配置，必須在當前shell中設定core檔案的限制 2.在當前shell中設定core限制，在其他shell中啟動程式，是不會生效的 3.core一般很大，最好設為unlimited 4.root 使用者使用ulimit c unlimited命令，開啟core dump功能，並且不限制...
用gdb工具分析core檔案
在unix系統下，應用程式崩潰，一般會產生core檔案，如何根據core檔案查詢問題的所在，並做相應的分析和除錯，是非常重要的，本文對此做簡單介紹。例如，乙個程式cmm test tool在執行的時候發生了錯誤，並生成了乙個core檔案，如下 rw r r 1 root cmm test tool....
用gdb工具分析core檔案
在unix系統下，應用程式崩潰，一般會產生core檔案，如何根據core檔案查詢問題的所在，並做相應的分析和除錯，是非常重要的，本文對此做簡單介紹。例如，乙個程式cmm test tool在執行的時候發生了錯誤，並生成了乙個core檔案，如下 rw r r 1 root cmm test tool....