>>> >>> in that case it crashes here: >>> >>> >>> >>> if (s->msg_callback) >>> >>> s->msg_callback(0, s->version, SSL3_RT_HANDSHAKE, >>> >>> s->init_buf->data, (size_t)s->init_num + 4, s, s->msg_callback_arg); >>> >>> >>> >> >>> >> So is the pointer to the callback wrong, or is the SIGSEGV in the >>> >> called function? >>> > >>> > What happens if you type just 'disass' at debugger prompt. Question is >>> > if you see meaningful code at point of failure, at 0x80e130 in >>> original >>> > example. If you see meaningful instruction with reference to memory, >>> > issue even 'info reg'. If you don't see meaningful code, then it's >>> > likely that pointer to callback is wrong. In which case 'print $r10' >>> > would print address of failure. $r10 is because we already established >>> > that it was called with call *%r10. >>> > >>> >>> (gdb) disass >>> No function contains program counter for selected frame. >>> (gdb) disass 0x000000000080e130 >>> No function contains specified address. >>> (gdb) print $r10 >>> $1 = 8446256 >>> >>> 8446256 = 0x000000000080e130 >>> >>> so the pointer was wrong in the first place, >>> got changed or the function is not there anymore >> >> I suggest you try 'x/16i 0x80e130' as well, because disass can report "No >> function contains specified address." for an address that has no symbol >> information, even if it contains code. >> > (gdb) x/16i 0x80e130 > => 0x80e130: loopne 0x80e138 > 0x80e132: addl $0x0,(%rax) > 0x80e138: rclb 0x7e(%rdx) > 0x80e13b: add %al,(%rax) > 0x80e13d: add %al,(%rax)
This is not meaningful code and therefore crash is more likely to be caused by corrupted data... Hmmmmm... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
