[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988345#comment-13988345 ] Brian Geffon commented on TS-2497: -- this patch may not apply cleanly to 3.2.x (it's a pretty old verison) but you can just modify HttpSM.cc directly and comment out the tunnel.reset() in handle_post_failure(). I believe by not doing the reset and keeping references to the consumers and producers HttpSM::kill_this() will call deallocate_buffers() later and all should be fine. > Failed post results in tunnel buffers being returned to freelist prematurely > > > Key: TS-2497 > URL: https://issues.apache.org/jira/browse/TS-2497 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.2.0 > > > When a post fails to an origin server either the server died or the server > returned a response without reading all of the post data, in either case, TS > will destroy buffers too early. This normally does not result in a crash > because the MIOBuffers are returned to the freelist and only with sufficient > load will the race happen causing a crash. Additionally, even if a crash > doesn't happen you might have data corruption across post requests from the > buffers being used after being returned to the freelist. > Thanks to Thomas Jackson for help reproducing and resolving this bug. > An example stack trace, while we've seen other crashes in write_avail too. > #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at > ../iocore/eventsystem/I_IOBuffer.h:362 > #1 0x0050d151 in MIOBuffer::append_block_internal > (this=0x2aab38001130, b=0x2aab0c037200) at > ../iocore/eventsystem/P_IOBuffer.h:946 > #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, > asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 > #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:994 > #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:1002 > #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:1048 > #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, > vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 > #7 0x006c37bf in UnixNetVConnection::net_read_io > (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at > UnixNetVConnection.cc:816 > #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, > event=5, e=0x271d8e0) at UnixNet.cc:380 > #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, > event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 > #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, > e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 > #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at > UnixEThread.cc:264 > #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 > #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 > #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[
https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988340#comment-13988340
]
Brian Geffon commented on TS-2497:
--
[~shaunmcginnity] I believe I see the issue, tunnel.reset() calls memset on
producers/consumers making the call to tunnel.deallocate_buffers() do nothing
later on, can you please try the following patch:
{code}
diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index 3ff0397..e0357f8 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -4940,7 +4940,7 @@ HttpSM::handle_post_failure()
// have the full post and it's deallocating the post buffers here
enable_redirection = false;
tunnel.deallocate_redirect_postdata_buffers();
- tunnel.reset();
+ //tunnel.reset();
// Don't even think about doing keep-alive after this debacle
t_state.client_info.keep_alive = HTTP_NO_KEEPALIVE;
{code}
> Failed post results in tunnel buffers being returned to freelist prematurely
>
>
> Key: TS-2497
> URL: https://issues.apache.org/jira/browse/TS-2497
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 4.2.0
>
>
> When a post fails to an origin server either the server died or the server
> returned a response without reading all of the post data, in either case, TS
> will destroy buffers too early. This normally does not result in a crash
> because the MIOBuffers are returned to the freelist and only with sufficient
> load will the race happen causing a crash. Additionally, even if a crash
> doesn't happen you might have data corruption across post requests from the
> buffers being used after being returned to the freelist.
> Thanks to Thomas Jackson for help reproducing and resolving this bug.
> An example stack trace, while we've seen other crashes in write_avail too.
> #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at
> ../iocore/eventsystem/I_IOBuffer.h:362
> #1 0x0050d151 in MIOBuffer::append_block_internal
> (this=0x2aab38001130, b=0x2aab0c037200) at
> ../iocore/eventsystem/P_IOBuffer.h:946
> #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130,
> asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986
> #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at
> ../iocore/eventsystem/P_IOBuffer.h:994
> #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at
> ../iocore/eventsystem/P_IOBuffer.h:1002
> #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at
> ../iocore/eventsystem/P_IOBuffer.h:1048
> #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208,
> vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234
> #7 0x006c37bf in UnixNetVConnection::net_read_io
> (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at
> UnixNetVConnection.cc:816
> #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208,
> event=5, e=0x271d8e0) at UnixNet.cc:380
> #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208,
> event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146
> #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010,
> e=0x271d8e0, calling_code=5) at UnixEThread.cc:142
> #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at
> UnixEThread.cc:264
> #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88
> #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0
> #14 0x0033728e68ed in clone () from /lib64/libc.so.6
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988307#comment-13988307 ] Brian Geffon commented on TS-2497: -- Shaun, just out of curiosity does the memory stabilize at some point? Because HttpSM::kill_this() calls tunnel.deallocate_buffers(), so I'm wondering if you're just seeing the memory increase as the freelist grows? Or does it continue to grow unbounded? Brian > Failed post results in tunnel buffers being returned to freelist prematurely > > > Key: TS-2497 > URL: https://issues.apache.org/jira/browse/TS-2497 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.2.0 > > > When a post fails to an origin server either the server died or the server > returned a response without reading all of the post data, in either case, TS > will destroy buffers too early. This normally does not result in a crash > because the MIOBuffers are returned to the freelist and only with sufficient > load will the race happen causing a crash. Additionally, even if a crash > doesn't happen you might have data corruption across post requests from the > buffers being used after being returned to the freelist. > Thanks to Thomas Jackson for help reproducing and resolving this bug. > An example stack trace, while we've seen other crashes in write_avail too. > #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at > ../iocore/eventsystem/I_IOBuffer.h:362 > #1 0x0050d151 in MIOBuffer::append_block_internal > (this=0x2aab38001130, b=0x2aab0c037200) at > ../iocore/eventsystem/P_IOBuffer.h:946 > #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, > asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 > #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:994 > #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:1002 > #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:1048 > #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, > vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 > #7 0x006c37bf in UnixNetVConnection::net_read_io > (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at > UnixNetVConnection.cc:816 > #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, > event=5, e=0x271d8e0) at UnixNet.cc:380 > #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, > event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 > #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, > e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 > #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at > UnixEThread.cc:264 > #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 > #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 > #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988175#comment-13988175
]
ASF subversion and git services commented on TS-2431:
-
Commit ea7849384139a0ae8308fe12dc0741c4390953e1 in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ea78493 ]
TS-2744: remove TSNetAcceptNamedProtocol assertion for unknown protocols
TSNetAcceptNamedProtocol is supposed to accept arbitrary strings
because it lets you implement your own protocol plugin over TLS,
using NPN or ALPN to demux the session. TS-2431 added an assertion
to SSLNextProtocolSet::NextProtocolEndpoint::NextProtocolEndpoint
when an unknown protocol is registered. There's no "unknown" value
in TSProtoType, but it is safe to mark unrecognized protocols as
TS_PROTO_TLS.
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
> 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
> 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2744) TSNetAcceptNamedProtocol asserts for unknown protocols
[
https://issues.apache.org/jira/browse/TS-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988174#comment-13988174
]
ASF subversion and git services commented on TS-2744:
-
Commit ea7849384139a0ae8308fe12dc0741c4390953e1 in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ea78493 ]
TS-2744: remove TSNetAcceptNamedProtocol assertion for unknown protocols
TSNetAcceptNamedProtocol is supposed to accept arbitrary strings
because it lets you implement your own protocol plugin over TLS,
using NPN or ALPN to demux the session. TS-2431 added an assertion
to SSLNextProtocolSet::NextProtocolEndpoint::NextProtocolEndpoint
when an unknown protocol is registered. There's no "unknown" value
in TSProtoType, but it is safe to mark unrecognized protocols as
TS_PROTO_TLS.
> TSNetAcceptNamedProtocol asserts for unknown protocols
> --
>
> Key: TS-2744
> URL: https://issues.apache.org/jira/browse/TS-2744
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> {{TSNetAcceptNamedProtocol}} is supposed to accept arbitrary strings because
> it lets you implement your own protocol plugin over TLS, using NPN or ALPN to
> demux the session. TS-2431 broke this by adding an assertion to
> {{SSLNextProtocolSet::NextProtocolEndpoint::NextProtocolEndpoint}} when an
> unknown protocol is registered. A large part of the point of this API is to
> allow you to register your own protocol.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-898) fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988172#comment-13988172 ] ASF subversion and git services commented on TS-898: Commit 07a10818623ab5660bf79aa33a203ef211ad46fa in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=07a1081 ] TS-898: stop the esi plugin referencing invalidated strings The hackery that the esi plugin does to avoid any string copying in cookie value extraction leads Coverity to believe that invalidated std::string data is referenced. This is is probably fine in practice, but it's still easy to fix. Coverity #1200048 > fix potential problems from coverity scan > - > > Key: TS-898 > URL: https://issues.apache.org/jira/browse/TS-898 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.0 > Environment: RHEL5 >Reporter: Bryan Call > Fix For: sometime > > > Ran Coverity over the code and it reported 856 potential problems with the > code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2778) Websockets remap doesn't properly handle the implicit port for wss.
[ https://issues.apache.org/jira/browse/TS-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2778: - Fix Version/s: 5.0.0 > Websockets remap doesn't properly handle the implicit port for wss. > --- > > Key: TS-2778 > URL: https://issues.apache.org/jira/browse/TS-2778 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 4.2.1, 5.0.0 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.0.0 > > > When doing remap rules such as: map wss://domain.com/ ..., remap isn't > handling the implicit port 443 correctly, the issues is currently resolved by > doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2778) Websockets remap doesn't properly handle the implicit port for wss.
[ https://issues.apache.org/jira/browse/TS-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2778: - Backport to Version: 4.2.2 > Websockets remap doesn't properly handle the implicit port for wss. > --- > > Key: TS-2778 > URL: https://issues.apache.org/jira/browse/TS-2778 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 4.2.1, 5.0.0 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.0.0 > > > When doing remap rules such as: map wss://domain.com/ ..., remap isn't > handling the implicit port 443 correctly, the issues is currently resolved by > doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2778) Websockets remap doesn't properly handle the implicit port for wss.
[ https://issues.apache.org/jira/browse/TS-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988123#comment-13988123 ] Brian Geffon commented on TS-2778: -- [~psudaemon], please include 6396c485bab8dbc4255f6790a5711de298b22787 for backport to 4.2.2. Thanks! > Websockets remap doesn't properly handle the implicit port for wss. > --- > > Key: TS-2778 > URL: https://issues.apache.org/jira/browse/TS-2778 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 4.2.1, 5.0.0 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.0.0 > > > When doing remap rules such as: map wss://domain.com/ ..., remap isn't > handling the implicit port 443 correctly, the issues is currently resolved by > doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2778) Websockets remap doesn't properly handle the implicit port for wss.
[ https://issues.apache.org/jira/browse/TS-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988122#comment-13988122 ] ASF subversion and git services commented on TS-2778: - Commit 270d0a0f6340797305fe9e02f29b57fae2b54415 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=270d0a0 ] TS-2778: Websockets remap doesn't properly handle the implicit port for wss. > Websockets remap doesn't properly handle the implicit port for wss. > --- > > Key: TS-2778 > URL: https://issues.apache.org/jira/browse/TS-2778 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 4.2.1, 5.0.0 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.0.0 > > > When doing remap rules such as: map wss://domain.com/ ..., remap isn't > handling the implicit port 443 correctly, the issues is currently resolved by > doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2778) Websockets remap doesn't properly handle the implicit port for wss.
[ https://issues.apache.org/jira/browse/TS-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988121#comment-13988121 ] ASF subversion and git services commented on TS-2778: - Commit 6396c485bab8dbc4255f6790a5711de298b22787 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6396c48 ] TS-2778: Websockets remap doesn't properly handle the implicit port for wss. > Websockets remap doesn't properly handle the implicit port for wss. > --- > > Key: TS-2778 > URL: https://issues.apache.org/jira/browse/TS-2778 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 4.2.1, 5.0.0 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.0.0 > > > When doing remap rules such as: map wss://domain.com/ ..., remap isn't > handling the implicit port 443 correctly, the issues is currently resolved by > doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2778) Websockets remap doesn't properly handle the implicit port for wss.
[ https://issues.apache.org/jira/browse/TS-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2778: - Affects Version/s: 5.0.0 4.2.1 > Websockets remap doesn't properly handle the implicit port for wss. > --- > > Key: TS-2778 > URL: https://issues.apache.org/jira/browse/TS-2778 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 4.2.1, 5.0.0 >Reporter: Brian Geffon > > When doing remap rules such as: map wss://domain.com/ ..., remap isn't > handling the implicit port 443 correctly, the issues is currently resolved by > doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2778) Websockets remap doesn't properly handle the implicit port for wss.
Brian Geffon created TS-2778: Summary: Websockets remap doesn't properly handle the implicit port for wss. Key: TS-2778 URL: https://issues.apache.org/jira/browse/TS-2778 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon When doing remap rules such as: map wss://domain.com/ ..., remap isn't handling the implicit port 443 correctly, the issues is currently resolved by doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2778) Websockets remap doesn't properly handle the implicit port for wss.
[ https://issues.apache.org/jira/browse/TS-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-2778: Assignee: Brian Geffon > Websockets remap doesn't properly handle the implicit port for wss. > --- > > Key: TS-2778 > URL: https://issues.apache.org/jira/browse/TS-2778 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 4.2.1, 5.0.0 >Reporter: Brian Geffon >Assignee: Brian Geffon > > When doing remap rules such as: map wss://domain.com/ ..., remap isn't > handling the implicit port 443 correctly, the issues is currently resolved by > doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2777) atscppapi: bug in intercept - not working with request transformation
[ https://issues.apache.org/jira/browse/TS-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13987990#comment-13987990 ] ASF GitHub Bot commented on TS-2777: GitHub user manjeshnilange opened a pull request: https://github.com/apache/trafficserver/pull/76 atscppapi: fix for TS-2777 - using content length from correct header Previously, the intercept code was looking for the Content Length header in the data sent by the client. However, when a request transformation is added, this can change. So the correct fix is to use the header that is read "off the wire" to find content length. So we now do it after reading the header rather than in the constructor. You can merge this pull request into a Git repository by running: $ git pull https://github.com/manjeshnilange/trafficserver master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/76.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #76 commit 4bd8af16ae8fb0ef99988798dc00289af2c30156 Author: Manjesh Nilange Date: 2014-05-02T17:42:07Z atscppapi: fix for TS-2777 - using content length from correct header > atscppapi: bug in intercept - not working with request transformation > - > > Key: TS-2777 > URL: https://issues.apache.org/jira/browse/TS-2777 > Project: Traffic Server > Issue Type: Bug > Components: CPP API >Reporter: Manjesh Nilange >Assignee: Brian Geffon > > When used in conjunction with a request transformation, the intercept appears > to "hang". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2777) atscppapi: bug in intercept - not working with request transformation
Manjesh Nilange created TS-2777: --- Summary: atscppapi: bug in intercept - not working with request transformation Key: TS-2777 URL: https://issues.apache.org/jira/browse/TS-2777 Project: Traffic Server Issue Type: Bug Components: CPP API Reporter: Manjesh Nilange Assignee: Brian Geffon When used in conjunction with a request transformation, the intercept appears to "hang". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2774) TS::AdminClient.pm's get_stat API broken in 5.0
[ https://issues.apache.org/jira/browse/TS-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13987913#comment-13987913 ] ASF subversion and git services commented on TS-2774: - Commit cf22df8b901d3020ca2d8113a397afb5968ea251 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cf22df8 ] Added TS-2774 to changes > TS::AdminClient.pm's get_stat API broken in 5.0 > --- > > Key: TS-2774 > URL: https://issues.apache.org/jira/browse/TS-2774 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.0.0 > > Attachments: ts2774.diff > > > With the changes in TS-2637, the order in which the fields in the response > are sent, has been changed. This broke the get_stat() perl API in > TS::AdminClient, which expects the response fields in a specific order. Will > open a separate jira to fix any other clients that might have also been > impacted by this API change, but, in the meantime, fixing the get_stat() perl > API first, since some production monitoring tools that we use are impacted by > it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2774) TS::AdminClient.pm's get_stat API broken in 5.0
[ https://issues.apache.org/jira/browse/TS-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13987911#comment-13987911 ] ASF subversion and git services commented on TS-2774: - Commit b1c3b758aaa33a20975724bcb0d906b4600886cd in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b1c3b75 ] TS-2774: TS::AdminClient.pm's get_stat API broken in 5.0 > TS::AdminClient.pm's get_stat API broken in 5.0 > --- > > Key: TS-2774 > URL: https://issues.apache.org/jira/browse/TS-2774 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Attachments: ts2774.diff > > > With the changes in TS-2637, the order in which the fields in the response > are sent, has been changed. This broke the get_stat() perl API in > TS::AdminClient, which expects the response fields in a specific order. Will > open a separate jira to fix any other clients that might have also been > impacted by this API change, but, in the meantime, fixing the get_stat() perl > API first, since some production monitoring tools that we use are impacted by > it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2774) TS::AdminClient.pm's get_stat API broken in 5.0
[ https://issues.apache.org/jira/browse/TS-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2774: -- Labels: spdy yahoo (was: SPDY_ATS yahoo) > TS::AdminClient.pm's get_stat API broken in 5.0 > --- > > Key: TS-2774 > URL: https://issues.apache.org/jira/browse/TS-2774 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Attachments: ts2774.diff > > > With the changes in TS-2637, the order in which the fields in the response > are sent, has been changed. This broke the get_stat() perl API in > TS::AdminClient, which expects the response fields in a specific order. Will > open a separate jira to fix any other clients that might have also been > impacted by this API change, but, in the meantime, fixing the get_stat() perl > API first, since some production monitoring tools that we use are impacted by > it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2774) TS::AdminClient.pm's get_stat API broken in 5.0
[ https://issues.apache.org/jira/browse/TS-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2774: -- Labels: SPDY_ATS yahoo (was: spdy yahoo) > TS::AdminClient.pm's get_stat API broken in 5.0 > --- > > Key: TS-2774 > URL: https://issues.apache.org/jira/browse/TS-2774 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: SPDY_ATS, yahoo > Attachments: ts2774.diff > > > With the changes in TS-2637, the order in which the fields in the response > are sent, has been changed. This broke the get_stat() perl API in > TS::AdminClient, which expects the response fields in a specific order. Will > open a separate jira to fix any other clients that might have also been > impacted by this API change, but, in the meantime, fixing the get_stat() perl > API first, since some production monitoring tools that we use are impacted by > it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2774) TS::AdminClient.pm's get_stat API broken in 5.0
[ https://issues.apache.org/jira/browse/TS-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-2774: -- Assignee: Bryan Call > TS::AdminClient.pm's get_stat API broken in 5.0 > --- > > Key: TS-2774 > URL: https://issues.apache.org/jira/browse/TS-2774 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Attachments: ts2774.diff > > > With the changes in TS-2637, the order in which the fields in the response > are sent, has been changed. This broke the get_stat() perl API in > TS::AdminClient, which expects the response fields in a specific order. Will > open a separate jira to fix any other clients that might have also been > impacted by this API change, but, in the meantime, fixing the get_stat() perl > API first, since some production monitoring tools that we use are impacted by > it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2774) TS::AdminClient.pm's get_stat API broken in 5.0
[ https://issues.apache.org/jira/browse/TS-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2774: --- Labels: spdy yahoo (was: SPDY_ATS yahoo) > TS::AdminClient.pm's get_stat API broken in 5.0 > --- > > Key: TS-2774 > URL: https://issues.apache.org/jira/browse/TS-2774 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Sudheer Vinukonda > Labels: spdy, yahoo > Attachments: ts2774.diff > > > With the changes in TS-2637, the order in which the fields in the response > are sent, has been changed. This broke the get_stat() perl API in > TS::AdminClient, which expects the response fields in a specific order. Will > open a separate jira to fix any other clients that might have also been > impacted by this API change, but, in the meantime, fixing the get_stat() perl > API first, since some production monitoring tools that we use are impacted by > it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2776) Core dump inside openssl library
[
https://issues.apache.org/jira/browse/TS-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2776:
--
Labels: SPDY_ATS yahoo (was: )
> Core dump inside openssl library
>
>
> Key: TS-2776
> URL: https://issues.apache.org/jira/browse/TS-2776
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Sudheer Vinukonda
> Labels: SPDY_ATS, yahoo
>
> During production testing of SPDY (w/ ATS compiled from master repo), noticed
> the below core from open ssl library. This core showed up after fixing a few
> other core dumps and memory leaks (refer TS-2742, TS-2743, TS-2750, TS-2765,
> TS-2767 etc) and happened once so far, after running stable for 30+ hours on
> a production host.
> {code}
> [example_prep.sh] Checking/Moving old cores...
> [TrafficServer] using root directory '/home/y'
> [TrafficManager] ==> Cleaning up and reissuing signal #15
> [TrafficManager] ==> signal #15
> [E. Mgmt] log ==> [TrafficManager] using root directory '/home/y'
> [example_prep.sh] Checking/Moving old cores...
> [TrafficServer] using root directory '/home/y'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x329720f500)[0x2b7dff1f6500]
> /usr/lib64/libssl.so.10[0x331622b2e7]
> /usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6db57f]
> /home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x418)[0x6ef488]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x6e3ee3]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x7109ff]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x43b)[0x71122b]
> /home/y/bin/traffic_server[0x70fdaa]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b7dff1ee851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> [E. Mgmt] log ==> [TrafficManager] using root directory '/home/y'
> [example_prep.sh] Checking/Moving old cores...
> [TrafficServer] using root directory '/home/y'
> {code}
> gdb output below:
> {code}
> (gdb) bt
> #0 0x00331622b2e7 in ?? () from /usr/lib64/libssl.so.10
> #1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
> #2 0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693,
> wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf= out>, needs=@0x2b7e111aec38)
> at SSLNetVConnection.cc:90
> #3 SSLNetVConnection::load_buffer_and_write (this=0x2b7f42c7ca70,
> towrite=207693, wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30,
> buf=, needs=@0x2b7e111aec38)
> at SSLNetVConnection.cc:399
> #4 0x006ef488 in write_to_net_io (nh=0x2b7e0f89ac10,
> vc=0x2b7f42c7ca70, thread=0x2b7e0f897010) at UnixNetVConnection.cc:527
> #5 0x006e3ee3 in NetHandler::mainNetEvent (this=0x2b7e0f89ac10,
> event=, e=) at UnixNet.cc:400
> #6 0x007109ff in handleEvent (this=0x2b7e0f897010, e=0x31ae0d0,
> calling_code=5) at I_Continuation.h:146
> #7 EThread::process_event (this=0x2b7e0f897010, e=0x31ae0d0, calling_code=5)
> at UnixEThread.cc:145
> #8 0x0071122b in EThread::execute (this=0x2b7e0f897010) at
> UnixEThread.cc:269
> #9 0x0070fdaa in spawn_thread_internal (a=0x2f8fbe0) at Thread.cc:88
> #10 0x2b7dff1ee851 in start_thread () from /lib64/libpthread.so.0
> #11 0x003296ee890d in clone () from /lib64/libc.so.6
> (gdb) up
> #1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
> (gdb) up
> #2 0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693,
> wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf= out>, needs=@0x2b7e111aec38)
> at SSLNetVConnection.cc:90
> 90SSLNetVConnection.cc: No such file or directory.
> in SSLNetVConnection.cc
> (gdb)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2776) Core dump inside openssl library
Sudheer Vinukonda created TS-2776:
-
Summary: Core dump inside openssl library
Key: TS-2776
URL: https://issues.apache.org/jira/browse/TS-2776
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
During production testing of SPDY (w/ ATS compiled from master repo), noticed
the below core from open ssl library. This core showed up after fixing a few
other core dumps and memory leaks (refer TS-2742, TS-2743, TS-2750, TS-2765,
TS-2767 etc) and happened once so far, after running stable for 30+ hours on a
production host.
{code}
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
[TrafficManager] ==> Cleaning up and reissuing signal #15
[TrafficManager] ==> signal #15
[E. Mgmt] log ==> [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b7dff1f6500]
/usr/lib64/libssl.so.10[0x331622b2e7]
/usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6db57f]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x418)[0x6ef488]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x6e3ee3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x7109ff]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x43b)[0x71122b]
/home/y/bin/traffic_server[0x70fdaa]
/lib64/libpthread.so.0(+0x3297207851)[0x2b7dff1ee851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[E. Mgmt] log ==> [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
{code}
gdb output below:
{code}
(gdb) bt
#0 0x00331622b2e7 in ?? () from /usr/lib64/libssl.so.10
#1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
#2 0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693,
wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf=, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:90
#3 SSLNetVConnection::load_buffer_and_write (this=0x2b7f42c7ca70,
towrite=207693, wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30,
buf=, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:399
#4 0x006ef488 in write_to_net_io (nh=0x2b7e0f89ac10,
vc=0x2b7f42c7ca70, thread=0x2b7e0f897010) at UnixNetVConnection.cc:527
#5 0x006e3ee3 in NetHandler::mainNetEvent (this=0x2b7e0f89ac10,
event=, e=) at UnixNet.cc:400
#6 0x007109ff in handleEvent (this=0x2b7e0f897010, e=0x31ae0d0,
calling_code=5) at I_Continuation.h:146
#7 EThread::process_event (this=0x2b7e0f897010, e=0x31ae0d0, calling_code=5)
at UnixEThread.cc:145
#8 0x0071122b in EThread::execute (this=0x2b7e0f897010) at
UnixEThread.cc:269
#9 0x0070fdaa in spawn_thread_internal (a=0x2f8fbe0) at Thread.cc:88
#10 0x2b7dff1ee851 in start_thread () from /lib64/libpthread.so.0
#11 0x003296ee890d in clone () from /lib64/libc.so.6
(gdb) up
#1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
(gdb) up
#2 0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693,
wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf=, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:90
90 SSLNetVConnection.cc: No such file or directory.
in SSLNetVConnection.cc
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2775) Add header info from Geo ACL plugin
Leif Hedstrom created TS-2775: - Summary: Add header info from Geo ACL plugin Key: TS-2775 URL: https://issues.apache.org/jira/browse/TS-2775 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom It'd be useful to get Geo info into headers, and since we have a Geo based ACL plugin, it seems reasonable to add that to this plugin. We'd also then have an option such as only adding header information, and defer the ACLs for the origin to decide (based on the header info). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2775) Add header info from Geo ACL plugin
[ https://issues.apache.org/jira/browse/TS-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2775: -- Fix Version/s: sometime > Add header info from Geo ACL plugin > --- > > Key: TS-2775 > URL: https://issues.apache.org/jira/browse/TS-2775 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: sometime > > > It'd be useful to get Geo info into headers, and since we have a Geo based > ACL plugin, it seems reasonable to add that to this plugin. We'd also then > have an option such as only adding header information, and defer the ACLs for > the origin to decide (based on the header info). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2775) Add header info from Geo ACL plugin
[ https://issues.apache.org/jira/browse/TS-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2775: - Assignee: Leif Hedstrom > Add header info from Geo ACL plugin > --- > > Key: TS-2775 > URL: https://issues.apache.org/jira/browse/TS-2775 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: sometime > > > It'd be useful to get Geo info into headers, and since we have a Geo based > ACL plugin, it seems reasonable to add that to this plugin. We'd also then > have an option such as only adding header information, and defer the ACLs for > the origin to decide (based on the header info). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2767) ATS Memory Leak related to SPDY
[
https://issues.apache.org/jira/browse/TS-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13987611#comment-13987611
]
Yunkai Zhang commented on TS-2767:
--
Ah, sorry, I'm also not an STL expert:(
Totally agree to remove STL, they just be used for quickly implementation.
> ATS Memory Leak related to SPDY
> ---
>
> Key: TS-2767
> URL: https://issues.apache.org/jira/browse/TS-2767
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
>Reporter: Sudheer Vinukonda
> Labels: SPDY_ATS, yahoo
> Fix For: 5.0.0
>
> Attachments: ts2767.diff
>
>
> During production testing of SPDY, we noticed ATS's memory quickly grows to
> about 20g RES and 31g VIRT and eventually becomes unresponsive. dstat shows a
> lot of disk/paging activity.
> Running Valgrind on a single request (using spdycat) shows the below possible
> leaks.
> {code}
> ==23000== 103 bytes in 1 blocks are possibly lost in loss record 3,133 of
> 3,823
> ==23000==at 0x4C285BC: operator new(unsigned long)
> (vg_replace_malloc.c:298)
> ==23000==by 0x72CC3C8: std::string::_Rep::_S_create(unsigned long,
> unsigned long, std::allocator const&) (in
> /usr/lib64/libstdc++.so.6.0.13)
> ==23000==by 0x72CD19A: std::string::_Rep::_M_clone(std::allocator
> const&, unsigned long) (in /usr/lib64/libstdc++.so.6.0.13)
> ==23000==by 0x72CD5EB: std::string::reserve(unsigned long) (in
> /usr/lib64/libstdc++.so.6.0.13)
> ==23000==by 0x72CDABE: std::string::append(std::string const&) (in
> /usr/lib64/libstdc++.so.6.0.13)
> ==23000==by 0x5D28DE: spdy_fetcher_launch(SpdyRequest*, TSFetchMethod)
> (basic_string.h:2165)
> ==23000==by 0x5D379D: spdy_on_ctrl_recv_callback(spdylay_session*,
> spdylay_frame_type, spdylay_frame*, void*) (SpdyCallbacks.cc:294)
> ==23000==by 0x715E9F: spdylay_session_on_syn_stream_received
> (spdylay_session.c:1782)
> ==23000==by 0x716BA6: spdylay_session_mem_recv (spdylay_session.c:2246)
> ==23000==by 0x716DD8: spdylay_session_recv (spdylay_session.c:2828)
> ==23000==by 0x5D0E57: spdy_default_handler(tsapi_cont*, TSEvent, void*)
> (SpdySM.cc:263)
> ==23000==by 0x6EC1A6: UnixNetVConnection::readSignalAndUpdate(int)
> (I_Continuation.h:146)
> ==23000==
> ==23000== 128 bytes in 1 blocks are possibly lost in loss record 3,256 of
> 3,823
> ==23000==at 0x4C285BC: operator new(unsigned long)
> (vg_replace_malloc.c:298)
> ==23000==by 0x5D3C8E: std::vector,
> std::allocator >
> >::_M_insert_aux(__gnu_cxx::__normal_iterator std::string>*, std::vector,
> std::allocator > > >,
> std::pair const&) (new_allocator.h:89)
> ==23000==by 0x5D32CF: spdy_on_ctrl_recv_callback(spdylay_session*,
> spdylay_frame_type, spdylay_frame*, void*) (stl_vector.h:741)
> ==23000==by 0x715E9F: spdylay_session_on_syn_stream_received
> (spdylay_session.c:1782)
> ==23000==by 0x716BA6: spdylay_session_mem_recv (spdylay_session.c:2246)
> ==23000==by 0x716DD8: spdylay_session_recv (spdylay_session.c:2828)
> ==23000==by 0x5D0E57: spdy_default_handler(tsapi_cont*, TSEvent, void*)
> (SpdySM.cc:263)
> ==23000==by 0x6EC1A6: UnixNetVConnection::readSignalAndUpdate(int)
> (I_Continuation.h:146)
> ==23000==by 0x6DC779: SSLNetVConnection::net_read_io(NetHandler*,
> EThread*) (SSLNetVConnection.cc:294)
> ==23000==by 0x6E39F1: NetHandler::mainNetEvent(int, Event*)
> (UnixNet.cc:384)
> ==23000==by 0x71059E: EThread::process_event(Event*, int)
> (I_Continuation.h:146)
> ==23000==by 0x710DCA: EThread::execute() (UnixEThread.cc:269)
> ==23000==
> ==23000== 173 bytes in 5 blocks are possibly lost in loss record 3,303 of
> 3,823
> ==23000==at 0x4C285BC: operator new(unsigned long)
> (vg_replace_malloc.c:298)
> ==23000==by 0x72CC3C8: std::string::_Rep::_S_create(unsigned long,
> unsigned long, std::allocator const&) (in
> /usr/lib64/libstdc++.so.6.0.13)
> ==23000==by 0x72CCDE4: ??? (in /usr/lib64/libstdc++.so.6.0.13)
> ==23000==by 0x72CCF32: std::basic_string,
> std::allocator >::basic_string(char const*, std::allocator
> const&) (in /usr/lib64/libstdc++.so.6.0.13)
> ==23000==by 0x5D32A2: spdy_on_ctrl_recv_callback(spdylay_session*,
> spdylay_frame_type, spdylay_frame*, void*) (stl_pair.h:101)
> ==23000==by 0x715E9F: spdylay_session_on_syn_stream_received
> (spdylay_session.c:1782)
> ==23000==by 0x716BA6: spdylay_session_mem_recv (spdylay_session.c:2246)
> ==23000==by 0x716DD8: spdylay_session_recv (spdylay_session.c:2828)
> ==23000==by 0x5D0E57: spdy_default_handler(tsapi_cont*, TSEvent, void*)
> (SpdySM.cc:263)
> ==23000==by 0x6EC1A6: UnixNetVConnection::readSignalAndUpdate(int)
> (I_Continuation.h:146)
> ==23000==by 0x6DC779: SSLNetVConnection::net_read_io(NetHandler*,
> EThread*) (SSLNetVConnection.cc:294
