[jira] [Commented] (TS-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619550#comment-13619550
]
Yunkai Zhang commented on TS-1006:
--
Do you use master for testing? Or does this issue happen on your private branch
which had been backported from master?
It works well for us in product environment for more than one months.
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Fix For: 3.3.3
Attachments:
0001-TS-1006-Add-an-enable-reclaimable-freelist-option.patch,
0002-TS-1006-Add-a-new-wrapper-ink_atomic_decrement.patch,
0003-TS-1006-Introduce-a-reclaimable-InkFreeList.patch,
0004-TS-1006-Make-InkFreeList-memory-pool-configurable.patch,
Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 |
memory/RemapPluginsAlloc
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |128
[jira] [Commented] (TS-1713) Querying SRV record doesn't work
[
https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619555#comment-13619555
]
weijin commented on TS-1713:
virtual size_t estimated_heap_bytes_per_entry() const { return
sizeof(HostDBInfo) * 2 + 512; }
sorry, I made a mistake.
if we config 12 entries. then the hostdb has
12 entries for level1, (12 * 64)
15000 entries for level0, (15000 * 64)
and
estimated_heap_bytes_per_entry * (12 + 15000) for heap
the total size is 64 * 12 + 64 * 15000 + 640 * 135000 = 9504 (90M)
so total storage 100M is enough.
Querying SRV record doesn't work
Key: TS-1713
URL: https://issues.apache.org/jira/browse/TS-1713
Project: Traffic Server
Issue Type: Bug
Components: DNS
Reporter: Li-Wen Hsu
Assignee: weijin
Fix For: 3.3.2
Attachments: support_srv.patch, ts-1713.diff
For ATS 3.0.x, when setting CONFIG proxy.config.srv_enabled INT 1 in
records.config , ATS blocks and return nothing to client, even no 404.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619594#comment-13619594 ] ASF subversion and git services commented on TS-1713: - Commit 349d11d217a77e11be5746450c4af9fef581d3ea in branch refs/heads/master from Zhao Yongming ming@gmail.com [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=349d11d ] add TS-1713 Querying SRV record doesn't work Key: TS-1713 URL: https://issues.apache.org/jira/browse/TS-1713 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: Li-Wen Hsu Assignee: weijin Fix For: 3.3.2 Attachments: support_srv.patch, ts-1713.diff For ATS 3.0.x, when setting CONFIG proxy.config.srv_enabled INT 1 in records.config , ATS blocks and return nothing to client, even no 404. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1791) changing the Format in the LogFormat of logs_xml.config may crash the log collation
[ https://issues.apache.org/jira/browse/TS-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619599#comment-13619599 ] ASF subversion and git services commented on TS-1791: - Commit 91ba85cac417088567c82bc626b71be64b568355 in branch refs/heads/master from Zhao Yongming ming@gmail.com [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=91ba85c ] TS-1791: remove m_mutex acquirerelease to avoid deadlock changing the Format in the LogFormat of logs_xml.config may crash the log collation --- Key: TS-1791 URL: https://issues.apache.org/jira/browse/TS-1791 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 3.3.3 in some heavy system, the change will lock up the server by some dead locking, that is a bad code that not removed in the last big logging patch, my fault :( the bad code is in ~LogBufferList() and Gan Li(nick as quehan) in my team is working on this fix, may provide an patch asap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1341) Calling TSCacheHookAdd from a plugin compiles, but results in undefined object
[
https://issues.apache.org/jira/browse/TS-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619776#comment-13619776
]
Yunkai Zhang commented on TS-1341:
--
Now, TSCacheHookAdd was removed, how to implement hooks for cache? :(
Calling TSCacheHookAdd from a plugin compiles, but results in undefined
object
Key: TS-1341
URL: https://issues.apache.org/jira/browse/TS-1341
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.3.0
Reporter: Otto van der Schaaf
Assignee: Leif Hedstrom
Fix For: 3.3.0
Calling TSCacheHookAdd from a plugin compiles, but results in an undefined
object error when starting traffic server
[Jul 10 14:22:18.459] Server {0x7ffd30759740} ERROR: unable to load
'/usr/local/libexec/trafficserver/cache_control.so':
/usr/local/libexec/trafficserver/cache_control.so: undefined symbol:
TSCacheHookAdd
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1797) when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers.
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-1797: Assignee: Bin Chen when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. - Key: TS-1797 URL: https://issues.apache.org/jira/browse/TS-1797 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Maybe one clusterHandler have created(connection is establish) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1797) when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers.
Bin Chen created TS-1797: Summary: when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Key: TS-1797 URL: https://issues.apache.org/jira/browse/TS-1797 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Maybe one clusterHandler have created(connection is establish) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers.
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1797: - Summary: when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers. (was: when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers.) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers. -- Key: TS-1797 URL: https://issues.apache.org/jira/browse/TS-1797 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Maybe one clusterHandler have created(connection is establish) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers.
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619794#comment-13619794 ] Bin Chen commented on TS-1797: -- in ClusterHandler *ClusterMachine::pop_ClusterHandler. when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers. -- Key: TS-1797 URL: https://issues.apache.org/jira/browse/TS-1797 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Maybe one clusterHandler have created(connection is establish) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler.
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1797: - Summary: when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler. (was: when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers.) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler. Key: TS-1797 URL: https://issues.apache.org/jira/browse/TS-1797 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Maybe one clusterHandler have created(connection is establish) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler().
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1797: - Summary: when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler(). (was: when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler.) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler(). -- Key: TS-1797 URL: https://issues.apache.org/jira/browse/TS-1797 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Maybe one clusterHandler have created(connection is establish) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619848#comment-13619848 ] Leif Hedstrom commented on TS-1713: --- Hmmm, ok. I'd recommend we reduce the storage entries then. It's absolutely crazy that we'd consume 15000 bytes (15KB) for each entry. A vast majority of people will never use SRV records, in forward proxy it's all but guaranteed that a single entry fits in a 512 byte UDP package. Does the new calculation assume that every entry is SRV ? Or does it always consume roughly 3x the amount of storage now, even if there are no SRV records? I understand 100MB is nothing for your boxes, but I know there are plenty of use cases where a small memory footprint is important. Like, the way I use it, this change would double my memory footprint (unless I tweak the configs myself). I much rather have the settings somewhat reasonable for some large number of people (i.e. small footprint) and let the ones who needs SRV records change the configs (I don't know of anyone except Taobao that are using SRV records). Querying SRV record doesn't work Key: TS-1713 URL: https://issues.apache.org/jira/browse/TS-1713 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: Li-Wen Hsu Assignee: weijin Fix For: 3.3.2 Attachments: support_srv.patch, ts-1713.diff For ATS 3.0.x, when setting CONFIG proxy.config.srv_enabled INT 1 in records.config , ATS blocks and return nothing to client, even no 404. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619882#comment-13619882 ] Leif Hedstrom commented on TS-1713: --- Thinking about it, would it be possible such that if SRV records is disabled (it used to have a records.config option?) we use the old storage sizes? Querying SRV record doesn't work Key: TS-1713 URL: https://issues.apache.org/jira/browse/TS-1713 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: Li-Wen Hsu Assignee: weijin Fix For: 3.3.2 Attachments: support_srv.patch, ts-1713.diff For ATS 3.0.x, when setting CONFIG proxy.config.srv_enabled INT 1 in records.config , ATS blocks and return nothing to client, even no 404. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1341) Calling TSCacheHookAdd from a plugin compiles, but results in undefined object
[
https://issues.apache.org/jira/browse/TS-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619927#comment-13619927
]
Leif Hedstrom commented on TS-1341:
---
Well, this hook was to replace the native cache, there are other hooks / APIs
to get into the native cache.
Calling TSCacheHookAdd from a plugin compiles, but results in undefined
object
Key: TS-1341
URL: https://issues.apache.org/jira/browse/TS-1341
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.3.0
Reporter: Otto van der Schaaf
Assignee: Leif Hedstrom
Fix For: 3.3.0
Calling TSCacheHookAdd from a plugin compiles, but results in an undefined
object error when starting traffic server
[Jul 10 14:22:18.459] Server {0x7ffd30759740} ERROR: unable to load
'/usr/local/libexec/trafficserver/cache_control.so':
/usr/local/libexec/trafficserver/cache_control.so: undefined symbol:
TSCacheHookAdd
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1798) Crash report: UnixNetProcessor::connect_re_internal UnixNetProcessor::allocateThread
Zhao Yongming created TS-1798:
-
Summary: Crash report: UnixNetProcessor::connect_re_internal
UnixNetProcessor::allocateThread
Key: TS-1798
URL: https://issues.apache.org/jira/browse/TS-1798
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
here is a stack which occured in the current master tree
{code}
[root@localhost trafficserver]# cat traffic.out
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2afd236e5500]
/usr/bin/traffic_server(UnixNetProcessor::allocateThread(EThread*)+0x4)[0x66b404]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x2e)[0x66c27e]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x6a8)[0x5287f8]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4dd)[0x52fbad]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x52ac94]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x52c858]
/usr/bin/traffic_server[0x66ee21]
/usr/bin/traffic_server[0x6731b5]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x669ff2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2afd236dd851]
/lib64/libc.so.6(clone+0x6d)[0x2afd25d6f11d]
[TrafficServer] using root directory '/usr
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1798) Crash report: UnixNetProcessor::connect_re_internal UnixNetProcessor::allocateThread
[
https://issues.apache.org/jira/browse/TS-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1798:
Labels: crash (was: )
Crash report: UnixNetProcessor::connect_re_internal
UnixNetProcessor::allocateThread
---
Key: TS-1798
URL: https://issues.apache.org/jira/browse/TS-1798
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.3.2
here is a stack which occured in the current master tree
{code}
[root@localhost trafficserver]# cat traffic.out
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2afd236e5500]
/usr/bin/traffic_server(UnixNetProcessor::allocateThread(EThread*)+0x4)[0x66b404]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x2e)[0x66c27e]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x6a8)[0x5287f8]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4dd)[0x52fbad]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x52ac94]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x52c858]
/usr/bin/traffic_server[0x66ee21]
/usr/bin/traffic_server[0x6731b5]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x669ff2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2afd236dd851]
/lib64/libc.so.6(clone+0x6d)[0x2afd25d6f11d]
[TrafficServer] using root directory '/usr
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1798) Crash report: UnixNetProcessor::connect_re_internal UnixNetProcessor::allocateThread
[
https://issues.apache.org/jira/browse/TS-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620022#comment-13620022
]
James Peach commented on TS-1798:
-
Any steps to reproduce?
Crash report: UnixNetProcessor::connect_re_internal
UnixNetProcessor::allocateThread
---
Key: TS-1798
URL: https://issues.apache.org/jira/browse/TS-1798
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.3.2
here is a stack which occured in the current master tree
{code}
[root@localhost trafficserver]# cat traffic.out
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2afd236e5500]
/usr/bin/traffic_server(UnixNetProcessor::allocateThread(EThread*)+0x4)[0x66b404]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x2e)[0x66c27e]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x6a8)[0x5287f8]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4dd)[0x52fbad]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x52ac94]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x52c858]
/usr/bin/traffic_server[0x66ee21]
/usr/bin/traffic_server[0x6731b5]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x669ff2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2afd236dd851]
/lib64/libc.so.6(clone+0x6d)[0x2afd25d6f11d]
[TrafficServer] using root directory '/usr
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1798) Crash report: UnixNetProcessor::connect_re_internal UnixNetProcessor::allocateThread
[
https://issues.apache.org/jira/browse/TS-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1798:
Fix Version/s: 3.3.2
Crash report: UnixNetProcessor::connect_re_internal
UnixNetProcessor::allocateThread
---
Key: TS-1798
URL: https://issues.apache.org/jira/browse/TS-1798
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Fix For: 3.3.2
here is a stack which occured in the current master tree
{code}
[root@localhost trafficserver]# cat traffic.out
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2afd236e5500]
/usr/bin/traffic_server(UnixNetProcessor::allocateThread(EThread*)+0x4)[0x66b404]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x2e)[0x66c27e]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x6a8)[0x5287f8]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4dd)[0x52fbad]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x52ac94]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x52c858]
/usr/bin/traffic_server[0x66ee21]
/usr/bin/traffic_server[0x6731b5]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x669ff2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2afd236dd851]
/lib64/libc.so.6(clone+0x6d)[0x2afd25d6f11d]
[TrafficServer] using root directory '/usr
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1766) resurrect unit test programs
[ https://issues.apache.org/jira/browse/TS-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620030#comment-13620030 ] ASF subversion and git services commented on TS-1766: - Commit 2918fc1cf74a54cc0a17887fa0ebf75294c09365 in branch refs/heads/master from James Peach jpe...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2918fc1 ] TS-1766: Add iocore/eventsystem tests to the build resurrect unit test programs Key: TS-1766 URL: https://issues.apache.org/jira/browse/TS-1766 Project: Traffic Server Issue Type: Bug Components: Cleanup, Core Reporter: James Peach Assignee: James Peach Fix For: 3.3.4 There are a lot of test source files in the source tree that are never built into actual test programs. We should build these into standalone test programs so that make check runs them as unit tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1766) resurrect unit test programs
[ https://issues.apache.org/jira/browse/TS-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620129#comment-13620129 ] ASF subversion and git services commented on TS-1766: - Commit 3f905d527b1ae73e241f1a174f0d0b0853029590 in branch refs/heads/master from James Peach jpe...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3f905d5 ] TS-1766: add TCL libs to unit tests resurrect unit test programs Key: TS-1766 URL: https://issues.apache.org/jira/browse/TS-1766 Project: Traffic Server Issue Type: Bug Components: Cleanup, Core Reporter: James Peach Assignee: James Peach Fix For: 3.3.4 There are a lot of test source files in the source tree that are never built into actual test programs. We should build these into standalone test programs so that make check runs them as unit tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1736) Fatal() terminate process without logging backtrace
[ https://issues.apache.org/jira/browse/TS-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620133#comment-13620133 ] ASF subversion and git services commented on TS-1736: - Commit 82ce5ff1919a0c15e44b47dba36967db0acc427b in branch refs/heads/master from [~yunkai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=82ce5ff ] TS-1736: Fatal() terminates process without a backtrace The root casue is that cleanup_func() was called before logging backtrace in Diags::error(), however cleanup_func() would terminate process by calling exit() directly. Fatal() terminate process without logging backtrace --- Key: TS-1736 URL: https://issues.apache.org/jira/browse/TS-1736 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Yunkai Zhang Assignee: James Peach Fix For: 3.3.2 Attachments: 0001-diags-Fatal-terminate-process-without-logging-backtr-V2.patch, 0001-diags-Fatal-terminate-process-without-logging-backtr-V3.patch The root casue is that cleanup_func() was called before logging backtrace in Diags::error(), however cleanup_func() would terminate process by calling exit() directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620251#comment-13620251 ] Uri Shachar commented on TS-1125: - Sure -- adding a knob would be better then what we currently have. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Priority: Minor Fix For: 3.3.3 Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1067) Remove unused config (and code) for bandwidth management
[ https://issues.apache.org/jira/browse/TS-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620297#comment-13620297 ] ASF subversion and git services commented on TS-1067: - Commit 197e918ca54289cb6f32a9dd7876e8ddcc587d60 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=197e918 ] TS-1067 Remove unused config (and code) for bandwidth management Remove unused config (and code) for bandwidth management Key: TS-1067 URL: https://issues.apache.org/jira/browse/TS-1067 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.2 There's a configuration file, and code, related to bandwidth management for the old UDP based streaming media protocols, that were part of the core (it's long since gone). We should remove this for now, and possibly (for future plugins) add APIs appropriate for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1067) Remove unused config (and code) for bandwidth management
[ https://issues.apache.org/jira/browse/TS-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620298#comment-13620298 ] ASF subversion and git services commented on TS-1067: - Commit bfc78c736da2336fc05b83faab2a4381229b6e21 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bfc78c7 ] TS-1067 Add a new config option, proxy.config.ssl.number.threads, and code Remove unused config (and code) for bandwidth management Key: TS-1067 URL: https://issues.apache.org/jira/browse/TS-1067 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.2 There's a configuration file, and code, related to bandwidth management for the old UDP based streaming media protocols, that were part of the core (it's long since gone). We should remove this for now, and possibly (for future plugins) add APIs appropriate for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1067) Remove unused config (and code) for bandwidth management
[ https://issues.apache.org/jira/browse/TS-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620300#comment-13620300 ] ASF subversion and git services commented on TS-1067: - Commit 20dacb06b94c276f157e57370d66fc663649ba5b in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=20dacb0 ] TS-1067 Fix the global variable that we read periodic_cleanup into. Remove unused config (and code) for bandwidth management Key: TS-1067 URL: https://issues.apache.org/jira/browse/TS-1067 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.2 There's a configuration file, and code, related to bandwidth management for the old UDP based streaming media protocols, that were part of the core (it's long since gone). We should remove this for now, and possibly (for future plugins) add APIs appropriate for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1067) Remove unused config (and code) for bandwidth management
[ https://issues.apache.org/jira/browse/TS-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620304#comment-13620304 ] ASF subversion and git services commented on TS-1067: - Commit 5cf774a13cf07b7bb66457d39ddf0e8a5abdd6ad in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5cf774a ] TS-1067 Remove a few more unused variables, to get builds going Remove unused config (and code) for bandwidth management Key: TS-1067 URL: https://issues.apache.org/jira/browse/TS-1067 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.2 There's a configuration file, and code, related to bandwidth management for the old UDP based streaming media protocols, that were part of the core (it's long since gone). We should remove this for now, and possibly (for future plugins) add APIs appropriate for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1783) Eliminate the wpad.dat configuration option (it's unused)
[ https://issues.apache.org/jira/browse/TS-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620394#comment-13620394 ] ASF subversion and git services commented on TS-1783: - Commit 86b17cc139ff0580d987b91e49b90106d570e4e7 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=86b17cc ] TS-1783 Eliminate the wpad.dat configuration option (it's unused). Eliminate the wpad.dat configuration option (it's unused) - Key: TS-1783 URL: https://issues.apache.org/jira/browse/TS-1783 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1783) Eliminate the wpad.dat configuration option (it's unused)
[ https://issues.apache.org/jira/browse/TS-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620395#comment-13620395 ] ASF subversion and git services commented on TS-1783: - Commit 8f7f66a77a0bf544bab0930b29d79b8e365cd1d4 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8f7f66a ] TS-1783 Remove the remnants of wpad.dat Eliminate the wpad.dat configuration option (it's unused) - Key: TS-1783 URL: https://issues.apache.org/jira/browse/TS-1783 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1496) Traffic Server with null-transform buffering large responses when client connection slow
[
https://issues.apache.org/jira/browse/TS-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620406#comment-13620406
]
Alan M. Carroll commented on TS-1496:
-
1) I'll take a look. I just copied what was there originally.
2) You have a transform you want to keep running even if it is not being cached
and the user agent client disconnects. You need a sink to keep the tunnel
operating and consume transform output.
3) I think that will require an additional fix.
Traffic Server with null-transform buffering large responses when client
connection slow
Key: TS-1496
URL: https://issues.apache.org/jira/browse/TS-1496
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.0
Environment: Red Hat 6.3
Reporter: snf
Assignee: Alan M. Carroll
Fix For: 3.3.2
Attachments: ts-1496.diff, TS-1496.patch, TS-1496.patch
Scenario: Traffic Server started with the null-transform plugin. The link
between the client and Traffic Server is slower than the link between the
Traffic Server and the Origin Server.
Affect: If the client requests a large file from the Origin Server, the
whole file can be transmitted to, and buffered by, Traffic Server before
content is released to the client. This is a bigger issue if a large number
of clients request large files then the Traffic Server could end up buffering
very large amounts of content.
Expected behaviour: The Traffic Server should not download all the content
from the Origin Server. Instead, if the client is slow receiving from
Traffic Server, then Traffic Server should be slow receiving from the Origin
Server. Traffic Server should facilitate end to end flow control between
client and Origin Server.
Tools to replicate problem: Use Traffic Control to set a lower bandwidth on
the client machine.
Possible related area in the Traffic Server code: The following comment
appears in proxy/http/Httptunnel.cc
48 static void
49 chunked_reenable(HttpTunnelProducer * p, HttpTunnel * tunnel)
50 {
51
52 // FIX ME: still need to deal with huge chunk sizes. If a chunk
53 // is 1GB, we will currently buffer the whole thing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1799) Segmentation fault (git master)
bettydramit created TS-1799: --- Summary: Segmentation fault (git master) Key: TS-1799 URL: https://issues.apache.org/jira/browse/TS-1799 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: bettydramit [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b20d9026500] /usr/bin/traffic_server(_ZN18UnixNetVConnection11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x18)[0x6708b8] /usr/bin/traffic_server(_ZN18HttpSessionManager15release_sessionEP17HttpServerSession+0x7d)[0x515b2d] /usr/bin/traffic_server(_ZN6HttpSM21tunnel_handler_serverEiP18HttpTunnelProducer+0x2ff)[0x523faf] /usr/bin/traffic_server(_ZN10HttpTunnel16producer_handlerEiP18HttpTunnelProducer+0x196)[0x565ba6] /usr/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x666)[0x5666c6] /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56694d] /usr/bin/traffic_server(_ZN14ClusterHandler25cluster_signal_and_updateEiP18ClusterVConnectionP17ClusterVConnState+0x33)[0x605b43] /usr/bin/traffic_server(_ZN14ClusterHandler20valid_for_data_writeEP18ClusterVConnection+0x61e)[0x60316e] /usr/bin/traffic_server(_ZN14ClusterHandler23build_write_descriptorsEv+0xbd)[0x6034cd] /usr/bin/traffic_server[0x604490] /usr/bin/traffic_server(_ZN14ClusterHandler16mainClusterEventEiP5Event+0x1e4)[0x604774] /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x84)[0x694964] /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4b3)[0x695343] /usr/bin/traffic_server[0x6938e2] /lib64/libpthread.so.0(+0x7851)[0x2b20d901e851] /lib64/libc.so.6(clone+0x6d)[0x2b20db6b090d] [E. Mgmt] log == [TrafficManager] using root directory '/usr' [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b8d852ea500] /usr/bin/traffic_server(_ZN18UnixNetVConnection11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x18)[0x6708b8] /usr/bin/traffic_server(_ZN18HttpSessionManager15release_sessionEP17HttpServerSession+0x7d)[0x515b2d] /usr/bin/traffic_server(_ZN6HttpSM21tunnel_handler_serverEiP18HttpTunnelProducer+0x2ff)[0x523faf] /usr/bin/traffic_server(_ZN10HttpTunnel16producer_handlerEiP18HttpTunnelProducer+0x196)[0x565ba6] /usr/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x666)[0x5666c6] /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56694d] /usr/bin/traffic_server(_ZN14ClusterHandler25cluster_signal_and_updateEiP18ClusterVConnectionP17ClusterVConnState+0x33)[0x605b43] /usr/bin/traffic_server(_ZN14ClusterHandler20valid_for_data_writeEP18ClusterVConnection+0x61e)[0x60316e] /usr/bin/traffic_server(_ZN14ClusterHandler23build_write_descriptorsEv+0xbd)[0x6034cd] /usr/bin/traffic_server[0x604490] /usr/bin/traffic_server(_ZN14ClusterHandler16mainClusterEventEiP5Event+0x1e4)[0x604774] /usr/bin/traffic_server(_ZN12ClusterState10IOCompleteEv+0xc2)[0x60b472] /usr/bin/traffic_server(_ZN12ClusterState16doIO_write_eventEiPv+0x109)[0x60b7e9] /usr/bin/traffic_server[0x66f321] /usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x671b57] /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x66a086] /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x84)[0x694964] /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4b3)[0x695343] /usr/bin/traffic_server[0x6938e2] /lib64/libpthread.so.0(+0x7851)[0x2b8d852e2851] /lib64/libc.so.6(clone+0x6d)[0x2b8d8797490d] [E. Mgmt] log == [TrafficManager] using root directory '/usr' [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b12fb535500] /usr/bin/traffic_server(_ZN18UnixNetVConnection11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x18)[0x6708b8] /usr/bin/traffic_server(_ZN18HttpSessionManager15release_sessionEP17HttpServerSession+0x7d)[0x515b2d] /usr/bin/traffic_server(_ZN6HttpSM21tunnel_handler_serverEiP18HttpTunnelProducer+0x2ff)[0x523faf] /usr/bin/traffic_server(_ZN10HttpTunnel16producer_handlerEiP18HttpTunnelProducer+0x196)[0x565ba6] /usr/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x666)[0x5666c6] /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56694d] /usr/bin/traffic_server(_ZN14ClusterHandler25cluster_signal_and_updateEiP18ClusterVConnectionP17ClusterVConnState+0x33)[0x605b43] /usr/bin/traffic_server(_ZN14ClusterHandler20valid_for_data_writeEP18ClusterVConnection+0x61e)[0x60316e] /usr/bin/traffic_server(_ZN14ClusterHandler23build_write_descriptorsEv+0xbd)[0x6034cd] /usr/bin/traffic_server[0x604490]
[jira] [Updated] (TS-1799) Segmentation fault (git master) at cluster
[ https://issues.apache.org/jira/browse/TS-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-1799: Summary: Segmentation fault (git master) at cluster (was: Segmentation fault (git master)) Segmentation fault (git master) at cluster --- Key: TS-1799 URL: https://issues.apache.org/jira/browse/TS-1799 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: bettydramit [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b20d9026500] /usr/bin/traffic_server(_ZN18UnixNetVConnection11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x18)[0x6708b8] /usr/bin/traffic_server(_ZN18HttpSessionManager15release_sessionEP17HttpServerSession+0x7d)[0x515b2d] /usr/bin/traffic_server(_ZN6HttpSM21tunnel_handler_serverEiP18HttpTunnelProducer+0x2ff)[0x523faf] /usr/bin/traffic_server(_ZN10HttpTunnel16producer_handlerEiP18HttpTunnelProducer+0x196)[0x565ba6] /usr/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x666)[0x5666c6] /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56694d] /usr/bin/traffic_server(_ZN14ClusterHandler25cluster_signal_and_updateEiP18ClusterVConnectionP17ClusterVConnState+0x33)[0x605b43] /usr/bin/traffic_server(_ZN14ClusterHandler20valid_for_data_writeEP18ClusterVConnection+0x61e)[0x60316e] /usr/bin/traffic_server(_ZN14ClusterHandler23build_write_descriptorsEv+0xbd)[0x6034cd] /usr/bin/traffic_server[0x604490] /usr/bin/traffic_server(_ZN14ClusterHandler16mainClusterEventEiP5Event+0x1e4)[0x604774] /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x84)[0x694964] /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4b3)[0x695343] /usr/bin/traffic_server[0x6938e2] /lib64/libpthread.so.0(+0x7851)[0x2b20d901e851] /lib64/libc.so.6(clone+0x6d)[0x2b20db6b090d] [E. Mgmt] log == [TrafficManager] using root directory '/usr' [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b8d852ea500] /usr/bin/traffic_server(_ZN18UnixNetVConnection11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x18)[0x6708b8] /usr/bin/traffic_server(_ZN18HttpSessionManager15release_sessionEP17HttpServerSession+0x7d)[0x515b2d] /usr/bin/traffic_server(_ZN6HttpSM21tunnel_handler_serverEiP18HttpTunnelProducer+0x2ff)[0x523faf] /usr/bin/traffic_server(_ZN10HttpTunnel16producer_handlerEiP18HttpTunnelProducer+0x196)[0x565ba6] /usr/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x666)[0x5666c6] /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56694d] /usr/bin/traffic_server(_ZN14ClusterHandler25cluster_signal_and_updateEiP18ClusterVConnectionP17ClusterVConnState+0x33)[0x605b43] /usr/bin/traffic_server(_ZN14ClusterHandler20valid_for_data_writeEP18ClusterVConnection+0x61e)[0x60316e] /usr/bin/traffic_server(_ZN14ClusterHandler23build_write_descriptorsEv+0xbd)[0x6034cd] /usr/bin/traffic_server[0x604490] /usr/bin/traffic_server(_ZN14ClusterHandler16mainClusterEventEiP5Event+0x1e4)[0x604774] /usr/bin/traffic_server(_ZN12ClusterState10IOCompleteEv+0xc2)[0x60b472] /usr/bin/traffic_server(_ZN12ClusterState16doIO_write_eventEiPv+0x109)[0x60b7e9] /usr/bin/traffic_server[0x66f321] /usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x671b57] /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x66a086] /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x84)[0x694964] /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4b3)[0x695343] /usr/bin/traffic_server[0x6938e2] /lib64/libpthread.so.0(+0x7851)[0x2b8d852e2851] /lib64/libc.so.6(clone+0x6d)[0x2b8d8797490d] [E. Mgmt] log == [TrafficManager] using root directory '/usr' [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b12fb535500] /usr/bin/traffic_server(_ZN18UnixNetVConnection11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x18)[0x6708b8] /usr/bin/traffic_server(_ZN18HttpSessionManager15release_sessionEP17HttpServerSession+0x7d)[0x515b2d] /usr/bin/traffic_server(_ZN6HttpSM21tunnel_handler_serverEiP18HttpTunnelProducer+0x2ff)[0x523faf] /usr/bin/traffic_server(_ZN10HttpTunnel16producer_handlerEiP18HttpTunnelProducer+0x196)[0x565ba6] /usr/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x666)[0x5666c6] /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56694d]
[jira] [Updated] (TS-1799) Segmentation fault (git master) at cluster
[ https://issues.apache.org/jira/browse/TS-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-1799: Affects Version/s: 3.3.2 Segmentation fault (git master) at cluster --- Key: TS-1799 URL: https://issues.apache.org/jira/browse/TS-1799 Project: Traffic Server Issue Type: Bug Components: Clustering Affects Versions: 3.3.2 Reporter: bettydramit [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b20d9026500] /usr/bin/traffic_server(_ZN18UnixNetVConnection11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x18)[0x6708b8] /usr/bin/traffic_server(_ZN18HttpSessionManager15release_sessionEP17HttpServerSession+0x7d)[0x515b2d] /usr/bin/traffic_server(_ZN6HttpSM21tunnel_handler_serverEiP18HttpTunnelProducer+0x2ff)[0x523faf] /usr/bin/traffic_server(_ZN10HttpTunnel16producer_handlerEiP18HttpTunnelProducer+0x196)[0x565ba6] /usr/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x666)[0x5666c6] /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56694d] /usr/bin/traffic_server(_ZN14ClusterHandler25cluster_signal_and_updateEiP18ClusterVConnectionP17ClusterVConnState+0x33)[0x605b43] /usr/bin/traffic_server(_ZN14ClusterHandler20valid_for_data_writeEP18ClusterVConnection+0x61e)[0x60316e] /usr/bin/traffic_server(_ZN14ClusterHandler23build_write_descriptorsEv+0xbd)[0x6034cd] /usr/bin/traffic_server[0x604490] /usr/bin/traffic_server(_ZN14ClusterHandler16mainClusterEventEiP5Event+0x1e4)[0x604774] /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x84)[0x694964] /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4b3)[0x695343] /usr/bin/traffic_server[0x6938e2] /lib64/libpthread.so.0(+0x7851)[0x2b20d901e851] /lib64/libc.so.6(clone+0x6d)[0x2b20db6b090d] [E. Mgmt] log == [TrafficManager] using root directory '/usr' [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b8d852ea500] /usr/bin/traffic_server(_ZN18UnixNetVConnection11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x18)[0x6708b8] /usr/bin/traffic_server(_ZN18HttpSessionManager15release_sessionEP17HttpServerSession+0x7d)[0x515b2d] /usr/bin/traffic_server(_ZN6HttpSM21tunnel_handler_serverEiP18HttpTunnelProducer+0x2ff)[0x523faf] /usr/bin/traffic_server(_ZN10HttpTunnel16producer_handlerEiP18HttpTunnelProducer+0x196)[0x565ba6] /usr/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x666)[0x5666c6] /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56694d] /usr/bin/traffic_server(_ZN14ClusterHandler25cluster_signal_and_updateEiP18ClusterVConnectionP17ClusterVConnState+0x33)[0x605b43] /usr/bin/traffic_server(_ZN14ClusterHandler20valid_for_data_writeEP18ClusterVConnection+0x61e)[0x60316e] /usr/bin/traffic_server(_ZN14ClusterHandler23build_write_descriptorsEv+0xbd)[0x6034cd] /usr/bin/traffic_server[0x604490] /usr/bin/traffic_server(_ZN14ClusterHandler16mainClusterEventEiP5Event+0x1e4)[0x604774] /usr/bin/traffic_server(_ZN12ClusterState10IOCompleteEv+0xc2)[0x60b472] /usr/bin/traffic_server(_ZN12ClusterState16doIO_write_eventEiPv+0x109)[0x60b7e9] /usr/bin/traffic_server[0x66f321] /usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x671b57] /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x66a086] /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x84)[0x694964] /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4b3)[0x695343] /usr/bin/traffic_server[0x6938e2] /lib64/libpthread.so.0(+0x7851)[0x2b8d852e2851] /lib64/libc.so.6(clone+0x6d)[0x2b8d8797490d] [E. Mgmt] log == [TrafficManager] using root directory '/usr' [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b12fb535500] /usr/bin/traffic_server(_ZN18UnixNetVConnection11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x18)[0x6708b8] /usr/bin/traffic_server(_ZN18HttpSessionManager15release_sessionEP17HttpServerSession+0x7d)[0x515b2d] /usr/bin/traffic_server(_ZN6HttpSM21tunnel_handler_serverEiP18HttpTunnelProducer+0x2ff)[0x523faf] /usr/bin/traffic_server(_ZN10HttpTunnel16producer_handlerEiP18HttpTunnelProducer+0x196)[0x565ba6] /usr/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x666)[0x5666c6] /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56694d] /usr/bin/traffic_server(_ZN14ClusterHandler25cluster_signal_and_updateEiP18ClusterVConnectionP17ClusterVConnState+0x33)[0x605b43]
[jira] [Updated] (TS-1799) Segmentation fault (git master) at cluster
[
https://issues.apache.org/jira/browse/TS-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-1799:
--
Description:
{code}
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b20d9026500]
/usr/bin/traffic_server(UnixNetVConnection::do_io_write(Continuation*, long,
IOBufferReader*, bool)+0x18)[0x6708b8]
/usr/bin/traffic_server(HttpSessionManager::release_session(HttpServerSession*)+0x7d)[0x515b2d]
/usr/bin/traffic_server(HttpSM::tunnel_handler_server(int,
HttpTunnelProducer*)+0x2ff)[0x523faf]
/usr/bin/traffic_server(HttpTunnel::producer_handler(int,
HttpTunnelProducer*)+0x196)[0x565ba6]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x666)[0x5666c6]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x56694d]
/usr/bin/traffic_server(ClusterHandler::cluster_signal_and_update(int,
ClusterVConnection*, ClusterVConnState*)+0x33)[0x605b43]
/usr/bin/traffic_server(ClusterHandler::valid_for_data_write(ClusterVConnection*)+0x61e)[0x60316e]
/usr/bin/traffic_server(ClusterHandler::build_write_descriptors()+0xbd)[0x6034cd]
/usr/bin/traffic_server[0x604490]
/usr/bin/traffic_server(ClusterHandler::mainClusterEvent(int,
Event*)+0x1e4)[0x604774]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2b20d901e851]
/lib64/libc.so.6(clone+0x6d)[0x2b20db6b090d]
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b8d852ea500]
/usr/bin/traffic_server(UnixNetVConnection::do_io_write(Continuation*, long,
IOBufferReader*, bool)+0x18)[0x6708b8]
/usr/bin/traffic_server(HttpSessionManager::release_session(HttpServerSession*)+0x7d)[0x515b2d]
/usr/bin/traffic_server(HttpSM::tunnel_handler_server(int,
HttpTunnelProducer*)+0x2ff)[0x523faf]
/usr/bin/traffic_server(HttpTunnel::producer_handler(int,
HttpTunnelProducer*)+0x196)[0x565ba6]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x666)[0x5666c6]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x56694d]
/usr/bin/traffic_server(ClusterHandler::cluster_signal_and_update(int,
ClusterVConnection*, ClusterVConnState*)+0x33)[0x605b43]
/usr/bin/traffic_server(ClusterHandler::valid_for_data_write(ClusterVConnection*)+0x61e)[0x60316e]
/usr/bin/traffic_server(ClusterHandler::build_write_descriptors()+0xbd)[0x6034cd]
/usr/bin/traffic_server[0x604490]
/usr/bin/traffic_server(ClusterHandler::mainClusterEvent(int,
Event*)+0x1e4)[0x604774]
/usr/bin/traffic_server(ClusterState::IOComplete()+0xc2)[0x60b472]
/usr/bin/traffic_server(ClusterState::doIO_write_event(int,
void*)+0x109)[0x60b7e9]
/usr/bin/traffic_server[0x66f321]
/usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x847)[0x671b57]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x286)[0x66a086]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2b8d852e2851]
/lib64/libc.so.6(clone+0x6d)[0x2b8d8797490d]
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b12fb535500]
/usr/bin/traffic_server(UnixNetVConnection::do_io_write(Continuation*, long,
IOBufferReader*, bool)+0x18)[0x6708b8]
/usr/bin/traffic_server(HttpSessionManager::release_session(HttpServerSession*)+0x7d)[0x515b2d]
/usr/bin/traffic_server(HttpSM::tunnel_handler_server(int,
HttpTunnelProducer*)+0x2ff)[0x523faf]
/usr/bin/traffic_server(HttpTunnel::producer_handler(int,
HttpTunnelProducer*)+0x196)[0x565ba6]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x666)[0x5666c6]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x56694d]
/usr/bin/traffic_server(ClusterHandler::cluster_signal_and_update(int,
ClusterVConnection*, ClusterVConnState*)+0x33)[0x605b43]
/usr/bin/traffic_server(ClusterHandler::valid_for_data_write(ClusterVConnection*)+0x61e)[0x60316e]
/usr/bin/traffic_server(ClusterHandler::build_write_descriptors()+0xbd)[0x6034cd]
/usr/bin/traffic_server[0x604490]
/usr/bin/traffic_server(ClusterHandler::mainClusterEvent(int,
Event*)+0x1e4)[0x604774]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
[jira] [Updated] (TS-1799) Segmentation fault (git master) at cluster
[
https://issues.apache.org/jira/browse/TS-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1799:
Labels: crash (was: )
Segmentation fault (git master) at cluster
---
Key: TS-1799
URL: https://issues.apache.org/jira/browse/TS-1799
Project: Traffic Server
Issue Type: Bug
Components: Clustering
Affects Versions: 3.3.2
Reporter: bettydramit
Labels: crash
{code}
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b20d9026500]
/usr/bin/traffic_server(UnixNetVConnection::do_io_write(Continuation*, long,
IOBufferReader*, bool)+0x18)[0x6708b8]
/usr/bin/traffic_server(HttpSessionManager::release_session(HttpServerSession*)+0x7d)[0x515b2d]
/usr/bin/traffic_server(HttpSM::tunnel_handler_server(int,
HttpTunnelProducer*)+0x2ff)[0x523faf]
/usr/bin/traffic_server(HttpTunnel::producer_handler(int,
HttpTunnelProducer*)+0x196)[0x565ba6]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x666)[0x5666c6]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x56694d]
/usr/bin/traffic_server(ClusterHandler::cluster_signal_and_update(int,
ClusterVConnection*, ClusterVConnState*)+0x33)[0x605b43]
/usr/bin/traffic_server(ClusterHandler::valid_for_data_write(ClusterVConnection*)+0x61e)[0x60316e]
/usr/bin/traffic_server(ClusterHandler::build_write_descriptors()+0xbd)[0x6034cd]
/usr/bin/traffic_server[0x604490]
/usr/bin/traffic_server(ClusterHandler::mainClusterEvent(int,
Event*)+0x1e4)[0x604774]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2b20d901e851]
/lib64/libc.so.6(clone+0x6d)[0x2b20db6b090d]
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b8d852ea500]
/usr/bin/traffic_server(UnixNetVConnection::do_io_write(Continuation*, long,
IOBufferReader*, bool)+0x18)[0x6708b8]
/usr/bin/traffic_server(HttpSessionManager::release_session(HttpServerSession*)+0x7d)[0x515b2d]
/usr/bin/traffic_server(HttpSM::tunnel_handler_server(int,
HttpTunnelProducer*)+0x2ff)[0x523faf]
/usr/bin/traffic_server(HttpTunnel::producer_handler(int,
HttpTunnelProducer*)+0x196)[0x565ba6]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x666)[0x5666c6]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x56694d]
/usr/bin/traffic_server(ClusterHandler::cluster_signal_and_update(int,
ClusterVConnection*, ClusterVConnState*)+0x33)[0x605b43]
/usr/bin/traffic_server(ClusterHandler::valid_for_data_write(ClusterVConnection*)+0x61e)[0x60316e]
/usr/bin/traffic_server(ClusterHandler::build_write_descriptors()+0xbd)[0x6034cd]
/usr/bin/traffic_server[0x604490]
/usr/bin/traffic_server(ClusterHandler::mainClusterEvent(int,
Event*)+0x1e4)[0x604774]
/usr/bin/traffic_server(ClusterState::IOComplete()+0xc2)[0x60b472]
/usr/bin/traffic_server(ClusterState::doIO_write_event(int,
void*)+0x109)[0x60b7e9]
/usr/bin/traffic_server[0x66f321]
/usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x847)[0x671b57]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x286)[0x66a086]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2b8d852e2851]
/lib64/libc.so.6(clone+0x6d)[0x2b8d8797490d]
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b12fb535500]
/usr/bin/traffic_server(UnixNetVConnection::do_io_write(Continuation*, long,
IOBufferReader*, bool)+0x18)[0x6708b8]
/usr/bin/traffic_server(HttpSessionManager::release_session(HttpServerSession*)+0x7d)[0x515b2d]
/usr/bin/traffic_server(HttpSM::tunnel_handler_server(int,
HttpTunnelProducer*)+0x2ff)[0x523faf]
/usr/bin/traffic_server(HttpTunnel::producer_handler(int,
HttpTunnelProducer*)+0x196)[0x565ba6]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x666)[0x5666c6]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x56694d]
/usr/bin/traffic_server(ClusterHandler::cluster_signal_and_update(int,
ClusterVConnection*,
[jira] [Commented] (TS-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler().
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620558#comment-13620558 ] ASF subversion and git services commented on TS-1797: - Commit 25adb5cf4833a08de59f773095f4321920ecbaee in branch refs/heads/master from [~kuotai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=25adb5c ] TS-1797 improve ClusterMachine::pop_ClusterHandler() when ts starting when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler(). -- Key: TS-1797 URL: https://issues.apache.org/jira/browse/TS-1797 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: TS-1797.patch when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Maybe one clusterHandler have created(connection is establish) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler().
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1797. Resolution: Fixed when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler(). -- Key: TS-1797 URL: https://issues.apache.org/jira/browse/TS-1797 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: TS-1797.patch when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Maybe one clusterHandler have created(connection is establish) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
