- 論壇徽章:
- 0
|
問題描述:
發(fā)現(xiàn)了服務(wù)器上面的一個core文件，這個core，對于我來說感到很奇怪。程序是收到sig 11信號然后core的。某個線程的rip為0了。
(gdb) where
#0 0x0000000000000000 in ?? ()
#1 0x000000000045bed1 in APNS_push_Pool::doIt2 (this=0x4b81ad0) at apns/APNS_msgpush_pool.cpp:522
#2 0x000000000045922d in APNS_push_Pool::threadProc2 (para=0x4b81ad0) at apns/APNS_msgpush_pool.cpp:137
#3 0x0000003711c079d1 in start_thread () from /lib64/libpthread.so.0
#4 0x00000037110e8b6d in clone () from /lib64/libc.so.6
apns/APNS_msgpush_pool.cpp:522，該處函數(shù)為:
519 char buf[PUSH_ERROR_FORMAT_LEN + 1];
520 memset(buf, 0, sizeof(buf));
521 int ret = 0;
522 ret = SSL_read(msg_push->connection->ssl, buf, PUSH_ERROR_FORMAT_LEN);
這段代碼的匯編碼為:
0x000000000045beba <+558>: lea -0x130(%rbp),%rcx
0x000000000045bec1 <+565>: mov $0x6,%edx
0x000000000045bec6 <+570>: mov %rcx,%rsi
---Type <return> to continue, or q <return> to quit---
0x000000000045bec9 <+573>: mov %rax,%rdi
0x000000000045becc <+576>: callq 0x407350 <SSL_read@plt>
也就是rdx對應(yīng)PUSH_ERROR_FORMAT_LEN,rsi對應(yīng)buf，rdi對應(yīng)msg_push->connection->ssl
在這幾個函數(shù)的rsp rbp的值。
f3 rsp 0x7f52837eade0 rbp 0
f2 rsp 0x7f52837eadb0 rbp 0x7f52837eadd0
f1 rsp 0x7f52837ea820 rbp 0x7f52837eada0
f0 rsp 0x7f52837ea818 rbp 0x7f52837eada0
PS: 這里funtion 0和funtion 1的rbp值一樣，很奇怪。
在另外一個線程寫失敗后，會重新連接：
/* Load encryption & hashing algorithms for the SSL program */
SSL_library_init();
/* Load the error strings for SSL & CRYPTO APIs */
SSL_load_error_strings();
/* Create an SSL_METHOD structure (choose an SSL/TLS protocol version), there is three methods of ssl*/
//sslcon->meth = SSLv3_method();
/* Create an SSL_CTX structure */
sslcon->ctx = SSL_CTX_new(SSLv3_method());
對于上面SSL_read實際調(diào)用的SSL*指針的參數(shù)值:
(gdb) print *(SSL*)0x7f5234626340
$1 = {version = 878882672, type = 32594, method = 0x7f52346153a0, rbio = 0x7f5234617260,
wbio = 0x7f5234617260, bbio = 0x0, rwstate = 2, in_handshake = 0,
handshake_func = 0x31efe26f60 <ssl3_connect>, server = 0, new_session = 0, quiet_shutdown = 0,
shutdown = 1, state = 3, rstate = 240, init_buf = 0x0, init_msg = 0x7f5234617574, init_num = 0,
init_off = 0, packet = 0x7f523461cad3 "", packet_length = 0, s2 = 0x0, s3 = 0x0, d1 = 0x0,
read_ahead = 0, msg_callback = 0, msg_callback_arg = 0x0, hit = 0, param = 0x7f5234626730,
cipher_list = 0x0, cipher_list_by_id = 0x0, mac_flags = 0, enc_read_ctx = 0x0, read_hash = 0x0,
expand = 0x0, enc_write_ctx = 0x0, write_hash = 0x0, compress = 0x0, cert = 0x7f5234626600,
sid_ctx_length = 0, sid_ctx = '\000' <repeats 31 times>, session = 0x7f5234626770,
generate_session_id = 0, verify_mode = 0, verify_callback = 0, info_callback = 0, error = 0,
error_code = 0, kssl_ctx = 0x7f52346156b0, psk_client_callback = 0, psk_server_callback = 0,
ctx = 0x7f5234026d10, debug = 0, verify_result = 20, ex_data = {sk = 0x0, dummy = 0}, client_CA = 0x0,
references = 0, options = 4, mode = 0, max_cert_list = 102400, first_packet = 0, client_version = 769,
max_send_fragment = 16384, tlsext_debug_cb = 0, tlsext_debug_arg = 0x0, tlsext_hostname = 0x0,
servername_done = 0, tlsext_status_type = -1, tlsext_status_expected = 0, tlsext_ocsp_ids = 0x0,
tlsext_ocsp_exts = 0x0, tlsext_ocsp_resp = 0x0, tlsext_ocsp_resplen = -1, tlsext_ticket_expected = 1,
tlsext_ecpointformatlist_length = 3, tlsext_ecpointformatlist = 0x7f52346269d0 " \215b4R\177",
tlsext_ellipticcurvelist_length = 4, tlsext_ellipticcurvelist = 0x7f52346269f0 "\300ib4R\177",
tlsext_opaque_prf_input = 0x0, tlsext_opaque_prf_input_len = 0, tlsext_session_ticket = 0x0,
tls_session_ticket_ext_cb = 0, tls_session_ticket_ext_cb_arg = 0x0, tls_session_secret_cb = 0,
tls_session_secret_cb_arg = 0x0, initial_ctx = 0x7f5234026d10, next_proto_negotiated = 0x0,
next_proto_negotiated_len = 0 '\000', srtp_profiles = 0x0, srtp_profile = 0x0, tlsext_heartbeat = 0,
tlsext_hb_pending = 0, tlsext_hb_seq = 0, renegotiate = 0}
提供的信息就這些了
問題：
1.為啥奔潰的f 0，rbp沒變，是不是說明在函數(shù)重新定位的時候出錯了
2.SSL_library_init()會不會有一些操作導(dǎo)致地址改變，應(yīng)該不會，想確認(rèn)下 |
|
免費注冊
發(fā)表于 2014-11-20 17:44