[jira] [Updated] (TS-3841) LogAccess.cc assert failed when enabling custom log and stats_over_http plugin
[
https://issues.apache.org/jira/browse/TS-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3841:
---
Fix Version/s: (was: 6.1.0)
6.2.0
> LogAccess.cc assert failed when enabling custom log and stats_over_http plugin
> --
>
> Key: TS-3841
> URL: https://issues.apache.org/jira/browse/TS-3841
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: taoyunxing
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> when I enable both the custom log and stats_over_http plugin, I encounter the
> following problem:
> {code}
> FATAL: LogAccess.cc:816: failed assert `actual_len < padded_len`
> Program received signal SIGABRT, Aborted.
> (gdb) bt
> #0 0x003d150328a5 in raise () from /lib64/libc.so.6
> #1 0x003d15034085 in abort () from /lib64/libc.so.6
> #2 0x77dd8751 in ink_die_die_die () at ink_error.cc:43
> #3 0x77dd8808 in ink_fatal_va(const char *, typedef __va_list_tag
> __va_list_tag *) (fmt=0x77dea738 "%s:%d: failed assert `%s`",
> ap=0x75e1f430) at ink_error.cc:65
> #4 0x77dd88cd in ink_fatal (message_format=0x77dea738 "%s:%d:
> failed assert `%s`") at ink_error.cc:73
> #5 0x77dd6272 in _ink_assert (expression=0x7e653b "actual_len <
> padded_len", file=0x7e64c7 "LogAccess.cc", line=816) at ink_assert.cc:37
> #6 0x0066a2e2 in LogAccess::marshal_mem (dest=0x7fffec004358 "",
> source=0x7e6539 "-", actual_len=1, padded_len=0) at LogAccess.cc:816
> #7 0x0066d455 in LogAccessHttp::marshal_client_req_unmapped_url_host
> (this=0x75e1f7d0, buf=0x7fffec004358 "") at LogAccessHttp.cc:472
> #8 0x0067b441 in LogField::marshal (this=0x1110e80,
> lad=0x75e1f7d0, buf=0x7fffec004358 "") at LogField.cc:276
> #9 0x0067bf5b in LogFieldList::marshal (this=0x110d5b0,
> lad=0x75e1f7d0, buf=0x7fffec004318 "") at LogField.cc:574
> #10 0x0068b408 in LogObject::log (this=0x110d4e0, lad=0x75e1f7d0,
> text_entry=0x0) at LogObject.cc:623
> #11 0x0068da22 in LogObjectManager::log (this=0x1116da8,
> lad=0x75e1f7d0) at LogObject.cc:1331
> #12 0x00666d0e in Log::access (lad=0x75e1f7d0) at Log.cc:927
> #13 0x005f630d in HttpSM::kill_this (this=0x70ef1aa0) at
> HttpSM.cc:6571
> #14 0x005e7184 in HttpSM::main_handler (this=0x70ef1aa0,
> event=2301, data=0x70ef2ef8) at HttpSM.cc:2567
> #15 0x00506166 in Continuation::handleEvent (this=0x70ef1aa0,
> event=2301, data=0x70ef2ef8) at ../iocore/eventsystem/I_Continuation.h:145
> #16 0x00635ad9 in HttpTunnel::main_handler (this=0x70ef2ef8,
> event=103, data=0x718b2110) at HttpTunnel.cc:1585
> #17 0x00506166 in Continuation::handleEvent (this=0x70ef2ef8,
> event=103, data=0x718b2110) at ../iocore/eventsystem/I_Continuation.h:145
> #18 0x00778bdb in write_signal_and_update (event=103,
> vc=0x718b1f80) at UnixNetVConnection.cc:170
> #19 0x00778df3 in write_signal_done (event=103, nh=0x7622a780,
> vc=0x718b1f80) at UnixNetVConnection.cc:212
> #20 0x00779f92 in write_to_net_io (nh=0x7622a780,
> vc=0x718b1f80, thread=0x76227010) at UnixNetVConnection.cc:530
> #21 0x007796e9 in write_to_net (nh=0x7622a780, vc=0x718b1f80,
> thread=0x76227010) at UnixNetVConnection.cc:384
> #22 0x0077245a in NetHandler::mainNetEvent (this=0x7622a780,
> event=5, e=0x75a1eb40) at UnixNet.cc:562
> #23 0x00506166 in Continuation::handleEvent (this=0x7622a780,
> event=5, data=0x75a1eb40) at ../iocore/eventsystem/I_Continuation.h:145
> #24 0x0079aa26 in EThread::process_event (this=0x76227010,
> e=0x75a1eb40, calling_code=5) at UnixEThread.cc:128
> #25 0x0079b047 in EThread::execute (this=0x76227010) at
> UnixEThread.cc:252
> #26 0x00799f2c in spawn_thread_internal (a=0x1106a40) at Thread.cc:85
> #27 0x003d15407851 in start_thread () from /lib64/libpthread.so.0
> #28 0x003d150e767d in clone () from /lib64/libc.so.6
> (gdb)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4124) Cleanup code around proxy.config.net.inactive_threashold_in
[ https://issues.apache.org/jira/browse/TS-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-4124: -- Assignee: Bryan Call > Cleanup code around proxy.config.net.inactive_threashold_in > --- > > Key: TS-4124 > URL: https://issues.apache.org/jira/browse/TS-4124 > Project: Traffic Server > Issue Type: Bug > Components: Configuration, Network >Reporter: Leif Hedstrom >Assignee: Bryan Call > Fix For: 6.2.0 > > > This is a (currently) unused configuration, so for code clarity, we should > clean this up. [~bcall] suggests either commenting it out for now, or just > remove. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4124) Cleanup code around proxy.config.net.inactive_threashold_in
Leif Hedstrom created TS-4124: - Summary: Cleanup code around proxy.config.net.inactive_threashold_in Key: TS-4124 URL: https://issues.apache.org/jira/browse/TS-4124 Project: Traffic Server Issue Type: Bug Components: Configuration, Network Reporter: Leif Hedstrom This is a (currently) unused configuration, so for code clarity, we should clean this up. [~bcall] suggests either commenting it out for now, or just remove. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4124) Cleanup code around proxy.config.net.inactive_threashold_in
[ https://issues.apache.org/jira/browse/TS-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-4124: -- Fix Version/s: 6.2.0 > Cleanup code around proxy.config.net.inactive_threashold_in > --- > > Key: TS-4124 > URL: https://issues.apache.org/jira/browse/TS-4124 > Project: Traffic Server > Issue Type: Bug > Components: Configuration, Network >Reporter: Leif Hedstrom > Fix For: 6.2.0 > > > This is a (currently) unused configuration, so for code clarity, we should > clean this up. [~bcall] suggests either commenting it out for now, or just > remove. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3841) LogAccess.cc assert failed when enabling custom log and stats_over_http plugin
[
https://issues.apache.org/jira/browse/TS-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15093093#comment-15093093
]
ASF subversion and git services commented on TS-3841:
-
Commit 9399a76410de027092b20e0a287f315fca20257d in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9399a76 ]
TS-3841: LogAccess.cc assert failed when enabling custom log and
stats_over_http plugin
> LogAccess.cc assert failed when enabling custom log and stats_over_http plugin
> --
>
> Key: TS-3841
> URL: https://issues.apache.org/jira/browse/TS-3841
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: taoyunxing
>Assignee: Bryan Call
> Fix For: 6.1.0
>
>
> when I enable both the custom log and stats_over_http plugin, I encounter the
> following problem:
> {code}
> FATAL: LogAccess.cc:816: failed assert `actual_len < padded_len`
> Program received signal SIGABRT, Aborted.
> (gdb) bt
> #0 0x003d150328a5 in raise () from /lib64/libc.so.6
> #1 0x003d15034085 in abort () from /lib64/libc.so.6
> #2 0x77dd8751 in ink_die_die_die () at ink_error.cc:43
> #3 0x77dd8808 in ink_fatal_va(const char *, typedef __va_list_tag
> __va_list_tag *) (fmt=0x77dea738 "%s:%d: failed assert `%s`",
> ap=0x75e1f430) at ink_error.cc:65
> #4 0x77dd88cd in ink_fatal (message_format=0x77dea738 "%s:%d:
> failed assert `%s`") at ink_error.cc:73
> #5 0x77dd6272 in _ink_assert (expression=0x7e653b "actual_len <
> padded_len", file=0x7e64c7 "LogAccess.cc", line=816) at ink_assert.cc:37
> #6 0x0066a2e2 in LogAccess::marshal_mem (dest=0x7fffec004358 "",
> source=0x7e6539 "-", actual_len=1, padded_len=0) at LogAccess.cc:816
> #7 0x0066d455 in LogAccessHttp::marshal_client_req_unmapped_url_host
> (this=0x75e1f7d0, buf=0x7fffec004358 "") at LogAccessHttp.cc:472
> #8 0x0067b441 in LogField::marshal (this=0x1110e80,
> lad=0x75e1f7d0, buf=0x7fffec004358 "") at LogField.cc:276
> #9 0x0067bf5b in LogFieldList::marshal (this=0x110d5b0,
> lad=0x75e1f7d0, buf=0x7fffec004318 "") at LogField.cc:574
> #10 0x0068b408 in LogObject::log (this=0x110d4e0, lad=0x75e1f7d0,
> text_entry=0x0) at LogObject.cc:623
> #11 0x0068da22 in LogObjectManager::log (this=0x1116da8,
> lad=0x75e1f7d0) at LogObject.cc:1331
> #12 0x00666d0e in Log::access (lad=0x75e1f7d0) at Log.cc:927
> #13 0x005f630d in HttpSM::kill_this (this=0x70ef1aa0) at
> HttpSM.cc:6571
> #14 0x005e7184 in HttpSM::main_handler (this=0x70ef1aa0,
> event=2301, data=0x70ef2ef8) at HttpSM.cc:2567
> #15 0x00506166 in Continuation::handleEvent (this=0x70ef1aa0,
> event=2301, data=0x70ef2ef8) at ../iocore/eventsystem/I_Continuation.h:145
> #16 0x00635ad9 in HttpTunnel::main_handler (this=0x70ef2ef8,
> event=103, data=0x718b2110) at HttpTunnel.cc:1585
> #17 0x00506166 in Continuation::handleEvent (this=0x70ef2ef8,
> event=103, data=0x718b2110) at ../iocore/eventsystem/I_Continuation.h:145
> #18 0x00778bdb in write_signal_and_update (event=103,
> vc=0x718b1f80) at UnixNetVConnection.cc:170
> #19 0x00778df3 in write_signal_done (event=103, nh=0x7622a780,
> vc=0x718b1f80) at UnixNetVConnection.cc:212
> #20 0x00779f92 in write_to_net_io (nh=0x7622a780,
> vc=0x718b1f80, thread=0x76227010) at UnixNetVConnection.cc:530
> #21 0x007796e9 in write_to_net (nh=0x7622a780, vc=0x718b1f80,
> thread=0x76227010) at UnixNetVConnection.cc:384
> #22 0x0077245a in NetHandler::mainNetEvent (this=0x7622a780,
> event=5, e=0x75a1eb40) at UnixNet.cc:562
> #23 0x00506166 in Continuation::handleEvent (this=0x7622a780,
> event=5, data=0x75a1eb40) at ../iocore/eventsystem/I_Continuation.h:145
> #24 0x0079aa26 in EThread::process_event (this=0x76227010,
> e=0x75a1eb40, calling_code=5) at UnixEThread.cc:128
> #25 0x0079b047 in EThread::execute (this=0x76227010) at
> UnixEThread.cc:252
> #26 0x00799f2c in spawn_thread_internal (a=0x1106a40) at Thread.cc:85
> #27 0x003d15407851 in start_thread () from /lib64/libpthread.so.0
> #28 0x003d150e767d in clone () from /lib64/libc.so.6
> (gdb)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3981) Segmentation fault in add_to_active_queue()
[
https://issues.apache.org/jira/browse/TS-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3981:
---
Fix Version/s: (was: 6.1.0)
6.2.0
> Segmentation fault in add_to_active_queue()
>
>
> Key: TS-3981
> URL: https://issues.apache.org/jira/browse/TS-3981
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 6.0.0
>Reporter: bettydramit
>Assignee: Bryan Call
> Labels: crash
> Fix For: 6.2.0
>
>
> {code}
> traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2b15be123430]
> /usr/bin/traffic_server(NetHandler::add_to_active_queue(UnixNetVConnection*)+0x51f)[0x77818f]
> /usr/bin/traffic_server(HttpClientSession::start()+0x11d)[0x5a3ced]
> /usr/bin/traffic_server(ProxyClientSession::state_api_callout(int,
> void*)+0x33)[0x4f7c13]
> /usr/bin/traffic_server(HttpClientSession::new_connection(NetVConnection*,
> MIOBuffer*, IOBufferReader*, bool)+0x21a)[0x5a106a]
> /usr/bin/traffic_server(HttpSessionAccept::accept(NetVConnection*,
> MIOBuffer*, IOBufferReader*)+0x211)[0x59af31]
> /usr/bin/traffic_server(ProtocolProbeTrampoline::ioCompletionEvent(int,
> void*)+0xb02)[0x4f72e2]
> /usr/bin/traffic_server[0x786f53]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1fa)[0x774efa]
> /usr/bin/traffic_server(EThread::execute()+0x67b)[0x7beabb]
> /usr/bin/traffic_server[0x7bd8c5]
> /lib64/libpthread.so.0(+0x7555)[0x2b15be11a555]
> /lib64/libc.so.6(clone+0x6d)[0x2b15bf23cb9d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4123) Doc: Fix image URLs in the Security page
[ https://issues.apache.org/jira/browse/TS-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15091605#comment-15091605 ] ASF subversion and git services commented on TS-4123: - Commit 4c65b77759ad0ec3f7ad4b8fdc8ac6b163e6443d in trafficserver's branch refs/heads/master from [~hnakamur] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4c65b77 ] Doc: [TS-4123] Fix image URLs in the Security page This closes #415 > Doc: Fix image URLs in the Security page > > > Key: TS-4123 > URL: https://issues.apache.org/jira/browse/TS-4123 > Project: Traffic Server > Issue Type: Improvement > Components: Docs, Documentation >Reporter: Hiroaki Nakamura > > Fix image URLs in the Security page. > I created a pull request for this issue: > https://github.com/apache/trafficserver/pull/415 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4123) Doc: Fix image URLs in the Security page
[ https://issues.apache.org/jira/browse/TS-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masaori Koshiba updated TS-4123: Fix Version/s: 6.2.0 > Doc: Fix image URLs in the Security page > > > Key: TS-4123 > URL: https://issues.apache.org/jira/browse/TS-4123 > Project: Traffic Server > Issue Type: Improvement > Components: Docs, Documentation >Reporter: Hiroaki Nakamura >Assignee: Masaori Koshiba > Fix For: 6.2.0 > > > Fix image URLs in the Security page. > I created a pull request for this issue: > https://github.com/apache/trafficserver/pull/415 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4123) Doc: Fix image URLs in the Security page
[ https://issues.apache.org/jira/browse/TS-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masaori Koshiba resolved TS-4123. - Resolution: Fixed > Doc: Fix image URLs in the Security page > > > Key: TS-4123 > URL: https://issues.apache.org/jira/browse/TS-4123 > Project: Traffic Server > Issue Type: Improvement > Components: Docs, Documentation >Reporter: Hiroaki Nakamura >Assignee: Masaori Koshiba > Fix For: 6.2.0 > > > Fix image URLs in the Security page. > I created a pull request for this issue: > https://github.com/apache/trafficserver/pull/415 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4123) Doc: Fix image URLs in the Security page
[ https://issues.apache.org/jira/browse/TS-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masaori Koshiba reassigned TS-4123: --- Assignee: Masaori Koshiba > Doc: Fix image URLs in the Security page > > > Key: TS-4123 > URL: https://issues.apache.org/jira/browse/TS-4123 > Project: Traffic Server > Issue Type: Improvement > Components: Docs, Documentation >Reporter: Hiroaki Nakamura >Assignee: Masaori Koshiba > Fix For: 6.2.0 > > > Fix image URLs in the Security page. > I created a pull request for this issue: > https://github.com/apache/trafficserver/pull/415 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4055) Coredump when closing a transaction with a stalled connection to the origin
[
https://issues.apache.org/jira/browse/TS-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092275#comment-15092275
]
Luca Bruno commented on TS-4055:
I'm getting a similar crash with ats 6.0.0, but the stack trace is different.
Note that I'm not using traffic_cop, but directly traffic_manager:
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
> Coredump when closing a transaction with a stalled connection to the origin
> -
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
> Labels: crash
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> c++filt traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int,
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
> void*)+0x142)[0x5c0dd2]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xc8)[0x5c5e38]
> /usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
> Event*)+0x4ff)[0x78651f]
> /usr/bin/traffic_server(InactivityCop::check_inactivity(int,
> Event*)+0x28d)[0x7789ad]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8a)[0x7bdf5a]
> /usr/bin/traffic_server(EThread::execute()+0xaa5)[0x7bf045]
> /usr/bin/traffic_server[0x7bda25]
> /lib64/libpthread.so.0(+0x7555)[0x2abaac559555]
> /lib64/libc.so.6(clone+0x6d)[0x2abaad67bb9d]
> Dec 05 21:00:12 localhost sendEmail[23289]: Email was sent successfully!
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4055) Coredump when closing a transaction with a stalled connection to the origin
[
https://issues.apache.org/jira/browse/TS-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092275#comment-15092275
]
Luca Bruno edited comment on TS-4055 at 1/11/16 5:00 PM:
-
I'm getting a similar crash with ats 6.0.0, but the stack trace is different.
Note that I'm not using traffic_cop, but directly traffic_manager:
{quote}
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
{quote}
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
was (Author: lethalman):
I'm getting a similar crash with ats 6.0.0, but the stack trace is different.
Note that I'm not using traffic_cop, but directly traffic_manager:
{quote}
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
{/quote}
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
> Coredump when closing a transaction with a stalled connection to the origin
> -
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
> Labels: crash
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> c++filt traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int,
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
> void*)+0x142)[0x5c0dd2]
>
[jira] [Comment Edited] (TS-4055) Coredump when closing a transaction with a stalled connection to the origin
[
https://issues.apache.org/jira/browse/TS-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092275#comment-15092275
]
Luca Bruno edited comment on TS-4055 at 1/11/16 4:59 PM:
-
I'm getting a similar crash with ats 6.0.0, but the stack trace is different.
Note that I'm not using traffic_cop, but directly traffic_manager:
{{
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
}}
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
was (Author: lethalman):
I'm getting a similar crash with ats 6.0.0, but the stack trace is different.
Note that I'm not using traffic_cop, but directly traffic_manager:
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
> Coredump when closing a transaction with a stalled connection to the origin
> -
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
> Labels: crash
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> c++filt traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int,
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
> void*)+0x142)[0x5c0dd2]
> /usr/bin/traffic_server(HttpSM::main_handler(int,
[jira] [Comment Edited] (TS-4055) Coredump when closing a transaction with a stalled connection to the origin
[
https://issues.apache.org/jira/browse/TS-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092275#comment-15092275
]
Luca Bruno edited comment on TS-4055 at 1/11/16 5:00 PM:
-
I'm getting a similar crash with ats 6.0.0, but the stack trace is different.
Note that I'm not using traffic_cop, but directly traffic_manager:
{quote}
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
{/quote}
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
was (Author: lethalman):
I'm getting a similar crash with ats 6.0.0, but the stack trace is different.
Note that I'm not using traffic_cop, but directly traffic_manager:
{{
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
}}
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
> Coredump when closing a transaction with a stalled connection to the origin
> -
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
> Labels: crash
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> c++filt traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int,
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
> void*)+0x142)[0x5c0dd2]
>
[jira] [Comment Edited] (TS-4055) Coredump when closing a transaction with a stalled connection to the origin
[
https://issues.apache.org/jira/browse/TS-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092275#comment-15092275
]
Luca Bruno edited comment on TS-4055 at 1/11/16 5:02 PM:
-
I'm getting a similar crash with ats 6.0.0 under stress test, but the stack
trace is different. Note that I'm not using traffic_cop, but directly
traffic_manager:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
{noformat}
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
was (Author: lethalman):
I'm getting a similar crash with ats 6.0.0, but the stack trace is different.
Note that I'm not using traffic_cop, but directly traffic_manager:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
{noformat}
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
> Coredump when closing a transaction with a stalled connection to the origin
> -
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
> Labels: crash
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> c++filt traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int,
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
> void*)+0x142)[0x5c0dd2]
>
[jira] [Comment Edited] (TS-4055) Coredump when closing a transaction with a stalled connection to the origin
[
https://issues.apache.org/jira/browse/TS-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092275#comment-15092275
]
Luca Bruno edited comment on TS-4055 at 1/11/16 5:00 PM:
-
I'm getting a similar crash with ats 6.0.0, but the stack trace is different.
Note that I'm not using traffic_cop, but directly traffic_manager:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
{noformat}
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
was (Author: lethalman):
I'm getting a similar crash with ats 6.0.0, but the stack trace is different.
Note that I'm not using traffic_cop, but directly traffic_manager:
{quote}
traffic_server: Segmentation fault (Address not mapped to object [0x8])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa7)[0x2b1869771db7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b186c0538d0]
/usr/bin/traffic_server(_ZN10NetHandler9_close_vcEP18UnixNetVConnectionlRiS2_S2_S2_+0x2a8)[0x2b18699b8e58]
/usr/bin/traffic_server(_ZN10NetHandler19manage_active_queueEv+0xd3)[0x2b18699b9143]
/usr/bin/traffic_server(_ZN10NetHandler19add_to_active_queueEP18UnixNetVConnection+0x2a)[0x2b18699b91fa]
/usr/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x125)[0x2b1869820795]
/usr/bin/traffic_server(_ZN18ProxyClientSession17state_api_calloutEiPv+0x33)[0x2b18697ac1b3]
/usr/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x234)[0x2b186981fd04]
/usr/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x23d)[0x2b186981b3bd]
/usr/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x2da)[0x2b18697abeaa]
/usr/bin/traffic_server(+0x3235d8)[0x2b18699c45d8]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29a)[0x2b18699b7a7a]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x2b18699e7550]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x67e)[0x2b18699e80ee]
/usr/bin/traffic_server(+0x345ff6)[0x2b18699e6ff6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b186c04c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b186d0d404d]
{quote}
Is it the same or should I file a bug? If it's the same issue, which commits
should I apply on top of 6.0.0 to test? Or which commit should I try?
> Coredump when closing a transaction with a stalled connection to the origin
> -
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
> Labels: crash
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> c++filt traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int,
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
> void*)+0x142)[0x5c0dd2]
>
[jira] [Commented] (TS-4114) ASAN based build fails with gcc 5
[ https://issues.apache.org/jira/browse/TS-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092380#comment-15092380 ] Leif Hedstrom commented on TS-4114: --- I'm obviously in favor of 1, but I have never been able to compile LuaJIT with ASAN. > ASAN based build fails with gcc 5 > - > > Key: TS-4114 > URL: https://issues.apache.org/jira/browse/TS-4114 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Jason Kenny >Assignee: Kit Chan > Fix For: 6.2.0 > > > When building with gcc 5.x and asan on, the build will fail with memory leak > issues in lua. > ==1442==ERROR: LeakSanitizer: detected memory leaks > Direct leak of 4112 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c8d in build_code host/buildvm.c:204 > #2 0x407c8d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 1304 byte(s) in 1 object(s) allocated from: > #0 0x47fa51 in calloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47fa51) > #1 0x405666 in build_code host/buildvm.c:177 > #2 0x405666 in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 372 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407cae in build_code host/buildvm.c:206 > #2 0x407cae in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 296 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x40568d in build_code host/buildvm.c:182 > #2 0x40568d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 16 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c58 in sym_decorate host/buildvm.c:122 > #2 0x407c58 in build_code host/buildvm.c:203 > #3 0x407c58 in main host/buildvm.c:446 > #4 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 14758 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407bbc in build_code host/buildvm.c:199 > #2 0x407bbc in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 2425 byte(s) in 156 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407ed5 in build_code host/buildvm.c:230 > #4 0x407ed5 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1082 byte(s) in 93 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407e72 in build_code host/buildvm.c:217 > #4 0x407e72 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 525 byte(s) in 37 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b4722 in sym_decorate host/buildvm.c:122 > #2 0x4b4722 in collect_reloc host/buildvm.c:140 > #3 0x4b4722 in dasm_encode ../dynasm/dasm_x86.h:425 > #4 0x407bce in build_code host/buildvm.c:200 > #5 0x407bce in main host/buildvm.c:446 > #6 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407fc9 in build_code host/buildvm.c:235 > #4 0x407fc9 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > SUMMARY: AddressSanitizer: 24891 byte(s) leaked in 293 allocation(s). > make[5]: *** [lj_ffdef.h] Error 23 -- This message was
[jira] [Commented] (TS-4114) ASAN based build fails with gcc 5
[ https://issues.apache.org/jira/browse/TS-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092453#comment-15092453 ] Jason Kenny commented on TS-4114: - so the command I had to build ats with dts v3 was: ./configure CC=/opt/rh/devtoolset-3/root/usr/bin/gcc\ CXX=/opt/rh/devtoolset-3/root/usr/bin/g++\ CXXFLAGS="-fno-omit-frame-pointer -fsanitize=address -pthread -static-libasan"\ CFLAGS="-fno-omit-frame-pointer -fsanitize=address -pthread -static-libasan"\ --disable-freelist\ CURSES_LIB="-ltermcap -lcursesw"\ LUA_LDFLAGS="-fno-omit-frame-pointer -fsanitize=address -pthread -static-libasan" ... This older version of asan with rhel6 or rhel7 works fine. anything newer fails. > ASAN based build fails with gcc 5 > - > > Key: TS-4114 > URL: https://issues.apache.org/jira/browse/TS-4114 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Jason Kenny >Assignee: Kit Chan > Fix For: 6.2.0 > > > When building with gcc 5.x and asan on, the build will fail with memory leak > issues in lua. > ==1442==ERROR: LeakSanitizer: detected memory leaks > Direct leak of 4112 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c8d in build_code host/buildvm.c:204 > #2 0x407c8d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 1304 byte(s) in 1 object(s) allocated from: > #0 0x47fa51 in calloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47fa51) > #1 0x405666 in build_code host/buildvm.c:177 > #2 0x405666 in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 372 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407cae in build_code host/buildvm.c:206 > #2 0x407cae in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 296 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x40568d in build_code host/buildvm.c:182 > #2 0x40568d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 16 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c58 in sym_decorate host/buildvm.c:122 > #2 0x407c58 in build_code host/buildvm.c:203 > #3 0x407c58 in main host/buildvm.c:446 > #4 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 14758 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407bbc in build_code host/buildvm.c:199 > #2 0x407bbc in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 2425 byte(s) in 156 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407ed5 in build_code host/buildvm.c:230 > #4 0x407ed5 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1082 byte(s) in 93 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407e72 in build_code host/buildvm.c:217 > #4 0x407e72 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 525 byte(s) in 37 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b4722 in sym_decorate host/buildvm.c:122 > #2 0x4b4722 in collect_reloc host/buildvm.c:140 > #3 0x4b4722 in dasm_encode ../dynasm/dasm_x86.h:425 > #4 0x407bce in build_code host/buildvm.c:200 > #5 0x407bce in main host/buildvm.c:446 > #6 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in
[jira] [Updated] (TS-2427) xdebug: Trigger should be configurable
[
https://issues.apache.org/jira/browse/TS-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2427:
--
Issue Type: Improvement (was: Bug)
> xdebug: Trigger should be configurable
> --
>
> Key: TS-2427
> URL: https://issues.apache.org/jira/browse/TS-2427
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Igor Galić
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
>
> {code}
> // The name of the debug request header. This should probably be configurable.
> #define X_DEBUG_HEADER "X-Debug"
> {code}
> I agree!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3208) clang warnings on || 1
[
https://issues.apache.org/jira/browse/TS-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3208:
--
Fix Version/s: (was: 6.1.0)
> clang warnings on || 1
> --
>
> Key: TS-3208
> URL: https://issues.apache.org/jira/browse/TS-3208
> Project: Traffic Server
> Issue Type: Bug
> Components: Management API
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
>
> {code}
> CoreAPI.cc:368:187: warning: use of logical '||' with constant operand
> [-Wconstant-logical-operand]
> if ((threads).n) for (pid_t *qq__threadid = (pid_t*)0, threadid =
> (threads).v[0]; ((uintptr_t)(qq__threadid) < (threads).length()) &&
> ((threadid = (threads).v[(intptr_t)qq__threadid]) || 1); qq__threadid =
> (pid_t*)(((intptr_t)qq__threadid) + 1)) {
>
>
> ^ ~
> CoreAPI.cc:368:187: note: use '|' for a bitwise operation
> if ((threads).n) for (pid_t *qq__threadid = (pid_t*)0, threadid =
> (threads).v[0]; ((uintptr_t)(qq__threadid) < (threads).length()) &&
> ((threadid = (threads).v[(intptr_t)qq__threadid]) || 1); qq__threadid =
> (pid_t*)(((intptr_t)qq__threadid) + 1)) {
>
>
> ^~
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2118) memcached plugin is in the source tree but does not build
[
https://issues.apache.org/jira/browse/TS-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2118:
--
Component/s: Plugins
> memcached plugin is in the source tree but does not build
> -
>
> Key: TS-2118
> URL: https://issues.apache.org/jira/browse/TS-2118
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Igor Galić
>Assignee: John Rushford
> Labels: newbie
> Fix For: 6.1.0
>
> Attachments: TS-2118.diff
>
>
> The memcached_remap plugin is currently in our experimental plugin tree, but
> doesn't build even with {{--enable-experimental}}.
> This should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2523) Automatically max out the listen backlog
[
https://issues.apache.org/jira/browse/TS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2523:
--
Issue Type: Improvement (was: Bug)
> Automatically max out the listen backlog
>
>
> Key: TS-2523
> URL: https://issues.apache.org/jira/browse/TS-2523
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, Network
>Reporter: James Peach
>Assignee: James Peach
> Labels: incompatible, yahoo
> Fix For: 6.1.0
>
>
> Rather than choosing the right value for {{proxy.config.net.listen_backlog}},
> we should support a -1 default. This would max out the listen backlog on
> systems where we know how to find that, and set it to {{SOMAXCON}} everywhere
> else.
> On Linux, the max backlog is 65535 (unsigned short), and the kernel will clip
> that to {{/proc/sys/net/core/somaxconn}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2523) Automatically max out the listen backlog
[
https://issues.apache.org/jira/browse/TS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2523:
--
Summary: Automatically max out the listen backlog (was: automatically max
out the listen backlog)
> Automatically max out the listen backlog
>
>
> Key: TS-2523
> URL: https://issues.apache.org/jira/browse/TS-2523
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Network
>Reporter: James Peach
>Assignee: James Peach
> Labels: incompatible, yahoo
> Fix For: 6.1.0
>
>
> Rather than choosing the right value for {{proxy.config.net.listen_backlog}},
> we should support a -1 default. This would max out the listen backlog on
> systems where we know how to find that, and set it to {{SOMAXCON}} everywhere
> else.
> On Linux, the max backlog is 65535 (unsigned short), and the kernel will clip
> that to {{/proc/sys/net/core/somaxconn}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2861) traffic_ctl option to find differences from defaults
[ https://issues.apache.org/jira/browse/TS-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2861: -- Issue Type: Improvement (was: Bug) > traffic_ctl option to find differences from defaults > > > Key: TS-2861 > URL: https://issues.apache.org/jira/browse/TS-2861 > Project: Traffic Server > Issue Type: Improvement > Components: Utilities >Reporter: Miles Libbey >Assignee: James Peach > Fix For: 6.1.0 > > > Whenever someone has an issue with ATS getting to run as expected, the first > troubleshooting question is, 'what are your configs?' which frequently relies > on the user remembering what has been changed. It would be nice to have an > easy way to print out the configs that are different than the defaults to > begin troubleshooting. > Yesterday, someone came with a performance issue -- turned out that the user > had forgotten that he had turned on diagnostic logging, slowing the > performance. Took a while to figure out that it was turned on -- which could > have been avoided if it were easy to figure out the non-default > configurations being used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
