[GitHub] trafficserver issue #1221: TS-5046: Guard against the server_session server_...
Github user sekimura commented on the issue: https://github.com/apache/trafficserver/pull/1221 @sidhuagarwal could you create a new JIRA issue with more info like stacktrace? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
[
https://issues.apache.org/jira/browse/TS-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masa Sekimura resolved TS-5046.
---
Resolution: Fixed
> SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
> -
>
> Key: TS-5046
> URL: https://issues.apache.org/jira/browse/TS-5046
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Network
>Reporter: Masa Sekimura
> Assignee: Masa Sekimura
> Fix For: 6.2.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> one of servers running 6.2.x (729c60b) got a SIGSEGV
> {code}
> (gdb) thread 42
> [Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> 41../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> (gdb) bt
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
> ctx=0x2aaab460bbc0) at Crash.cc:164
> #2
> #3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
> event=, p=) at HttpSM.cc:3108
> #4 0x2ace1d72 in HttpTunnel::producer_handler
> (this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
> p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
> #5 0x2ace3343 in HttpTunnel::producer_run
> (this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at
> HttpTunnel.cc:1020
> #6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
> p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
> #7 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #8 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
> edata=0x2ab9b4efac00) at xdebug.cc:295
> #11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #12 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #13 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
> event=, data=) at HttpSM.cc:1452
> #18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
> HttpSM.cc:7296
> #19 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #20 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #22 0x2aaabf4038d5 in cont_handle_response (contp=,
> event=, edata=0x2ab9b4efac00) at background_fetch.cc:544
> #23 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9d00,
> event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #24 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #25 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #26 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #27 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #28 0x0
[jira] [Assigned] (TS-5032) Assertion on current 6.2.x branch
[
https://issues.apache.org/jira/browse/TS-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masa Sekimura reassigned TS-5032:
-
Assignee: Leif Hedstrom (was: Masa Sekimura)
> Assertion on current 6.2.x branch
> -
>
> Key: TS-5032
> URL: https://issues.apache.org/jira/browse/TS-5032
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.1
>
>
> {code}
> #0 0x2d6bc37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81d37 in crash_logger_invoke (signo=6, info=0x2aaab440a330,
> ctx=0x2aaab440a200) at Crash.cc:164
> #2
> #3 0x2e807625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #4 0x2e808e05 in *__GI_abort () at abort.c:92
> #5 0x2b996060 in ink_abort
> (message_format=message_format@entry=0x2b9a302f "%s:%d: failed assertion
> `%s`") at ink_error.cc:79
> #6 0x2b994165 in _ink_assert (expression=,
> file=, line=) at ink_assert.cc:37
> #7 0x2abcb8d0 in ProxyClientSession::state_api_callout
> (this=0x2aaabe73, event=) at ProxyClientSession.cc:147
> #8 0x2acf0883 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #9 Http2ClientSession::state_complete_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:480
> #10 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #11 0x2acf10a2 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #12 Http2ClientSession::state_start_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:448
> #13 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #14 0x2ae6868b in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #15 read_signal_and_update (vc=0x2aab37097820, vc@entry=0x1,
> event=event@entry=100) at UnixNetVConnection.cc:148
> #16 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab37097820,
> event=event@entry=100) at UnixNetVConnection.cc:1030
> #17 0x2ae47e43 in SSLNetVConnection::net_read_io
> (this=0x2aab37097820, nh=0x2aaab2d0acc0, lthread=0x2aaab2d07000) at
> SSLNetVConnection.cc:598
> #18 0x2ae55d7c in NetHandler::mainNetEvent (this=0x2aaab2d0acc0,
> event=, e=) at UnixNet.cc:513
> #19 0x2ae8db76 in Continuation::handleEvent (data=0x2aaab0bfa1c0,
> event=5, this=) at I_Continuation.h:153
> #20 EThread::process_event (calling_code=5, e=0x2aaab0bfa1c0,
> this=0x2aaab2d07000) at UnixEThread.cc:148
> #21 EThread::execute (this=0x2aaab2d07000) at UnixEThread.cc:275
> #22 0x2ae8c976 in spawn_thread_internal (a=0x2aaab0b23d90) at
> Thread.cc:86
> #23 0x2d6b4aa1 in start_thread (arg=0x2aaab440b700) at
> pthread_create.c:301
> #24 0x2e8bd93d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5032) Assertion on current 6.2.x branch
[
https://issues.apache.org/jira/browse/TS-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15713085#comment-15713085
]
Masa Sekimura commented on TS-5032:
---
we can say this is a dup of TS-5046. +1 to close this.
> Assertion on current 6.2.x branch
> -
>
> Key: TS-5032
> URL: https://issues.apache.org/jira/browse/TS-5032
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
>Assignee: Masa Sekimura
> Fix For: 6.2.1
>
>
> {code}
> #0 0x2d6bc37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81d37 in crash_logger_invoke (signo=6, info=0x2aaab440a330,
> ctx=0x2aaab440a200) at Crash.cc:164
> #2
> #3 0x2e807625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #4 0x2e808e05 in *__GI_abort () at abort.c:92
> #5 0x2b996060 in ink_abort
> (message_format=message_format@entry=0x2b9a302f "%s:%d: failed assertion
> `%s`") at ink_error.cc:79
> #6 0x2b994165 in _ink_assert (expression=,
> file=, line=) at ink_assert.cc:37
> #7 0x2abcb8d0 in ProxyClientSession::state_api_callout
> (this=0x2aaabe73, event=) at ProxyClientSession.cc:147
> #8 0x2acf0883 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #9 Http2ClientSession::state_complete_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:480
> #10 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #11 0x2acf10a2 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #12 Http2ClientSession::state_start_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:448
> #13 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #14 0x2ae6868b in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #15 read_signal_and_update (vc=0x2aab37097820, vc@entry=0x1,
> event=event@entry=100) at UnixNetVConnection.cc:148
> #16 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab37097820,
> event=event@entry=100) at UnixNetVConnection.cc:1030
> #17 0x2ae47e43 in SSLNetVConnection::net_read_io
> (this=0x2aab37097820, nh=0x2aaab2d0acc0, lthread=0x2aaab2d07000) at
> SSLNetVConnection.cc:598
> #18 0x2ae55d7c in NetHandler::mainNetEvent (this=0x2aaab2d0acc0,
> event=, e=) at UnixNet.cc:513
> #19 0x2ae8db76 in Continuation::handleEvent (data=0x2aaab0bfa1c0,
> event=5, this=) at I_Continuation.h:153
> #20 EThread::process_event (calling_code=5, e=0x2aaab0bfa1c0,
> this=0x2aaab2d07000) at UnixEThread.cc:148
> #21 EThread::execute (this=0x2aaab2d07000) at UnixEThread.cc:275
> #22 0x2ae8c976 in spawn_thread_internal (a=0x2aaab0b23d90) at
> Thread.cc:86
> #23 0x2d6b4aa1 in start_thread (arg=0x2aaab440b700) at
> pthread_create.c:301
> #24 0x2e8bd93d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #1221: TS-5046: Guard against the server_session ...
Github user sekimura closed the pull request at: https://github.com/apache/trafficserver/pull/1221 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1221: TS-5046: Guard against the server_session server_...
Github user sekimura commented on the issue: https://github.com/apache/trafficserver/pull/1221 It looks good so far with #1232. I'm going to close this PR since we don't need this anymore. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1236: TS-5067 Fix required action for http2.enab...
GitHub user sekimura opened a pull request: https://github.com/apache/trafficserver/pull/1236 TS-5067 Fix required action for http2.enabled config I know this config is dead in 7.0.x and master already. It could be a nice-to-have fix for 6.2.x LTS. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sekimura/trafficserver http2-enabled-recu Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1236.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 #1236 commit ddf966b8666e31cd67654c0eae25250bff1d206e Author: Masa Sekimura Date: 2016-11-29T01:12:44Z TS-5067 Fix required action for http2.enabled config --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (TS-5067) proy.config.http2.enabled is not reloadable config
Masa Sekimura created TS-5067:
-
Summary: proy.config.http2.enabled is not reloadable config
Key: TS-5067
URL: https://issues.apache.org/jira/browse/TS-5067
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Masa Sekimura
On 6.2.x running server, when I modified proxy.config.http2.enabled via
traffic_ctl, I got this message.
{code}
set proxy.config.http2.enabled, please wait 10 seconds for traffic server
to sync configuration, restart is not required
{code}
But restarting traffic_server actually need to be done to take the effect.
I know this config is already dead in 7.0.x branch and master...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #1221: TS-5046: Guard against the server_session server_...
Github user sekimura commented on the issue: https://github.com/apache/trafficserver/pull/1221 I hope we don't. Give me a bit more time to test a build with #1232 handling some traffic in the wild. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TS-5032) Assertion on current 6.2.x branch
[
https://issues.apache.org/jira/browse/TS-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15688579#comment-15688579
]
Masa Sekimura commented on TS-5032:
---
I haven't seen this crash after applying my silly bandaid to local 6.2.x branch
https://github.com/apache/trafficserver/pull/1221
> Assertion on current 6.2.x branch
> -
>
> Key: TS-5032
> URL: https://issues.apache.org/jira/browse/TS-5032
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
>Assignee: Masa Sekimura
> Fix For: 6.2.1
>
>
> {code}
> #0 0x2d6bc37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81d37 in crash_logger_invoke (signo=6, info=0x2aaab440a330,
> ctx=0x2aaab440a200) at Crash.cc:164
> #2
> #3 0x2e807625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #4 0x2e808e05 in *__GI_abort () at abort.c:92
> #5 0x2b996060 in ink_abort
> (message_format=message_format@entry=0x2b9a302f "%s:%d: failed assertion
> `%s`") at ink_error.cc:79
> #6 0x2b994165 in _ink_assert (expression=,
> file=, line=) at ink_assert.cc:37
> #7 0x2abcb8d0 in ProxyClientSession::state_api_callout
> (this=0x2aaabe73, event=) at ProxyClientSession.cc:147
> #8 0x2acf0883 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #9 Http2ClientSession::state_complete_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:480
> #10 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #11 0x2acf10a2 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #12 Http2ClientSession::state_start_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:448
> #13 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #14 0x2ae6868b in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #15 read_signal_and_update (vc=0x2aab37097820, vc@entry=0x1,
> event=event@entry=100) at UnixNetVConnection.cc:148
> #16 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab37097820,
> event=event@entry=100) at UnixNetVConnection.cc:1030
> #17 0x2ae47e43 in SSLNetVConnection::net_read_io
> (this=0x2aab37097820, nh=0x2aaab2d0acc0, lthread=0x2aaab2d07000) at
> SSLNetVConnection.cc:598
> #18 0x2ae55d7c in NetHandler::mainNetEvent (this=0x2aaab2d0acc0,
> event=, e=) at UnixNet.cc:513
> #19 0x2ae8db76 in Continuation::handleEvent (data=0x2aaab0bfa1c0,
> event=5, this=) at I_Continuation.h:153
> #20 EThread::process_event (calling_code=5, e=0x2aaab0bfa1c0,
> this=0x2aaab2d07000) at UnixEThread.cc:148
> #21 EThread::execute (this=0x2aaab2d07000) at UnixEThread.cc:275
> #22 0x2ae8c976 in spawn_thread_internal (a=0x2aaab0b23d90) at
> Thread.cc:86
> #23 0x2d6b4aa1 in start_thread (arg=0x2aaab440b700) at
> pthread_create.c:301
> #24 0x2e8bd93d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
[
https://issues.apache.org/jira/browse/TS-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15688263#comment-15688263
]
Masa Sekimura commented on TS-5046:
---
I haven't tested this in the wild yet but backport PR is here:
https://github.com/apache/trafficserver/pull/1232
> SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
> -
>
> Key: TS-5046
> URL: https://issues.apache.org/jira/browse/TS-5046
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Network
>Reporter: Masa Sekimura
>Assignee: Susan Hinrichs
> Fix For: 6.2.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> one of servers running 6.2.x (729c60b) got a SIGSEGV
> {code}
> (gdb) thread 42
> [Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> 41../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> (gdb) bt
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
> ctx=0x2aaab460bbc0) at Crash.cc:164
> #2
> #3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
> event=, p=) at HttpSM.cc:3108
> #4 0x2ace1d72 in HttpTunnel::producer_handler
> (this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
> p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
> #5 0x2ace3343 in HttpTunnel::producer_run
> (this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at
> HttpTunnel.cc:1020
> #6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
> p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
> #7 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #8 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
> edata=0x2ab9b4efac00) at xdebug.cc:295
> #11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #12 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #13 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
> event=, data=) at HttpSM.cc:1452
> #18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
> HttpSM.cc:7296
> #19 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #20 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #22 0x2aaabf4038d5 in cont_handle_response (contp=,
> event=, edata=0x2ab9b4efac00) at background_fetch.cc:544
> #23 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9d00,
> event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #24 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #25 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #26 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #27 0x2a
[GitHub] trafficserver pull request #1232: TS-4938: Avoid crashes due to NULL vc dere...
GitHub user sekimura opened a pull request: https://github.com/apache/trafficserver/pull/1232 TS-4938: Avoid crashes due to NULL vc dereferences. Potentially this could fix TS-5046 SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p) cherry picked from commit 784e7cc8a91b48b93b57cad27ba403684880969f Conflicts: proxy/http/HttpSM.cc proxy/http/HttpServerSession.h You can merge this pull request into a Git repository by running: $ git pull https://github.com/sekimura/trafficserver ts-4938-backport Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1232.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 #1232 commit cb7d71a6b1a0789fe66c424c51f137787a12e70b Author: Susan Hinrichs Date: 2016-10-06T16:20:08Z TS-4938: Avoid crashes due to NULL vc dereferences. One more null check. Remove server_session null checks. And address James' comments. clang-format (cherry picked from commit 784e7cc8a91b48b93b57cad27ba403684880969f) Conflicts: proxy/http/HttpSM.cc proxy/http/HttpServerSession.h --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TS-4938) Crash due to null client_vc
[
https://issues.apache.org/jira/browse/TS-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15688130#comment-15688130
]
Masa Sekimura commented on TS-4938:
---
okay, I keep "HEAD" for hostdb changes and going to test it.
> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813. Have a fix that checks
> get_netvc() returns a non-NULL. Should make a more comprehensive review on
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0 0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at
> ../iocore/net/P_NetVConnection.h:60
> #1 0x0057dca4 in NetVConnection::get_local_port (this=0x0) at
> ../iocore/net/P_NetVConnection.h:82
> #2 0x00627844 in
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98,
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3 0x00632bd1 in HttpTransact::build_error_response
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY,
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4 0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98)
> at HttpTransact.cc:7789
> #5 0x00620bbc in HttpTransact::handle_server_connection_not_open
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6 0x0061fd43 in HttpTransact::handle_response_from_server
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7 0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at
> HttpTransact.cc:3401
> #8 0x005fc928 in HttpSM::call_transact_and_set_next_state
> (this=0x2b65700d4a20,
> f=0x61cf9a ) at
> HttpSM.cc:7116
> #9 0x005f6902 in HttpSM::handle_server_setup_error
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20,
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20,
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104,
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0,
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0,
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140,
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0,
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0,
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010,
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4938) Crash due to null client_vc
[
https://issues.apache.org/jira/browse/TS-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15688097#comment-15688097
]
Masa Sekimura commented on TS-4938:
---
getting merge conflicts ad cherry-picking this change to 6.2.x branch.
http://paste.fedoraproject.org/488654/47985294/
I'd like to have Susan to look at it.
> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813. Have a fix that checks
> get_netvc() returns a non-NULL. Should make a more comprehensive review on
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0 0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at
> ../iocore/net/P_NetVConnection.h:60
> #1 0x0057dca4 in NetVConnection::get_local_port (this=0x0) at
> ../iocore/net/P_NetVConnection.h:82
> #2 0x00627844 in
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98,
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3 0x00632bd1 in HttpTransact::build_error_response
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY,
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4 0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98)
> at HttpTransact.cc:7789
> #5 0x00620bbc in HttpTransact::handle_server_connection_not_open
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6 0x0061fd43 in HttpTransact::handle_response_from_server
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7 0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at
> HttpTransact.cc:3401
> #8 0x005fc928 in HttpSM::call_transact_and_set_next_state
> (this=0x2b65700d4a20,
> f=0x61cf9a ) at
> HttpSM.cc:7116
> #9 0x005f6902 in HttpSM::handle_server_setup_error
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20,
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20,
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104,
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0,
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0,
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140,
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0,
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0,
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010,
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #1227: TS-5051 Add a new log tag % AppVersionInfo.B...
Github user sekimura commented on the issue: https://github.com/apache/trafficserver/pull/1227 +1 to " a logging tag that can log an arbitrary metric" --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1227: TS-5051 Add a new log tag % AppVersio...
GitHub user sekimura opened a pull request: https://github.com/apache/trafficserver/pull/1227 TS-5051 Add a new log tag % AppVersionInfo.BldNumStr You can merge this pull request into a Git repository by running: $ git pull https://github.com/sekimura/trafficserver ts-5051 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1227.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 #1227 commit ead9d56da076b43ac8ddb02e48e6a03f78bd3b06 Author: Masa Sekimura Date: 2016-11-18T23:34:35Z TS-5051 Add a new log tag % AppVersionInfo.BldNumStr --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TS-5051) Adds a new log tag, proxy server build_number
[
https://issues.apache.org/jira/browse/TS-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15675366#comment-15675366
]
Masa Sekimura commented on TS-5051:
---
Actually trafficserver-release is not a build_number it's PACKAGE_VERSION, I
think
{code}
cat /usr/local/etc/trafficserver/trafficserver-release
7.0.0
{code}
What I am "wishing" is build_number which you can get from traffic_ctl metric
{code}
$ traffic_ctl metric get proxy.process.version.server.build_number
proxy.process.version.server.build_number 6.2.1-14.34
{code}
> Adds a new log tag, proxy server build_number
> -
>
> Key: TS-5051
> URL: https://issues.apache.org/jira/browse/TS-5051
> Project: Traffic Server
> Issue Type: Wish
> Components: Build, Logging
>Reporter: Masa Sekimura
> Fix For: 7.1.0
>
>
> For A/B testing and such, it would be nice if we can log build_number (eg
> "6.2.1-12.31").
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5051) Adds a new log tag, proxy server build_number
[ https://issues.apache.org/jira/browse/TS-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15675352#comment-15675352 ] Masa Sekimura commented on TS-5051: --- James, Thanks! Is there a way to do the same on 6.2.x branch? > Adds a new log tag, proxy server build_number > - > > Key: TS-5051 > URL: https://issues.apache.org/jira/browse/TS-5051 > Project: Traffic Server > Issue Type: Wish > Components: Build, Logging >Reporter: Masa Sekimura > Fix For: 7.1.0 > > > For A/B testing and such, it would be nice if we can log build_number (eg > "6.2.1-12.31"). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
[
https://issues.apache.org/jira/browse/TS-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15668079#comment-15668079
]
Masa Sekimura commented on TS-5046:
---
Here's the pull request with the bandaid above.
https://github.com/apache/trafficserver/pull/1221
> SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
> -
>
> Key: TS-5046
> URL: https://issues.apache.org/jira/browse/TS-5046
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Network
>Reporter: Masa Sekimura
>Assignee: Susan Hinrichs
> Fix For: 6.2.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> one of servers running 6.2.x (729c60b) got a SIGSEGV
> {code}
> (gdb) thread 42
> [Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> 41../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> (gdb) bt
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
> ctx=0x2aaab460bbc0) at Crash.cc:164
> #2
> #3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
> event=, p=) at HttpSM.cc:3108
> #4 0x2ace1d72 in HttpTunnel::producer_handler
> (this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
> p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
> #5 0x2ace3343 in HttpTunnel::producer_run
> (this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at
> HttpTunnel.cc:1020
> #6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
> p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
> #7 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #8 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
> edata=0x2ab9b4efac00) at xdebug.cc:295
> #11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #12 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #13 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
> event=, data=) at HttpSM.cc:1452
> #18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
> HttpSM.cc:7296
> #19 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #20 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #22 0x2aaabf4038d5 in cont_handle_response (contp=,
> event=, edata=0x2ab9b4efac00) at background_fetch.cc:544
> #23 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9d00,
> event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #24 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #25 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #26 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #27 0x2aaabe01ea45
[GitHub] trafficserver pull request #1221: TS-5046: Guard against the server_session ...
GitHub user sekimura opened a pull request: https://github.com/apache/trafficserver/pull/1221 TS-5046: Guard against the server_session server_vc being NULL Only happens with 6.2.x branch and I could not identify which commit fixed this in 7.0.x branch hence here is an bandaid. I'm happy to withdraw this PR if we can identify a commit in 7.0.x so that we can simply backport it to 6.2.x. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sekimura/trafficserver ts-5046 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1221.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 #1221 commit ef1d60246e5660f77ee0317f1e0d78a6ab75a1c6 Author: Masa Sekimura Date: 2016-11-15T19:36:20Z TS-5046: Guard against the server_session server_vc being NULL --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
[
https://issues.apache.org/jira/browse/TS-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masa Sekimura updated TS-5046:
--
Assignee: Susan Hinrichs
> SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
> -
>
> Key: TS-5046
> URL: https://issues.apache.org/jira/browse/TS-5046
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Network
>Reporter: Masa Sekimura
>Assignee: Susan Hinrichs
> Fix For: 6.2.1
>
>
> one of servers running 6.2.x (729c60b) got a SIGSEGV
> {code}
> (gdb) thread 42
> [Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> 41../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> (gdb) bt
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
> ctx=0x2aaab460bbc0) at Crash.cc:164
> #2
> #3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
> event=, p=) at HttpSM.cc:3108
> #4 0x2ace1d72 in HttpTunnel::producer_handler
> (this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
> p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
> #5 0x2ace3343 in HttpTunnel::producer_run
> (this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at
> HttpTunnel.cc:1020
> #6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
> p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
> #7 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #8 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
> edata=0x2ab9b4efac00) at xdebug.cc:295
> #11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #12 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #13 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
> event=, data=) at HttpSM.cc:1452
> #18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
> HttpSM.cc:7296
> #19 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #20 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #22 0x2aaabf4038d5 in cont_handle_response (contp=,
> event=, edata=0x2ab9b4efac00) at background_fetch.cc:544
> #23 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9d00,
> event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #24 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #25 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #26 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #27 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #28 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
>
[jira] [Commented] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
[
https://issues.apache.org/jira/browse/TS-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15665585#comment-15665585
]
Masa Sekimura commented on TS-5046:
---
There must be a proper way to fix this issue in 7.0.x branch already but here's
a bandaid I might want to try.
{code}
diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index b7a1be2..9344873 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -3105,7 +3105,10 @@ HttpSM::tunnel_handler_server(int event,
HttpTunnelProducer *p)
ua_session->attach_server_session(server_session);
} else {
// Release the session back into the shared session pool
-
server_session->get_netvc()->set_inactivity_timeout(HRTIME_SECONDS(t_state.txn_conf->keep_alive_no_activity_timeout_out));
+ NetVConnection *vc = server_session->get_netvc();
+ if (vc) {
+
vc->set_inactivity_timeout(HRTIME_SECONDS(t_state.txn_conf->keep_alive_no_activity_timeout_out));
+ }
server_session->release();
}
}
{code}
> SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
> -
>
> Key: TS-5046
> URL: https://issues.apache.org/jira/browse/TS-5046
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Network
>Reporter: Masa Sekimura
> Fix For: 6.2.1
>
>
> one of servers running 6.2.x (729c60b) got a SIGSEGV
> {code}
> (gdb) thread 42
> [Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> 41../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> (gdb) bt
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
> ctx=0x2aaab460bbc0) at Crash.cc:164
> #2
> #3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
> event=, p=) at HttpSM.cc:3108
> #4 0x2ace1d72 in HttpTunnel::producer_handler
> (this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
> p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
> #5 0x2ace3343 in HttpTunnel::producer_run
> (this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at
> HttpTunnel.cc:1020
> #6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
> p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
> #7 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #8 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
> edata=0x2ab9b4efac00) at xdebug.cc:295
> #11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #12 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #13 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
> event=, data=) at HttpSM.cc:1452
> #18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
> HttpSM.cc:7296
> #19 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #20 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #22 0x2aaabf4038d5 in cont_handle_response (contp=,
> ev
[jira] [Updated] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
[
https://issues.apache.org/jira/browse/TS-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masa Sekimura updated TS-5046:
--
Description:
one of servers running 6.2.x (729c60b) got a SIGSEGV
{code}
(gdb) thread 42
[Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
#0 0x2d6bd37d in __libc_waitpid (pid=,
stat_loc=, options=) at
../sysdeps/unix/sysv/linux/waitpid.c:41
41 ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
(gdb) bt
#0 0x2d6bd37d in __libc_waitpid (pid=,
stat_loc=, options=) at
../sysdeps/unix/sysv/linux/waitpid.c:41
#1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
ctx=0x2aaab460bbc0) at Crash.cc:164
#2
#3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
event=, p=) at HttpSM.cc:3108
#4 0x2ace1d72 in HttpTunnel::producer_handler
(this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
#5 0x2ace3343 in HttpTunnel::producer_run
(this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1020
#6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
#7 0x2ac96f8b in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1534
#8 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
edata=0x2ab9b4efac00) at xdebug.cc:295
#11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#12 0x2ac96d10 in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1452
#13 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
#16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
event=, data=) at HttpSM.cc:1452
#18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
HttpSM.cc:7296
#19 0x2ac96f8b in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1534
#20 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#22 0x2aaabf4038d5 in cont_handle_response (contp=,
event=, edata=0x2ab9b4efac00) at background_fetch.cc:544
#23 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9d00,
event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#24 0x2ac96d10 in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1452
#25 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#26 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#27 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
#28 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#29 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
event=, data=) at HttpSM.cc:1452
#30 0x2ac97b6f in HttpSM::state_read_server_response_header
(this=0x2ab9b4efac00, event=100, data=0x2aaaf59b3a98) at HttpSM.cc:1953
#31 0x2ac9e2bd in HttpSM::main_handler (this=0x2ab9b4efac00, event=100,
data=0x2aaaf59b3a98) at HttpSM.cc:2658
#32 0x2ae6956b in Continuation::handleEvent (data=0x2aaaf59b3a98,
event=100, this=) at
../../iocore/eventsystem/I_Continuation.h:153
#33 read_signal_and_update (vc=0x2aaaf59b3980, vc@entry=0x1,
event=event@entry=100) at UnixNetVConnection.cc:148
#34 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aaaf59b3980,
event=event@entry=100) at UnixNetVConnection.cc:1030
#35 0x2ae48cb3 in SSLNetVConnection::net_read_io (this=0x2aaaf59b3980,
nh
[jira] [Created] (TS-5051) Adds a new log tag, proxy server build_number
Masa Sekimura created TS-5051: - Summary: Adds a new log tag, proxy server build_number Key: TS-5051 URL: https://issues.apache.org/jira/browse/TS-5051 Project: Traffic Server Issue Type: Wish Reporter: Masa Sekimura For A/B testing and such, it would be nice if we can log build_number (eg "6.2.1-12.31"). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
[
https://issues.apache.org/jira/browse/TS-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masa Sekimura updated TS-5046:
--
Fix Version/s: 6.2.1
> SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
> -
>
> Key: TS-5046
> URL: https://issues.apache.org/jira/browse/TS-5046
> Project: Traffic Server
> Issue Type: Bug
> Reporter: Masa Sekimura
> Fix For: 6.2.1
>
>
> one of servers running 6.2.x (729c60b) got a SIGSEGV
> {code}
> (gdb) thread 42
> [Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> 41../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> (gdb) bt
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
> ctx=0x2aaab460bbc0) at Crash.cc:164
> #2
> #3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
> event=, p=) at HttpSM.cc:3108
> #4 0x2ace1d72 in HttpTunnel::producer_handler
> (this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
> p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
> #5 0x2ace3343 in HttpTunnel::producer_run
> (this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at
> HttpTunnel.cc:1020
> #6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
> p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
> #7 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #8 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
> edata=0x2ab9b4efac00) at xdebug.cc:295
> #11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #12 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #13 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
> event=, data=) at HttpSM.cc:1452
> #18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
> HttpSM.cc:7296
> #19 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #20 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #22 0x2aaabf4038d5 in cont_handle_response (contp=,
> event=, edata=0x2ab9b4efac00) at background_fetch.cc:544
> #23 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9d00,
> event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #24 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #25 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #26 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #27 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #28 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
> event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #29 0x2ac96d10
[jira] [Created] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
Masa Sekimura created TS-5046:
-
Summary: SEGV HttpSM::tunnel_handler_server(int event,
HttpTunnelProducer *p)
Key: TS-5046
URL: https://issues.apache.org/jira/browse/TS-5046
Project: Traffic Server
Issue Type: Bug
Reporter: Masa Sekimura
one of servers running 6.2.x (729c60b) got a SIGSEGV
{code}
(gdb) thread 42
[Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
#0 0x2d6bd37d in __libc_waitpid (pid=,
stat_loc=, options=) at
../sysdeps/unix/sysv/linux/waitpid.c:41
41 ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
(gdb) bt
#0 0x2d6bd37d in __libc_waitpid (pid=,
stat_loc=, options=) at
../sysdeps/unix/sysv/linux/waitpid.c:41
#1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
ctx=0x2aaab460bbc0) at Crash.cc:164
#2
#3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
event=, p=) at HttpSM.cc:3108
#4 0x2ace1d72 in HttpTunnel::producer_handler
(this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
#5 0x2ace3343 in HttpTunnel::producer_run
(this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1020
#6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
#7 0x2ac96f8b in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1534
#8 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
edata=0x2ab9b4efac00) at xdebug.cc:295
#11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#12 0x2ac96d10 in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1452
#13 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
#16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
event=, data=) at HttpSM.cc:1452
#18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
HttpSM.cc:7296
#19 0x2ac96f8b in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1534
#20 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#22 0x2aaabf4038d5 in cont_handle_response (contp=,
event=, edata=0x2ab9b4efac00) at background_fetch.cc:544
#23 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9d00,
event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#24 0x2ac96d10 in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1452
#25 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#26 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#27 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
#28 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#29 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
event=, data=) at HttpSM.cc:1452
#30 0x2ac97b6f in HttpSM::state_read_server_response_header
(this=0x2ab9b4efac00, event=100, data=0x2aaaf59b3a98) at HttpSM.cc:1953
#31 0x2ac9e2bd in HttpSM::main_handler (this=0x2ab9b4efac00, event=100,
data=0x2aaaf59b3a98) at HttpSM.cc:2658
#32 0x2ae6956b in Continuation::handleEvent (data=0x2aaaf59b3a98,
event=100, this=) at
../../iocore/eventsystem/I_Continuation.h:153
#33 read_signal_and_update (vc=0x2aaaf59b3980, vc@entry=0x1,
event=event@entry=100) at UnixNetVConnection.cc:148
#34 UnixNetVConnection::readSignalAndUpdate (this=this@entry
[jira] [Created] (TS-5042) Add failcount and threshold values in parent selection logging
Masa Sekimura created TS-5042: - Summary: Add failcount and threshold values in parent selection logging Key: TS-5042 URL: https://issues.apache.org/jira/browse/TS-5042 Project: Traffic Server Issue Type: Improvement Reporter: Masa Sekimura To debug and treak those retry values appropriately, it would be nice to have actual fail count and threshold values in the log. https://github.com/apache/trafficserver/pull/1198 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #1198: Add failcount and threshold values in pare...
GitHub user sekimura opened a pull request: https://github.com/apache/trafficserver/pull/1198 Add failcount and threshold values in parent selection logging To debug and treak those retry values appropriately, it would be nice to have actual fail count and threshold values in the log. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sekimura/trafficserver parent-selection-log Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1198.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 #1198 commit c7c3be5edb88c2586635af475b346a185819bf89 Author: Masa Sekimura Date: 2016-11-04T18:58:09Z Add failcount and threshold values in parent selection logging --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1188: TS-4717: Http2 stack explosion.
Github user sekimura commented on the issue: https://github.com/apache/trafficserver/pull/1188 I've updated this PR with `cherry-pick -x` --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TS-4717) Http2 stack explosion
[
https://issues.apache.org/jira/browse/TS-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15634977#comment-15634977
]
Masa Sekimura commented on TS-4717:
---
I've created the one.
https://github.com/apache/trafficserver/pull/1188
> Http2 stack explosion
> -
>
> Key: TS-4717
> URL: https://issues.apache.org/jira/browse/TS-4717
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> We see this periodically with high traffic loads. ATS crashes with 7000+
> frames on the stack. The bulk of the frames are the following frame
> sequence.
> {code}
> #117 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90,
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #118 0x0064c05d in Http2ClientSession::state_start_frame_read
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:451
> #119 0x0064b0af in Http2ClientSession::main_event_handler
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0) at
> Http2ClientSession.cc:292
> #120 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90,
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #121 0x0064c386 in Http2ClientSession::state_complete_frame_read
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:483
> #122 0x0064b0af in Http2ClientSession::main_event_handler
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0) at
> Http2ClientSession.cc:292
> #123 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90,
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #124 0x0064c05d in Http2ClientSession::state_start_frame_read
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:451
> {code}
> We had cherry picked in the fix for TS-4209 to correctly enforce the
> concurrent stream limit. But in the latest crash of this type, it looks like
> we are pulling small items from cache, so the stream lives and dies on the
> stack. The concurrent active connection count never reaches the limit.
> I am going to try to change the
> state_state_start_frame_read/state_complete_frame_read logic from recursing
> handlers to a loop.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #1188: TS-4717: Http2 stack explosion.
GitHub user sekimura opened a pull request: https://github.com/apache/trafficserver/pull/1188 TS-4717: Http2 stack explosion. This is a backport PR of https://github.com/apache/trafficserver/pull/842 You can merge this pull request into a Git repository by running: $ git pull https://github.com/sekimura/trafficserver ts-4717 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1188.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 #1188 commit 1e6cc95b0b7c3f1c72750289ee37097afc4d782e Author: Susan Hinrichs Date: 2016-08-08T18:36:41Z TS-4717: Http2 stack explosion. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TS-5033) Assertion on current 6.2.x branch
[
https://issues.apache.org/jira/browse/TS-5033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15634652#comment-15634652
]
Masa Sekimura commented on TS-5033:
---
because of the event=100, I guess this is related to
https://issues.apache.org/jira/browse/TS-4717
> Assertion on current 6.2.x branch
> -
>
> Key: TS-5033
> URL: https://issues.apache.org/jira/browse/TS-5033
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, HTTP/2
>Affects Versions: 6.2.1
>Reporter: Leif Hedstrom
> Fix For: 6.2.1
>
>
> {code}
> #0 0x2d6bc37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81d37 in crash_logger_invoke (signo=6, info=0x2aaab440a330,
> ctx=0x2aaab440a200) at Crash.cc:164
> #2
> #3 0x2e807625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #4 0x2e808e05 in *__GI_abort () at abort.c:92
> #5 0x2b996060 in ink_abort
> (message_format=message_format@entry=0x2b9a302f "%s:%d: failed assertion
> `%s`") at ink_error.cc:79
> #6 0x2b994165 in _ink_assert (expression=,
> file=, line=) at ink_assert.cc:37
> #7 0x2abcb8d0 in ProxyClientSession::state_api_callout
> (this=0x2aaabe73, event=) at ProxyClientSession.cc:147
> #8 0x2acf0883 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #9 Http2ClientSession::state_complete_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:480
> #10 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #11 0x2acf10a2 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #12 Http2ClientSession::state_start_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:448
> #13 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #14 0x2ae6868b in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #15 read_signal_and_update (vc=0x2aab37097820, vc@entry=0x1,
> event=event@entry=100) at UnixNetVConnection.cc:148
> #16 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab37097820,
> event=event@entry=100) at UnixNetVConnection.cc:1030
> #17 0x2ae47e43 in SSLNetVConnection::net_read_io
> (this=0x2aab37097820, nh=0x2aaab2d0acc0, lthread=0x2aaab2d07000) at
> SSLNetVConnection.cc:598
> #18 0x2ae55d7c in NetHandler::mainNetEvent (this=0x2aaab2d0acc0,
> event=, e=) at UnixNet.cc:513
> #19 0x2ae8db76 in Continuation::handleEvent (data=0x2aaab0bfa1c0,
> event=5, this=) at I_Continuation.h:153
> #20 EThread::process_event (calling_code=5, e=0x2aaab0bfa1c0,
> this=0x2aaab2d07000) at UnixEThread.cc:148
> #21 EThread::execute (this=0x2aaab2d07000) at UnixEThread.cc:275
> #22 0x2ae8c976 in spawn_thread_internal (a=0x2aaab0b23d90) at
> Thread.cc:86
> #23 0x2d6b4aa1 in start_thread (arg=0x2aaab440b700) at
> pthread_create.c:301
> #24 0x2e8bd93d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4717) Http2 stack explosion
[
https://issues.apache.org/jira/browse/TS-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15634544#comment-15634544
]
Masa Sekimura commented on TS-4717:
---
Is this one backported to 6.2.x yet?
> Http2 stack explosion
> -
>
> Key: TS-4717
> URL: https://issues.apache.org/jira/browse/TS-4717
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> We see this periodically with high traffic loads. ATS crashes with 7000+
> frames on the stack. The bulk of the frames are the following frame
> sequence.
> {code}
> #117 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90,
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #118 0x0064c05d in Http2ClientSession::state_start_frame_read
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:451
> #119 0x0064b0af in Http2ClientSession::main_event_handler
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0) at
> Http2ClientSession.cc:292
> #120 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90,
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #121 0x0064c386 in Http2ClientSession::state_complete_frame_read
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:483
> #122 0x0064b0af in Http2ClientSession::main_event_handler
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0) at
> Http2ClientSession.cc:292
> #123 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90,
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #124 0x0064c05d in Http2ClientSession::state_start_frame_read
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:451
> {code}
> We had cherry picked in the fix for TS-4209 to correctly enforce the
> concurrent stream limit. But in the latest crash of this type, it looks like
> we are pulling small items from cache, so the stream lives and dies on the
> stack. The concurrent active connection count never reaches the limit.
> I am going to try to change the
> state_state_start_frame_read/state_complete_frame_read logic from recursing
> handlers to a loop.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5026) update keep_alive_no_activity_timeout_in document and default value in template
[ https://issues.apache.org/jira/browse/TS-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masa Sekimura updated TS-5026: -- Assignee: Bryan Call > update keep_alive_no_activity_timeout_in document and default value in > template > --- > > Key: TS-5026 > URL: https://issues.apache.org/jira/browse/TS-5026 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Documentation > Reporter: Masa Sekimura >Assignee: Bryan Call > > TS-4700 made essential changes to update the default value. There are some > documents and a template for records.config need to be updated. > https://github.com/sekimura/trafficserver/commit/e6248331ae2f4a220e7cdaeadcd9214c1d860d1e > I'll make a pull request -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #1179: Update keep_alive_no_activity_timeout_in d...
GitHub user sekimura opened a pull request: https://github.com/apache/trafficserver/pull/1179 Update keep_alive_no_activity_timeout_in doc and template TS-4700 made essential changes to update the default value. There are some documents and a template for records.config need to be updated. This will make `traffic_ctl config diff` output cleaner. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sekimura/trafficserver TS-4700-keep_alive_no_activity_timeout_in-default Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1179.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 #1179 commit e6248331ae2f4a220e7cdaeadcd9214c1d860d1e Author: Masa Sekimura Date: 2016-11-02T21:10:13Z Update keep_alive_no_activity_timeout_in doc and template TS-4700 made essential changes to update the default value. There are some documents and a template for records.config need to be updated. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TS-5026) update keep_alive_no_activity_timeout_in document and default value in template
[ https://issues.apache.org/jira/browse/TS-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630636#comment-15630636 ] Masa Sekimura commented on TS-5026: --- This change will make `traffic_ctl config diff` cleaner and that's why I noticed records.config.default.in need to be updated. > update keep_alive_no_activity_timeout_in document and default value in > template > --- > > Key: TS-5026 > URL: https://issues.apache.org/jira/browse/TS-5026 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Documentation >Reporter: Masa Sekimura > > TS-4700 made essential changes to update the default value. There are some > documents and a template for records.config need to be updated. > https://github.com/sekimura/trafficserver/commit/e6248331ae2f4a220e7cdaeadcd9214c1d860d1e > I'll make a pull request -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5026) update keep_alive_no_activity_timeout_in document and default value in template
Masa Sekimura created TS-5026: - Summary: update keep_alive_no_activity_timeout_in document and default value in template Key: TS-5026 URL: https://issues.apache.org/jira/browse/TS-5026 Project: Traffic Server Issue Type: Improvement Components: Configuration, Documentation Reporter: Masa Sekimura TS-4700 made essential changes to update the default value. There are some documents and a template for records.config need to be updated. https://github.com/sekimura/trafficserver/commit/e6248331ae2f4a220e7cdaeadcd9214c1d860d1e I'll make a pull request -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-4207) Crash in HostDB, likely a regression from 5.x
[
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193986#comment-15193986
]
Masa Sekimura edited comment on TS-4207 at 3/15/16 5:09 AM:
I've opened another JIRA ticket for hostDB.levels change TS-4274
was (Author: msekimura):
I've opened another JIRA ticket for hostDB.level change TS-4274
> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0 0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1 0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at
> HttpSM.cc:2126
> #2 0x2ac9713d in HttpSM::main_handler(int, void*) () at
> HttpSM.cc:2561
> #3 0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) ()
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4 0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at
> HostDB.cc:1685
> #5 0x2ad98faf in DNSEntry::postEvent(int, Event*) () at
> ../../iocore/eventsystem/I_Continuation.h:153
> #6 0x2ae7e420 in EThread::process_event(Event*, int) () at
> I_Continuation.h:153
> #7 0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8 0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9 0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is
> NULL, but it somehow still ends up using r->rr ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x
[
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193986#comment-15193986
]
Masa Sekimura commented on TS-4207:
---
I've opened another JIRA ticket for hostDB.level change TS-4274
> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0 0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1 0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at
> HttpSM.cc:2126
> #2 0x2ac9713d in HttpSM::main_handler(int, void*) () at
> HttpSM.cc:2561
> #3 0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) ()
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4 0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at
> HostDB.cc:1685
> #5 0x2ad98faf in DNSEntry::postEvent(int, Event*) () at
> ../../iocore/eventsystem/I_Continuation.h:153
> #6 0x2ae7e420 in EThread::process_event(Event*, int) () at
> I_Continuation.h:153
> #7 0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8 0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9 0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is
> NULL, but it somehow still ends up using r->rr ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4274) make sure using the right levels as calling lookup_block
Masa Sekimura created TS-4274: - Summary: make sure using the right levels as calling lookup_block Key: TS-4274 URL: https://issues.apache.org/jira/browse/TS-4274 Project: Traffic Server Issue Type: Bug Components: HostDB Reporter: Masa Sekimura With a wrong "levels" value, lookup_block() could return the wrong block. Related Jira ticket "Crash in HostDB, likely a regression from 5.x" https://issues.apache.org/jira/browse/TS-4207 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x
[
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190389#comment-15190389
]
Masa Sekimura commented on TS-4207:
---
Actually It crashes with or without Leif's bandaid patch
(https://patch-diff.githubusercontent.com/raw/apache/trafficserver/pull/521.patch).
So it still could be related but not directly addressing the original issue.
I'll file another Jira ticket for this.
> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0 0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1 0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at
> HttpSM.cc:2126
> #2 0x2ac9713d in HttpSM::main_handler(int, void*) () at
> HttpSM.cc:2561
> #3 0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) ()
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4 0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at
> HostDB.cc:1685
> #5 0x2ad98faf in DNSEntry::postEvent(int, Event*) () at
> ../../iocore/eventsystem/I_Continuation.h:153
> #6 0x2ae7e420 in EThread::process_event(Event*, int) () at
> I_Continuation.h:153
> #7 0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8 0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9 0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is
> NULL, but it somehow still ends up using r->rr ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4207) Crash in HostDB, likely a regression from 5.x
[
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190375#comment-15190375
]
Masa Sekimura edited comment on TS-4207 at 3/11/16 2:30 AM:
I'd like to mention that if I comment out this section 6.1.x can be more stable.
{code}
@@ -1365,18 +1369,18 @@ HostDBContinuation::lookup_done(IpAddr const &ip, char
const *aname, bool around
}
}
- if (aname) {
-const size_t s_size = strlen(aname) + 1;
-void *host_dest = hostDB.alloc(&i->hostname_offset, s_size);
-if (host_dest) {
- ink_strlcpy((char *)host_dest, aname, s_size);
- *((char *)host_dest + s_size) = '\0';
-} else {
- Warning("Out of room in hostdb for hostname (data area full!)");
- hostDB.delete_block(i);
- return NULL;
-}
- }
+// if (aname) {
+//const size_t s_size = strlen(aname) + 1;
+//void *host_dest = hostDB.alloc(&i->hostname_offset, s_size);
+//if (host_dest) {
+// ink_strlcpy((char *)host_dest, aname, s_size);
+// *((char *)host_dest + s_size) = '\0';
+//} else {
+// Warning("Out of room in hostdb for hostname (data area full!)");
+// hostDB.delete_block(i);
+// return NULL;
+//}
+// }
{/code}
was (Author: msekimura):
I'd like to mention that if I comment out this section 6.1.x can be more stable.
{{code}}
@@ -1365,18 +1369,18 @@ HostDBContinuation::lookup_done(IpAddr const &ip, char
const *aname, bool around
}
}
- if (aname) {
-const size_t s_size = strlen(aname) + 1;
-void *host_dest = hostDB.alloc(&i->hostname_offset, s_size);
-if (host_dest) {
- ink_strlcpy((char *)host_dest, aname, s_size);
- *((char *)host_dest + s_size) = '\0';
-} else {
- Warning("Out of room in hostdb for hostname (data area full!)");
- hostDB.delete_block(i);
- return NULL;
-}
- }
+// if (aname) {
+//const size_t s_size = strlen(aname) + 1;
+//void *host_dest = hostDB.alloc(&i->hostname_offset, s_size);
+//if (host_dest) {
+// ink_strlcpy((char *)host_dest, aname, s_size);
+// *((char *)host_dest + s_size) = '\0';
+//} else {
+// Warning("Out of room in hostdb for hostname (data area full!)");
+// hostDB.delete_block(i);
+// return NULL;
+//}
+// }
{{/code}}
> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0 0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1 0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at
> HttpSM.cc:2126
> #2 0x2ac9713d in HttpSM::main_handler(int, void*) () at
> HttpSM.cc:2561
> #3 0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) ()
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4 0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at
> HostDB.cc:1685
> #5 0x2ad98faf in DNSEntry::postEvent(int, Event*) () at
> ../../iocore/eventsystem/I_Continuation.h:153
> #6 0x2ae7e420 in EThread::process_event(Event*, int) () at
> I_Continuation.h:153
> #7 0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8 0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9 0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is
> NULL, but it somehow still ends up using r->rr ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4207) Crash in HostDB, likely a regression from 5.x
[
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190375#comment-15190375
]
Masa Sekimura edited comment on TS-4207 at 3/11/16 2:30 AM:
I'd like to mention that if I comment out this section 6.1.x can be more stable.
{code}
@@ -1365,18 +1369,18 @@ HostDBContinuation::lookup_done(IpAddr const &ip, char
const *aname, bool around
}
}
- if (aname) {
-const size_t s_size = strlen(aname) + 1;
-void *host_dest = hostDB.alloc(&i->hostname_offset, s_size);
-if (host_dest) {
- ink_strlcpy((char *)host_dest, aname, s_size);
- *((char *)host_dest + s_size) = '\0';
-} else {
- Warning("Out of room in hostdb for hostname (data area full!)");
- hostDB.delete_block(i);
- return NULL;
-}
- }
+// if (aname) {
+//const size_t s_size = strlen(aname) + 1;
+//void *host_dest = hostDB.alloc(&i->hostname_offset, s_size);
+//if (host_dest) {
+// ink_strlcpy((char *)host_dest, aname, s_size);
+// *((char *)host_dest + s_size) = '\0';
+//} else {
+// Warning("Out of room in hostdb for hostname (data area full!)");
+// hostDB.delete_block(i);
+// return NULL;
+//}
+// }
{code}
was (Author: msekimura):
I'd like to mention that if I comment out this section 6.1.x can be more stable.
{code}
@@ -1365,18 +1369,18 @@ HostDBContinuation::lookup_done(IpAddr const &ip, char
const *aname, bool around
}
}
- if (aname) {
-const size_t s_size = strlen(aname) + 1;
-void *host_dest = hostDB.alloc(&i->hostname_offset, s_size);
-if (host_dest) {
- ink_strlcpy((char *)host_dest, aname, s_size);
- *((char *)host_dest + s_size) = '\0';
-} else {
- Warning("Out of room in hostdb for hostname (data area full!)");
- hostDB.delete_block(i);
- return NULL;
-}
- }
+// if (aname) {
+//const size_t s_size = strlen(aname) + 1;
+//void *host_dest = hostDB.alloc(&i->hostname_offset, s_size);
+//if (host_dest) {
+// ink_strlcpy((char *)host_dest, aname, s_size);
+// *((char *)host_dest + s_size) = '\0';
+//} else {
+// Warning("Out of room in hostdb for hostname (data area full!)");
+// hostDB.delete_block(i);
+// return NULL;
+//}
+// }
{/code}
> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0 0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1 0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at
> HttpSM.cc:2126
> #2 0x2ac9713d in HttpSM::main_handler(int, void*) () at
> HttpSM.cc:2561
> #3 0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) ()
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4 0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at
> HostDB.cc:1685
> #5 0x2ad98faf in DNSEntry::postEvent(int, Event*) () at
> ../../iocore/eventsystem/I_Continuation.h:153
> #6 0x2ae7e420 in EThread::process_event(Event*, int) () at
> I_Continuation.h:153
> #7 0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8 0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9 0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is
> NULL, but it somehow still ends up using r->rr ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x
[
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190375#comment-15190375
]
Masa Sekimura commented on TS-4207:
---
I'd like to mention that if I comment out this section 6.1.x can be more stable.
{{code}}
@@ -1365,18 +1369,18 @@ HostDBContinuation::lookup_done(IpAddr const &ip, char
const *aname, bool around
}
}
- if (aname) {
-const size_t s_size = strlen(aname) + 1;
-void *host_dest = hostDB.alloc(&i->hostname_offset, s_size);
-if (host_dest) {
- ink_strlcpy((char *)host_dest, aname, s_size);
- *((char *)host_dest + s_size) = '\0';
-} else {
- Warning("Out of room in hostdb for hostname (data area full!)");
- hostDB.delete_block(i);
- return NULL;
-}
- }
+// if (aname) {
+//const size_t s_size = strlen(aname) + 1;
+//void *host_dest = hostDB.alloc(&i->hostname_offset, s_size);
+//if (host_dest) {
+// ink_strlcpy((char *)host_dest, aname, s_size);
+// *((char *)host_dest + s_size) = '\0';
+//} else {
+// Warning("Out of room in hostdb for hostname (data area full!)");
+// hostDB.delete_block(i);
+// return NULL;
+//}
+// }
{{/code}}
> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0 0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1 0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at
> HttpSM.cc:2126
> #2 0x2ac9713d in HttpSM::main_handler(int, void*) () at
> HttpSM.cc:2561
> #3 0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) ()
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4 0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at
> HostDB.cc:1685
> #5 0x2ad98faf in DNSEntry::postEvent(int, Event*) () at
> ../../iocore/eventsystem/I_Continuation.h:153
> #6 0x2ae7e420 in EThread::process_event(Event*, int) () at
> I_Continuation.h:153
> #7 0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8 0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9 0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is
> NULL, but it somehow still ends up using r->rr ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4207) Crash in HostDB, likely a regression from 5.x
[
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158299#comment-15158299
]
Masa Sekimura edited comment on TS-4207 at 2/23/16 6:27 PM:
I've just noticed that inside of HostDBContinuation::insert, lookup_block is
using hardcoded value "3" for levels. It's unlikely to match that md5 value but
it's possible match a different block due to the hardcoded value? If so,
hostDB.delete_block(old_r) can be deleting a different block.
{code}
diff --git a/iocore/hostdb/HostDB.cc b/iocore/hostdb/HostDB.cc
index eb5b541..0101848 100644
--- a/iocore/hostdb/HostDB.cc
+++ b/iocore/hostdb/HostDB.cc
@@ -743,7 +743,7 @@ HostDBContinuation::insert(unsigned int attl)
ink_assert(this_ethread() == hostDB.lock_for_bucket(bucket)->thread_holding);
// remove the old one to prevent buildup
- HostDBInfo *old_r = hostDB.lookup_block(folded_md5, 3);
+ HostDBInfo *old_r = hostDB.lookup_block(folded_md5, hostDB.levels);
if (old_r)
hostDB.delete_block(old_r);
HostDBInfo *r = hostDB.insert_block(folded_md5, NULL, 0);
{code}
was (Author: msekimura):
I've just noticed that inside of HostDBContinuation::insert, lookup_block is
using hardcoded value "3" for levels. It's unlikely to match that md5 value but
it's possible match a different block due to the hardcoded value? If so,
hostDB.delete_block(old_r) can be deleting a different block.
{code}
diff --git a/iocore/hostdb/HostDB.cc b/iocore/hostdb/HostDB.cc
index eb5b541..0101848 100644
--- a/iocore/hostdb/HostDB.cc
+++ b/iocore/hostdb/HostDB.cc
@@ -743,7 +743,7 @@ HostDBContinuation::insert(unsigned int attl)
ink_assert(this_ethread() == hostDB.lock_for_bucket(bucket)->thread_holding);
// remove the old one to prevent buildup
- HostDBInfo *old_r = hostDB.lookup_block(folded_md5, 3);
+ HostDBInfo *old_r = hostDB.lookup_block(folded_md5, hostdb.levels);
if (old_r)
hostDB.delete_block(old_r);
HostDBInfo *r = hostDB.insert_block(folded_md5, NULL, 0);
{code}
> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0 0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1 0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at
> HttpSM.cc:2126
> #2 0x2ac9713d in HttpSM::main_handler(int, void*) () at
> HttpSM.cc:2561
> #3 0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) ()
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4 0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at
> HostDB.cc:1685
> #5 0x2ad98faf in DNSEntry::postEvent(int, Event*) () at
> ../../iocore/eventsystem/I_Continuation.h:153
> #6 0x2ae7e420 in EThread::process_event(Event*, int) () at
> I_Continuation.h:153
> #7 0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8 0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9 0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is
> NULL, but it somehow still ends up using r->rr ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x
[
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158299#comment-15158299
]
Masa Sekimura commented on TS-4207:
---
I've just noticed that inside of HostDBContinuation::insert, lookup_block is
using hardcoded value "3" for levels. It's unlikely to match that md5 value but
it's possible match a different block due to the hardcoded value? If so,
hostDB.delete_block(old_r) can be deleting a different block.
{code}
diff --git a/iocore/hostdb/HostDB.cc b/iocore/hostdb/HostDB.cc
index eb5b541..0101848 100644
--- a/iocore/hostdb/HostDB.cc
+++ b/iocore/hostdb/HostDB.cc
@@ -743,7 +743,7 @@ HostDBContinuation::insert(unsigned int attl)
ink_assert(this_ethread() == hostDB.lock_for_bucket(bucket)->thread_holding);
// remove the old one to prevent buildup
- HostDBInfo *old_r = hostDB.lookup_block(folded_md5, 3);
+ HostDBInfo *old_r = hostDB.lookup_block(folded_md5, hostdb.levels);
if (old_r)
hostDB.delete_block(old_r);
HostDBInfo *r = hostDB.insert_block(folded_md5, NULL, 0);
{code}
> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0 0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1 0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at
> HttpSM.cc:2126
> #2 0x2ac9713d in HttpSM::main_handler(int, void*) () at
> HttpSM.cc:2561
> #3 0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) ()
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4 0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at
> HostDB.cc:1685
> #5 0x2ad98faf in DNSEntry::postEvent(int, Event*) () at
> ../../iocore/eventsystem/I_Continuation.h:153
> #6 0x2ae7e420 in EThread::process_event(Event*, int) () at
> I_Continuation.h:153
> #7 0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8 0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9 0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is
> NULL, but it somehow still ends up using r->rr ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3948) crashed at json_out_stat() with sprintf format mismatch
Masa Sekimura created TS-3948: - Summary: crashed at json_out_stat() with sprintf format mismatch Key: TS-3948 URL: https://issues.apache.org/jira/browse/TS-3948 Project: Traffic Server Issue Type: Bug Reporter: Masa Sekimura We ran into a core dump with the below stack trace. Record data_type was RECD_INT(0x1) in RecDumpRecords():RecCore.cc:963 but somehow it became TS_RECORDDATATYPE_STRING(0x3) which caused sprintf format error in json_out_stat():stats_over_http.c:176 (gdb) where #0 0x2e7d662e in _IO_default_xsputn_internal () from /lib64/libc.so.6 #1 0x2e7a732a in vfprintf () from /lib64/libc.so.6 #2 0x2e861aa0 in __vsnprintf_chk () from /lib64/libc.so.6 #3 0x2e8619da in __snprintf_chk () from /lib64/libc.so.6 #4 0x2aaab77f2617 in snprintf (rec_type=, edata=0x2ae56bb16c80, registered=, name=, data_type=, datum=) at /usr/include/bits/stdio2.h:65 #5 json_out_stat (rec_type=, edata=0x2ae56bb16c80, registered=, name=, data_type=, datum=) at stats_over_http.c:176 #6 0x2ae46ac5 in RecDumpRecords (rec_type=38, callback=0x2aaab77f2540 , edata=0x2ae56bb16c80) at RecCore.cc:963 #7 0x2aaab77f2891 in json_out_stats (contp=, event=TS_EVENT_VCONN_WRITE_READY, edata=0x2abca167bf70) at stats_over_http.c:189 #8 stats_process_write (contp=, event=TS_EVENT_VCONN_WRITE_READY, edata=0x2abca167bf70) at stats_over_http.c:204 #9 stats_dostuff (contp=, event=TS_EVENT_VCONN_WRITE_READY, edata=0x2abca167bf70) at stats_over_http.c:227 #10 0x2abc7b1a in PluginVC::process_write_side (this=0x2abca167be20, other_side_call=false) at PluginVC.cc:547 #11 0x2abc9be5 in PluginVC::main_handler (this=0x2abca167be20, event=, data=0x2aaab2c26840) at PluginVC.cc:208 #12 0x2ae545b8 in handleEvent (this=0x2aaab23a, e=0x2aaab2c26840, calling_code=1) at I_Continuation.h:145 #13 EThread::process_event (this=0x2aaab23a, e=0x2aaab2c26840, calling_code=1) at UnixEThread.cc:128 #14 0x2ae54edb in EThread::execute (this=0x2aaab23a) at UnixEThread.cc:179 #15 0x2ae5398a in spawn_thread_internal (a=0x2b8124f0) at Thread.cc:85 #16 0x2c9439d1 in start_thread () from /lib64/libpthread.so.0 #17 0x2e84a8fd in clone () from /lib64/libc.so.6 (gdb) f 6 #6 0x2ae46ac5 in RecDumpRecords (rec_type=38, callback=0x2aaab77f2540 , edata=0x2ae56bb16c80) at RecCore.cc:963 963 in RecCore.cc (gdb) p rec_type $20 = 38 (gdb) p edata $21 = (void *) 0x2ae56bb16c80 (gdb) p r->registered $22 = true (gdb) p r->name $23 = 0x2b7ba580 "proxy.process.ssl.origin_server_decryption_failed" (gdb) p r->data_type $24 = RECD_INT (gdb) p &r->data $25 = (RecData *) 0x2b76f380 (gdb) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
