[jira] [Updated] (TS-1142) we need to record ram hit in ram cache hit
[ https://issues.apache.org/jira/browse/TS-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-1142: Comment: was deleted (was: you can add CONFIG proxy.config.http.record_tcp_mem_hit INT 1 in reccords.config) we need to record ram hit in ram cache hit -- Key: TS-1142 URL: https://issues.apache.org/jira/browse/TS-1142 Project: Traffic Server Issue Type: Improvement Components: Cache, Stats Affects Versions: 3.1.4 Reporter: Zhao Yongming Assignee: kuotai we need to record the ram mem hites in stats -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1142) we need to record ram hit in ram cache hit
[ https://issues.apache.org/jira/browse/TS-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231900#comment-13231900 ] bettydramit commented on TS-1142: - you can add CONFIG proxy.config.http.record_tcp_mem_hit INT 1 in reccords.config we need to record ram hit in ram cache hit -- Key: TS-1142 URL: https://issues.apache.org/jira/browse/TS-1142 Project: Traffic Server Issue Type: Improvement Components: Cache, Stats Affects Versions: 3.1.4 Reporter: Zhao Yongming Assignee: kuotai we need to record the ram mem hites in stats -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1142) we need to record ram hit in ram cache hit
[ https://issues.apache.org/jira/browse/TS-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231949#comment-13231949 ] kuotai commented on TS-1142: this config only record in Via header. But we can`t get info stats by command links -dump http://localhost:8080/stat/; we need to record ram hit in ram cache hit -- Key: TS-1142 URL: https://issues.apache.org/jira/browse/TS-1142 Project: Traffic Server Issue Type: Improvement Components: Cache, Stats Affects Versions: 3.1.4 Reporter: Zhao Yongming Assignee: kuotai we need to record the ram mem hites in stats -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-1140) Implement HTTP method filtering in ip_allow.config
[ https://issues.apache.org/jira/browse/TS-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230901#comment-13230901 ] Igor Brezac edited comment on TS-1140 at 3/17/12 4:24 PM: -- Fixed a few more issues based on Igor's comments. was (Author: ibrezac): Fixed a few more issue based on Igor's comments. Implement HTTP method filtering in ip_allow.config -- Key: TS-1140 URL: https://issues.apache.org/jira/browse/TS-1140 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 3.1.3, 3.1.2 Reporter: Igor Brezac Priority: Critical Fix For: 3.1.3 Attachments: ts-1140-v2.diff, ts-1140.diff, ts.patch Implement HTTP method filtering in ip_allow.config (and deprecate proxy.config.http.quick_filter.mask) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1127) Wrong returned value of incoming port address
[ https://issues.apache.org/jira/browse/TS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1127: -- Fix Version/s: (was: 3.1.3) 3.1.4 Wrong returned value of incoming port address - Key: TS-1127 URL: https://issues.apache.org/jira/browse/TS-1127 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.1.2 Reporter: Yakov Kopel Assignee: Alan M. Carroll Fix For: 3.1.4 Attachments: fix.patch Original Estimate: 1m Remaining Estimate: 1m The API TSHttpTxnClientIncomingPortGet has been changed in Wed Oct 5 19:14:07 2011 (TS-926) and it returns another value. in the old version it returned the incoming port of the TS(the port which the client connected to the TS). in the new version the returned value is the sending port of the user. The different is in the line: - return sm-t_state.client_info.port; + return ink_inet_get_port(sm-t_state.client_info.addr); The assignment of those two members (port, addr) are in the HttpSM.cc file ink_inet_copy(t_state.client_info.addr, netvc-get_remote_addr()); t_state.client_info.port = netvc-get_local_port(); The old code gave the right answer from the port member, and the new one gives us wrong answer from the remote address. I attached a patch to fix this returned value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1114) Crash report: HttpTransactCache::SelectFromAlternates
[
https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1114:
--
Fix Version/s: (was: 3.1.3)
3.1.4
Crash report: HttpTransactCache::SelectFromAlternates
-
Key: TS-1114
URL: https://issues.apache.org/jira/browse/TS-1114
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.4
Attachments: cache_crash.diff
it may or may not be the upstream issue, let us open it for tracking.
{code}
#0 0x0053075e in HttpTransactCache::SelectFromAlternates
(cache_vector=0x2aaab80ff500, client_request=0x2aaab80ff4c0,
http_config_params=0x2aaab547b800) at ../../proxy/hdrs/HTTP.h:1375
1375((int32_t *) val)[0] = m_alt-m_object_key[0];
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1130) ink_time_t is 64bit on x86_64
[ https://issues.apache.org/jira/browse/TS-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1130: -- Fix Version/s: (was: 3.1.3) 3.1.4 ink_time_t is 64bit on x86_64 - Key: TS-1130 URL: https://issues.apache.org/jira/browse/TS-1130 Project: Traffic Server Issue Type: Sub-task Components: Core Reporter: Zhao Yongming Assignee: weijin Fix For: 3.1.4 Weijin: paste your patch here, :D -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1143) IpMap::fill fails to handle some edge cases.
[ https://issues.apache.org/jira/browse/TS-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1143: -- Fix Version/s: (was: 3.1.3) 3.1.4 IpMap::fill fails to handle some edge cases. Key: TS-1143 URL: https://issues.apache.org/jira/browse/TS-1143 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.2 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: 3.1.4 Three related issues: 1) Input ranges with a min value of zero can be mishandled due to wrap. 2) Input ranges with a maximum value can be mishandled due to wrap. 3) Fill sometimes fails to insert ranges between two existing ranges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1075) Port range bottleneck in transparent proxy mode
[ https://issues.apache.org/jira/browse/TS-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1075: -- Fix Version/s: (was: 3.1.3) 3.1.4 Port range bottleneck in transparent proxy mode --- Key: TS-1075 URL: https://issues.apache.org/jira/browse/TS-1075 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Environment: Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support ATS compiled as: ./configure --enable-tproxy Reporter: Danny Shporer Assignee: B Wyatt Fix For: 3.1.4 Attachments: ports.patch The Linux TPROXY stack only takes into account the local addresses when using dynamic bind (bind without specifying a specific port). This limits the port range to only the local range (around 30K by default and can be extended to around 64K) - this together with the TIME-WAIT Linux method of releasing ports causes a bottleneck). One symptom of this is that traffic_cop cannot open a connection to the server to monitor it (it gets error 99 - address already in use) and kills it. Another issue is when opening the connection to the server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1140) Implement HTTP method filtering in ip_allow.config
[ https://issues.apache.org/jira/browse/TS-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1140: -- Fix Version/s: (was: 3.1.3) 3.1.4 Implement HTTP method filtering in ip_allow.config -- Key: TS-1140 URL: https://issues.apache.org/jira/browse/TS-1140 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 3.1.3, 3.1.2 Reporter: Igor Brezac Priority: Critical Fix For: 3.1.4 Attachments: ts-1140-v2.diff, ts-1140.diff, ts.patch Implement HTTP method filtering in ip_allow.config (and deprecate proxy.config.http.quick_filter.mask) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1146) RFC 5077 TLS Session tickets
RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232150#comment-13232150 ] Leif Hedstrom commented on TS-1146: --- https://github.com/apache/httpd/commit/967d943b93498233f0ec81a5b48706fdb6892dfd RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232154#comment-13232154 ] James Peach commented on TS-1146: - Also: https://github.com/apache/httpd/commit/414911a5da0910b23aa00872874cf64b6b8a7b6b RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1147) deprecate records.config SSL configuration
deprecate records.config SSL configuration -- Key: TS-1147 URL: https://issues.apache.org/jira/browse/TS-1147 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Priority: Minor Since ssl_multicert.config is a strict superset of the SSL certificate configuration in records.config, we should deprecate configuring SSL certificates in records.config and make ssl_multicert.config the One True Way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1114) Crash report: HttpTransactCache::SelectFromAlternates
[
https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232157#comment-13232157
]
John Plevyak commented on TS-1114:
--
Gads, yes, the write_vector needs to be protected by the vol mutex. This is a
serious oversight. Thanx for finding it.
This patch has to get in. Do you want to commit it or do you want me to do a
closer read then commit it?
Crash report: HttpTransactCache::SelectFromAlternates
-
Key: TS-1114
URL: https://issues.apache.org/jira/browse/TS-1114
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.4
Attachments: cache_crash.diff
it may or may not be the upstream issue, let us open it for tracking.
{code}
#0 0x0053075e in HttpTransactCache::SelectFromAlternates
(cache_vector=0x2aaab80ff500, client_request=0x2aaab80ff4c0,
http_config_params=0x2aaab547b800) at ../../proxy/hdrs/HTTP.h:1375
1375((int32_t *) val)[0] = m_alt-m_object_key[0];
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-857) Crash Report: HttpTunnel::chain_abort_all - HttpServerSession::do_io_close - UnixNetVConnection::do_io_close
[
https://issues.apache.org/jira/browse/TS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232159#comment-13232159
]
John Plevyak commented on TS-857:
-
Could the non-locked access be coming from the InactivityCop? See attached
lock patch which handles a race in that code.
Crash Report: HttpTunnel::chain_abort_all - HttpServerSession::do_io_close
- UnixNetVConnection::do_io_close
--
Key: TS-857
URL: https://issues.apache.org/jira/browse/TS-857
Project: Traffic Server
Issue Type: Bug
Components: HTTP, Network
Affects Versions: 3.1.0
Environment: in my branch that is something same as 3.0.x
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.5
Attachments: ts-857.diff, ts-857.diff, ts-857.diff
here is the bt from the crash, some of the information is missing due to we
have not enable the --enable-debug configure options.
{code}
[New process 7532]
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out)
at ink_stack_trace.cc:68
68fp = (void **) (*fp);
(gdb) bt
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out)
at ink_stack_trace.cc:68
#1 0x2ba641dccef1 in ink_stack_trace_dump (sighandler_frame=value
optimized out) at ink_stack_trace.cc:114
#2 0x004df020 in signal_handler (sig=value optimized out) at
signals.cc:225
#3 signal handler called
#4 0x006a1ea9 in UnixNetVConnection::do_io_close (this=0x1cc9bd20,
alerrno=value optimized out)
at ../../iocore/eventsystem/I_Lock.h:297
#5 0x0051f1d0 in HttpServerSession::do_io_close
(this=0x2aaab0042c80, alerrno=20600) at HttpServerSession.cc:127
#6 0x0056d1e9 in HttpTunnel::chain_abort_all (this=0x2aabeeffdd70,
p=0x2aabeeffdf68) at HttpTunnel.cc:1300
#7 0x005269ca in HttpSM::tunnel_handler_ua (this=0x2aabeeffc070,
event=104, c=0x2aabeeffdda8) at HttpSM.cc:2987
#8 0x00571dfc in HttpTunnel::consumer_handler (this=0x2aabeeffdd70,
event=104, c=0x2aabeeffdda8) at HttpTunnel.cc:1232
#9 0x00572032 in HttpTunnel::main_handler (this=0x2aabeeffdd70,
event=1088608784, data=value optimized out)
at HttpTunnel.cc:1456
#10 0x006a6307 in write_to_net_io (nh=0x2b12d688, vc=0x1cc876e0,
thread=value optimized out)
at ../../iocore/eventsystem/I_Continuation.h:146
#11 0x0069ce97 in NetHandler::mainNetEvent (this=0x2b12d688,
event=value optimized out, e=0x171c1ed0) at UnixNet.cc:405
#12 0x006cddaf in EThread::process_event (this=0x2b12c010,
e=0x171c1ed0, calling_code=5) at I_Continuation.h:146
#13 0x006ce6bc in EThread::execute (this=0x2b12c010) at
UnixEThread.cc:262
#14 0x006cd0ee in spawn_thread_internal (a=0x171b58f0) at Thread.cc:88
#15 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
#16 0x003c330d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x40e2b790:
rip = 0x2ba641dccdf3 in ink_stack_trace_get(void**, int, int)
(ink_stack_trace.cc:68); saved rip 0x2ba641dccef1
called by frame at 0x40e2bbe0
source language c++.
Arglist at 0x40e2b770, args: stack=value optimized out, len=value
optimized out, signalhandler_frame=value optimized out
Locals at 0x40e2b770, Previous frame's sp is 0x40e2b790
Saved registers:
rbx at 0x40e2b778, rbp at 0x40e2b780, rip at 0x40e2b788
(gdb)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-857) Crash Report: HttpTunnel::chain_abort_all - HttpServerSession::do_io_close - UnixNetVConnection::do_io_close
[
https://issues.apache.org/jira/browse/TS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Plevyak updated TS-857:
Attachment: locking-jp1.patch
This fixes a race in inactivity timeouts coming from the InactivityCop
Crash Report: HttpTunnel::chain_abort_all - HttpServerSession::do_io_close
- UnixNetVConnection::do_io_close
--
Key: TS-857
URL: https://issues.apache.org/jira/browse/TS-857
Project: Traffic Server
Issue Type: Bug
Components: HTTP, Network
Affects Versions: 3.1.0
Environment: in my branch that is something same as 3.0.x
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.5
Attachments: locking-jp1.patch, ts-857.diff, ts-857.diff, ts-857.diff
here is the bt from the crash, some of the information is missing due to we
have not enable the --enable-debug configure options.
{code}
[New process 7532]
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out)
at ink_stack_trace.cc:68
68fp = (void **) (*fp);
(gdb) bt
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out)
at ink_stack_trace.cc:68
#1 0x2ba641dccef1 in ink_stack_trace_dump (sighandler_frame=value
optimized out) at ink_stack_trace.cc:114
#2 0x004df020 in signal_handler (sig=value optimized out) at
signals.cc:225
#3 signal handler called
#4 0x006a1ea9 in UnixNetVConnection::do_io_close (this=0x1cc9bd20,
alerrno=value optimized out)
at ../../iocore/eventsystem/I_Lock.h:297
#5 0x0051f1d0 in HttpServerSession::do_io_close
(this=0x2aaab0042c80, alerrno=20600) at HttpServerSession.cc:127
#6 0x0056d1e9 in HttpTunnel::chain_abort_all (this=0x2aabeeffdd70,
p=0x2aabeeffdf68) at HttpTunnel.cc:1300
#7 0x005269ca in HttpSM::tunnel_handler_ua (this=0x2aabeeffc070,
event=104, c=0x2aabeeffdda8) at HttpSM.cc:2987
#8 0x00571dfc in HttpTunnel::consumer_handler (this=0x2aabeeffdd70,
event=104, c=0x2aabeeffdda8) at HttpTunnel.cc:1232
#9 0x00572032 in HttpTunnel::main_handler (this=0x2aabeeffdd70,
event=1088608784, data=value optimized out)
at HttpTunnel.cc:1456
#10 0x006a6307 in write_to_net_io (nh=0x2b12d688, vc=0x1cc876e0,
thread=value optimized out)
at ../../iocore/eventsystem/I_Continuation.h:146
#11 0x0069ce97 in NetHandler::mainNetEvent (this=0x2b12d688,
event=value optimized out, e=0x171c1ed0) at UnixNet.cc:405
#12 0x006cddaf in EThread::process_event (this=0x2b12c010,
e=0x171c1ed0, calling_code=5) at I_Continuation.h:146
#13 0x006ce6bc in EThread::execute (this=0x2b12c010) at
UnixEThread.cc:262
#14 0x006cd0ee in spawn_thread_internal (a=0x171b58f0) at Thread.cc:88
#15 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
#16 0x003c330d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x40e2b790:
rip = 0x2ba641dccdf3 in ink_stack_trace_get(void**, int, int)
(ink_stack_trace.cc:68); saved rip 0x2ba641dccef1
called by frame at 0x40e2bbe0
source language c++.
Arglist at 0x40e2b770, args: stack=value optimized out, len=value
optimized out, signalhandler_frame=value optimized out
Locals at 0x40e2b770, Previous frame's sp is 0x40e2b790
Saved registers:
rbx at 0x40e2b778, rbp at 0x40e2b780, rip at 0x40e2b788
(gdb)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1114) Crash report: HttpTransactCache::SelectFromAlternates
[
https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232164#comment-13232164
]
Zhao Yongming commented on TS-1114:
---
yeah, we are confidential that we have fixed the crash, and we need your
review, that is what we are waiting for :D
Crash report: HttpTransactCache::SelectFromAlternates
-
Key: TS-1114
URL: https://issues.apache.org/jira/browse/TS-1114
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.4
Attachments: cache_crash.diff
it may or may not be the upstream issue, let us open it for tracking.
{code}
#0 0x0053075e in HttpTransactCache::SelectFromAlternates
(cache_vector=0x2aaab80ff500, client_request=0x2aaab80ff4c0,
http_config_params=0x2aaab547b800) at ../../proxy/hdrs/HTTP.h:1375
1375((int32_t *) val)[0] = m_alt-m_object_key[0];
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
