[ 
https://issues.apache.org/jira/browse/TS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507563#comment-13507563
 ] 

Bryan Call commented on TS-1598:
--------------------------------

A few things to note:
1. The _start and _end are not set in the IOBufferBlock - default values of 0x0
2. When write_avail is called on the buffer block it takes the _buf_end pointer 
and subtracts _end giving the crazy high number of bytes available to write
3. b->end() + offset in the code will be a very low memory address since _end 
== 0x0

Looking at the MIOBuffer:
(gdb) p *buf.mbuf
$6 = {size_index = 47430144908000, water_mark = 0, _writer = {
    m_ptr = 0x2b1f6b16f9b0}, readers = {{accessor = 0x0, mbuf = 0x0, block = {
        m_ptr = 0x0}, start_offset = 0, size_limit = 9223372036854775807}, {
      accessor = 0x0, mbuf = 0x0, block = {m_ptr = 0x0}, start_offset = 0, 
      size_limit = 9223372036854775807}, {accessor = 0x0, mbuf = 0x0, block = {
        m_ptr = 0x0}, start_offset = 0, size_limit = 9223372036854775807}, {
      accessor = 0x0, mbuf = 0x0, block = {m_ptr = 0x0}, start_offset = 0, 
      size_limit = 9223372036854775807}, {accessor = 0x0, mbuf = 0x0, block = {
        m_ptr = 0x0}, start_offset = 0, size_limit = 9223372036854775807}}, 
  _location = 0x6bcaa8 "memory/IOBuffer/HttpClientSession.cc:235"}

                
> Coring in SSL
> -------------
>
>                 Key: TS-1598
>                 URL: https://issues.apache.org/jira/browse/TS-1598
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: SSL
>    Affects Versions: 3.2.0
>         Environment: RHEL6.2 64bit
>            Reporter: Abhishek Nayani
>
> (gdb) bt
> #0  0x000000390ac88c5b in memcpy () from /lib64/libc.so.6
> #1  0x0000003f962264ce in ssl3_read_bytes () from /usr/lib64/libssl.so.10
> #2  0x0000003f96222270 in ?? () from /usr/lib64/libssl.so.10
> #3  0x000000000066eaf7 in ssl_read_from_net (nh=<value optimized out>, 
> vc=0x2ada4437e0a0, lthread=0x2ada11ff2010, ret=@0x2ada174e5c10) at 
> SSLNetVConnection.cc:135
> #4  0x000000000066f3b0 in SSLNetVConnection::net_read_io 
> (this=0x2ada4437e0a0, nh=0x2ada11ff51e8, lthread=0x2ada11ff2010) at 
> SSLNetVConnection.cc:288
> #5  0x0000000000676fb2 in NetHandler::mainNetEvent (this=0x2ada11ff51e8, 
> event=<value optimized out>, e=<value optimized out>) at UnixNet.cc:381
> #6  0x00000000006a0ba4 in handleEvent (this=0x2ada11ff2010, e=0x24fdfc0, 
> calling_code=5) at I_Continuation.h:146
> #7  EThread::process_event (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) 
> at UnixEThread.cc:142
> #8  0x00000000006a16f3 in EThread::execute (this=0x2ada11ff2010) at 
> UnixEThread.cc:264
> #9  0x000000000069fae2 in spawn_thread_internal (a=0x268f1a0) at Thread.cc:88
> #10 0x000000390b007851 in start_thread () from /lib64/libpthread.so.0
> #11 0x000000390ace76dd in clone () from /lib64/libc.so.6

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to