- 论坛徽章:
- 0
|
问题描述:
发现了服务器上面的一个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,该处函数为:
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对应PUSH_ERROR_FORMAT_LEN,rsi对应buf,rdi对应msg_push->connection->ssl
在这几个函数的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实际调用的SSL*指针的参数值:
(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没变,是不是说明在函数重新定位的时候出错了
2.SSL_library_init()会不会有一些操作导致地址改变,应该不会,想确认下 |
|