[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=13057723#comment-13057723
]
AdunGaos commented on TS-857:
-
code
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out) at ink_stack_trace.cc:68
68 fp = (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 0x2b9a63a34ef1 in ink_stack_trace_dump (sighandler_frame=value
optimized out) at ink_stack_trace.cc:114
#2 0x004ddc10 in signal_handler (sig=value optimized out) at
signals.cc:225
#3 signal handler called
#4 0x006990d9 in UnixNetVConnection::do_io_close (this=0x2aaab0052f00,
alerrno=value optimized out) at ../../iocore/eventsystem/I_Lock.h:297
#5 0x00513f5a in HttpClientSession::do_io_close (this=0x78046f0,
alerrno=-1) at HttpClientSession.cc:310
#6 0x0052588c in HttpSM::tunnel_handler_ua (this=0x2fcd8c40,
event=103, c=0x2fcda968) at HttpSM.cc:3027
#7 0x0056f9dc in HttpTunnel::consumer_handler (this=0x2fcda930,
event=103, c=0x2fcda968) at HttpTunnel.cc:1232
#8 0x0057095e in HttpTunnel::finish_all_internal (this=0x2fcda930,
p=0x2fcdab28, chain=false) at HttpTunnel.cc:1359
#9 0x00526e07 in HttpSM::tunnel_handler_server (this=0x2fcd8c40,
event=104, p=0x2fcdab28) at HttpTunnel.h:311
#10 0x0056eb21 in HttpTunnel::producer_handler (this=0x2fcda930,
event=104, p=0x2fcdab28) at HttpTunnel.cc:1136
#11 0x0056fca0 in HttpTunnel::main_handler (this=0x2fcda930,
event=1106414096, data=value optimized out) at HttpTunnel.cc:1452
#12 0x0069f097 in read_from_net (nh=0x2b22e688, vc=0x2aaab04fef40,
thread=value optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 0x006940e1 in NetHandler::mainNetEvent (this=0x2b22e688,
event=value optimized out, e=0x2b9b601c) at UnixNet.cc:389
#14 0x006c4fdf in EThread::process_event (this=0x2b22d010,
e=0x693bac0, calling_code=5) at I_Continuation.h:146
#15 0x006c58ec in EThread::execute (this=0x2b22d010) at
UnixEThread.cc:262
#16 0x006c431e in spawn_thread_internal (a=0x692f5d0) at Thread.cc:88
#17 0x0031060064a7 in start_thread () from /lib64/libpthread.so.0
#18 0x0031054d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x41f22560:
rip = 0x2b9a63a34df3 in ink_stack_trace_get(void**, int, int)
(ink_stack_trace.cc:68); saved rip 0x2b9a63a34ef1
called by frame at 0x41f229b0
source language c++.
Arglist at 0x41f22540, args: stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out
Locals at 0x41f22540, Previous frame's sp is 0x41f22560
Saved registers:
rbx at 0x41f22548, rbp at 0x41f22550, rip at 0x41f22558
/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
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
[jira] [Issue Comment Edited] (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=13057723#comment-13057723
]
AdunGaos edited comment on TS-857 at 6/30/11 9:47 AM:
--
{code}
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out) at ink_stack_trace.cc:68
68 fp = (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 0x2b9a63a34ef1 in ink_stack_trace_dump (sighandler_frame=value
optimized out) at ink_stack_trace.cc:114
#2 0x004ddc10 in signal_handler (sig=value optimized out) at
signals.cc:225
#3 signal handler called
#4 0x006990d9 in UnixNetVConnection::do_io_close (this=0x2aaab0052f00,
alerrno=value optimized out) at ../../iocore/eventsystem/I_Lock.h:297
#5 0x00513f5a in HttpClientSession::do_io_close (this=0x78046f0,
alerrno=-1) at HttpClientSession.cc:310
#6 0x0052588c in HttpSM::tunnel_handler_ua (this=0x2fcd8c40,
event=103, c=0x2fcda968) at HttpSM.cc:3027
#7 0x0056f9dc in HttpTunnel::consumer_handler (this=0x2fcda930,
event=103, c=0x2fcda968) at HttpTunnel.cc:1232
#8 0x0057095e in HttpTunnel::finish_all_internal (this=0x2fcda930,
p=0x2fcdab28, chain=false) at HttpTunnel.cc:1359
#9 0x00526e07 in HttpSM::tunnel_handler_server (this=0x2fcd8c40,
event=104, p=0x2fcdab28) at HttpTunnel.h:311
#10 0x0056eb21 in HttpTunnel::producer_handler (this=0x2fcda930,
event=104, p=0x2fcdab28) at HttpTunnel.cc:1136
#11 0x0056fca0 in HttpTunnel::main_handler (this=0x2fcda930,
event=1106414096, data=value optimized out) at HttpTunnel.cc:1452
#12 0x0069f097 in read_from_net (nh=0x2b22e688, vc=0x2aaab04fef40,
thread=value optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 0x006940e1 in NetHandler::mainNetEvent (this=0x2b22e688,
event=value optimized out, e=0x2b9b601c) at UnixNet.cc:389
#14 0x006c4fdf in EThread::process_event (this=0x2b22d010,
e=0x693bac0, calling_code=5) at I_Continuation.h:146
#15 0x006c58ec in EThread::execute (this=0x2b22d010) at
UnixEThread.cc:262
#16 0x006c431e in spawn_thread_internal (a=0x692f5d0) at Thread.cc:88
#17 0x0031060064a7 in start_thread () from /lib64/libpthread.so.0
#18 0x0031054d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x41f22560:
rip = 0x2b9a63a34df3 in ink_stack_trace_get(void**, int, int)
(ink_stack_trace.cc:68); saved rip 0x2b9a63a34ef1
called by frame at 0x41f229b0
source language c++.
Arglist at 0x41f22540, args: stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out
Locals at 0x41f22540, Previous frame's sp is 0x41f22560
Saved registers:
rbx at 0x41f22548, rbp at 0x41f22550, rip at 0x41f22558
{code}
was (Author: adungaos):
code
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out) at ink_stack_trace.cc:68
68 fp = (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 0x2b9a63a34ef1 in ink_stack_trace_dump (sighandler_frame=value
optimized out) at ink_stack_trace.cc:114
#2 0x004ddc10 in signal_handler (sig=value optimized out) at
signals.cc:225
#3 signal handler called
#4 0x006990d9 in UnixNetVConnection::do_io_close (this=0x2aaab0052f00,
alerrno=value optimized out) at ../../iocore/eventsystem/I_Lock.h:297
#5 0x00513f5a in HttpClientSession::do_io_close (this=0x78046f0,
alerrno=-1) at HttpClientSession.cc:310
#6 0x0052588c in HttpSM::tunnel_handler_ua (this=0x2fcd8c40,
event=103, c=0x2fcda968) at HttpSM.cc:3027
#7 0x0056f9dc in HttpTunnel::consumer_handler (this=0x2fcda930,
event=103, c=0x2fcda968) at HttpTunnel.cc:1232
#8 0x0057095e in HttpTunnel::finish_all_internal (this=0x2fcda930,
p=0x2fcdab28, chain=false) at HttpTunnel.cc:1359
#9 0x00526e07 in HttpSM::tunnel_handler_server (this=0x2fcd8c40,
event=104, p=0x2fcdab28) at HttpTunnel.h:311
#10 0x0056eb21 in HttpTunnel::producer_handler (this=0x2fcda930,
event=104, p=0x2fcdab28) at HttpTunnel.cc:1136
#11 0x0056fca0 in HttpTunnel::main_handler (this=0x2fcda930,
event=1106414096, data=value optimized out) at HttpTunnel.cc:1452
#12 0x0069f097 in read_from_net (nh=0x2b22e688, vc=0x2aaab04fef40,
thread=value optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 0x006940e1 in NetHandler::mainNetEvent (this=0x2b22e688,
event=value optimized out,
[jira] [Created] (TS-859) ATS requesting to origin instead to the parent server
ATS requesting to origin instead to the parent server - Key: TS-859 URL: https://issues.apache.org/jira/browse/TS-859 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP, Network Environment: CentOS 5.6 Linux 2.6.18-238.12.1.el5 64 bit. gcc 4.1.2-50.el5 Compiled in this machine. Clean installation. Reporter: Francisco Sariego I'm trying to configure parent servers for hierarchical caching in a forward proxy mode, but I am showing strange effects. I have 3 servers: - The ATS 3.0 server (172.16.1.144) - The parents (172.16.1.195, 172.16.1.196) My installation is clean and I've changed only a few parameters. - records.config: CONFIG proxy.config.url_remap.remap_required INT 0 CONFIG proxy.config.http.parent_proxy_routing_enable INT 1 - parent.config dest_domain=. parent=172.16.1.195:8080; 172.16.1.196:8080 round_robin=strict If I request http://www.apache.org from my web browser, I see, using tcpdump port 8080 -nn in the ATS 3.0 machine connections to 140.211.11.131.8080 (www.apache.org) but nothing to the parent servers. Connectivity between the ATS and the parents are confirmed using telnet to the 8080 port, and is responding to HTTP requests. If I disable the parent config, ATS 3.0 works well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-859) ATS requesting to origin instead to the parent server
[ https://issues.apache.org/jira/browse/TS-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Sariego updated TS-859: - Environment: ATS 3.0 CentOS 5.6 Linux 2.6.18-238.12.1.el5 64 bit. gcc 4.1.2-50.el5 Compiled in this machine. Clean installation. was: CentOS 5.6 Linux 2.6.18-238.12.1.el5 64 bit. gcc 4.1.2-50.el5 Compiled in this machine. Clean installation. Affects Version/s: 3.0.0 ATS requesting to origin instead to the parent server - Key: TS-859 URL: https://issues.apache.org/jira/browse/TS-859 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP, Network Affects Versions: 3.0.0 Environment: ATS 3.0 CentOS 5.6 Linux 2.6.18-238.12.1.el5 64 bit. gcc 4.1.2-50.el5 Compiled in this machine. Clean installation. Reporter: Francisco Sariego I'm trying to configure parent servers for hierarchical caching in a forward proxy mode, but I am showing strange effects. I have 3 servers: - The ATS 3.0 server (172.16.1.144) - The parents (172.16.1.195, 172.16.1.196) My installation is clean and I've changed only a few parameters. - records.config: CONFIG proxy.config.url_remap.remap_required INT 0 CONFIG proxy.config.http.parent_proxy_routing_enable INT 1 - parent.config dest_domain=. parent=172.16.1.195:8080; 172.16.1.196:8080 round_robin=strict If I request http://www.apache.org from my web browser, I see, using tcpdump port 8080 -nn in the ATS 3.0 machine connections to 140.211.11.131.8080 (www.apache.org) but nothing to the parent servers. Connectivity between the ATS and the parents are confirmed using telnet to the 8080 port, and is responding to HTTP requests. If I disable the parent config, ATS 3.0 works well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-860) Built in error for host not found looks like Internet Explorer error
Built in error for host not found looks like Internet Explorer error Key: TS-860 URL: https://issues.apache.org/jira/browse/TS-860 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.1.4, 2.1.5, 2.1.6, 2.1.7, 2.1.8, 3.0.0, 2.1.9 Reporter: William Bardwell Attachments: host_not_found.diff There are built in error pages that look like Internet Explorer error pages. These might be copyright Microsoft, but are a bit odd in any case. I think that we should just use the text from the body_factory page instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-860) Built in error for host not found looks like Internet Explorer error
[ https://issues.apache.org/jira/browse/TS-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-860: Attachment: host_not_found.diff Built in error for host not found looks like Internet Explorer error Key: TS-860 URL: https://issues.apache.org/jira/browse/TS-860 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.0, 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 Reporter: William Bardwell Attachments: host_not_found.diff There are built in error pages that look like Internet Explorer error pages. These might be copyright Microsoft, but are a bit odd in any case. I think that we should just use the text from the body_factory page instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-861) Need a way to disable Vary: Accept-Encoding checking so a plugin can take care of that
[ https://issues.apache.org/jira/browse/TS-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-861: Attachment: vary_accept_encoding.diff Need a way to disable Vary: Accept-Encoding checking so a plugin can take care of that -- Key: TS-861 URL: https://issues.apache.org/jira/browse/TS-861 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor Attachments: vary_accept_encoding.diff I was using the proxy.config.http.cache.ignore_accept_encoding_mismatch config setting and providing alt selection hooks to try to let a plugin take over handling of gzip vs uncompressed content, but I found that the checking of Vary: Accept-Encoding headers happened before alt selection, and so the plugin never got the chance to say gzip content is fine, I will transform it before sending it. So I added additional meaning to that setting to fix that. Perhaps the code should be attached to an all new config setting, but I found the existing meaning of that setting to not do enough. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-862) Need to be able to make keep alive connections not shared on a per-transaction basis
Need to be able to make keep alive connections not shared on a per-transaction basis Key: TS-862 URL: https://issues.apache.org/jira/browse/TS-862 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor Attachments: keep_alive_private.diff I want to be able to be able to mark keep alive connections as not shared on a per-transaction (really per-origin server) basis. There is a config option proxy.config.http.share_server_session but making it be per-transaction is not quite enough because the code that checks that in HttpServerSession::release() doesn't have a transaction any more. So I thought that it was easier to just make HttpServerSession.private_session settable from the plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-862) Need to be able to make keep alive connections not shared on a per-transaction basis
[ https://issues.apache.org/jira/browse/TS-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-862: Attachment: keep_alive_private.diff Need to be able to make keep alive connections not shared on a per-transaction basis Key: TS-862 URL: https://issues.apache.org/jira/browse/TS-862 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor Attachments: keep_alive_private.diff I want to be able to be able to mark keep alive connections as not shared on a per-transaction (really per-origin server) basis. There is a config option proxy.config.http.share_server_session but making it be per-transaction is not quite enough because the code that checks that in HttpServerSession::release() doesn't have a transaction any more. So I thought that it was easier to just make HttpServerSession.private_session settable from the plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-863) I want to be able to set proxy.config.http.keep_alive_no_activity_timeout_out per-transaction
I want to be able to set proxy.config.http.keep_alive_no_activity_timeout_out per-transaction - Key: TS-863 URL: https://issues.apache.org/jira/browse/TS-863 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor I want to be able to set this the same as you can set proxy.config.http.keep_alive_no_activity_timeout_in. I have a patch, but it just turns off a couple of calls, which seems wrong because I suspect that those calls are supposed to re-set the 'active'-ness of the connections, but it works reasonably for me even so. (The calls are disabled because they are being made after the code doesn't have a transaction to check the config in.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-863) I want to be able to set proxy.config.http.keep_alive_no_activity_timeout_out per-transaction
[ https://issues.apache.org/jira/browse/TS-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-863: Attachment: keep_alive_out.diff I want to be able to set proxy.config.http.keep_alive_no_activity_timeout_out per-transaction - Key: TS-863 URL: https://issues.apache.org/jira/browse/TS-863 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor Attachments: keep_alive_out.diff I want to be able to set this the same as you can set proxy.config.http.keep_alive_no_activity_timeout_in. I have a patch, but it just turns off a couple of calls, which seems wrong because I suspect that those calls are supposed to re-set the 'active'-ness of the connections, but it works reasonably for me even so. (The calls are disabled because they are being made after the code doesn't have a transaction to check the config in.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-864) Need more information from CacheHttpInfo (req time, resp time, size)
Need more information from CacheHttpInfo (req time, resp time, size) Key: TS-864 URL: https://issues.apache.org/jira/browse/TS-864 Project: Traffic Server Issue Type: New Feature Reporter: William Bardwell Priority: Minor I needed access to more fields in the CacheHttpInfo that you get from doing cache scans. Patch enclosed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-864) Need more information from CacheHttpInfo (req time, resp time, size)
[ https://issues.apache.org/jira/browse/TS-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-864: Attachment: cache_info.diff Need more information from CacheHttpInfo (req time, resp time, size) Key: TS-864 URL: https://issues.apache.org/jira/browse/TS-864 Project: Traffic Server Issue Type: New Feature Reporter: William Bardwell Priority: Minor Attachments: cache_info.diff I needed access to more fields in the CacheHttpInfo that you get from doing cache scans. Patch enclosed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-865) Need to get address for a VConn from a plugin similar to how you can get it for the various things in a transaction
Need to get address for a VConn from a plugin similar to how you can get it for the various things in a transaction --- Key: TS-865 URL: https://issues.apache.org/jira/browse/TS-865 Project: Traffic Server Issue Type: New Feature Reporter: William Bardwell Attachments: vconn_local_addr.diff I will add the patch to add TSNetVConnLocalAddrGet() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-866) Need way to clear contents of a cache entry
Need way to clear contents of a cache entry --- Key: TS-866 URL: https://issues.apache.org/jira/browse/TS-866 Project: Traffic Server Issue Type: New Feature Components: Cache Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor Attachments: cache_erase.diff I needed a way to clear a cache entry off of disk, not just forget about it. The worry was about if you got content on a server that was illegal or a privacy violation of some sort, we wanted a way to be able to tell customers that after this step there was no way that TS could serve the content again. The normal cache remove just clears the directory entry, but theoretically a bug could allow that data out in some way. This was not intended to prevent forensic analysis of the hardware being able to recover the data. And bugs in low level drivers or the kernel could theoretically allow data to survive due to block remapping or mis-management of disk caches. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-866) Need way to clear contents of a cache entry
[ https://issues.apache.org/jira/browse/TS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-866: Attachment: cache_erase.diff Need way to clear contents of a cache entry --- Key: TS-866 URL: https://issues.apache.org/jira/browse/TS-866 Project: Traffic Server Issue Type: New Feature Components: Cache Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor Attachments: cache_erase.diff I needed a way to clear a cache entry off of disk, not just forget about it. The worry was about if you got content on a server that was illegal or a privacy violation of some sort, we wanted a way to be able to tell customers that after this step there was no way that TS could serve the content again. The normal cache remove just clears the directory entry, but theoretically a bug could allow that data out in some way. This was not intended to prevent forensic analysis of the hardware being able to recover the data. And bugs in low level drivers or the kernel could theoretically allow data to survive due to block remapping or mis-management of disk caches. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-867) PluginVC crashes with TSFetchURL
PluginVC crashes with TSFetchURL
Key: TS-867
URL: https://issues.apache.org/jira/browse/TS-867
Project: Traffic Server
Issue Type: Bug
Reporter: Naveen
The call_event does not match with any of the
events(active_event,inactive_event,core_lock_retry_event,sm_lock_retry_event).
However, on trace analysis it actually matches with sm_lock_retry_event.
(gdb) bt
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb7a1ae71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7a1e34e in abort () at abort.c:92
#3 0xb7fad9a4 in ink_die_die_die (retval=1) at ink_error.cc:43
#4 0xb7fada79 in ink_fatal_va (return_code=1, message_format=0xb5767f5c
PluginVC.cc:193: failed assert `call_event == core_lock_retry_event`,
ap=0xb5767f38 ) at ink_error.cc:65
#5 0xb7fadabd in ink_fatal (return_code=1, message_format=0xb5767f5c
PluginVC.cc:193: failed assert `call_event == core_lock_retry_event`)
at ink_error.cc:73
#6 0xb7fac684 in _ink_assert (a=0x8302b10 call_event ==
core_lock_retry_event, f=0x8302a2d PluginVC.cc, l=193) at ink_assert.cc:44
#7 0x0813e0fa in PluginVC::main_handler (this=0x896a7fc, event=1,
data=0x8999890) at PluginVC.cc:193
#8 0x0810bd47 in Continuation::handleEvent (this=0x896a7fc, event=1,
data=0x8999890) at ../iocore/eventsystem/I_Continuation.h:146
#9 0x082f2a8a in EThread::process_event (this=0xb6577008, e=0x8999890,
calling_code=1) at UnixEThread.cc:140
#10 0x082f2f30 in EThread::execute (this=0xb6577008) at UnixEThread.cc:232
#11 0x082f1b75 in spawn_thread_internal (a=0x891a1e0) at Thread.cc:85
#12 0xb7f89e99 in start_thread (arg=0xb5768b70) at pthread_create.c:304
#13 0xb7ac073e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) f 7
#7 0x0813e0fa in PluginVC::main_handler (this=0x896a7fc, event=1,
data=0x8999890) at PluginVC.cc:193
193 ink_release_assert(call_event == core_lock_retry_event);
(gdb) print *this
$1 = {NetVConnection = {VConnection = {Continuation =
{force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x8303188}, handler = (
int (Continuation::*)(Continuation *, int, void *)) 0x813dc66
PluginVC::main_handler(int, void*),
handler_name = 0x8302a06 PluginVC::main_handler, mutex = {m_ptr =
0x8979c30}, link = {SLinkContinuation = {next = 0x0},
prev = 0x0}}, lerrno = 0}, options = {ip_proto =
NetVCOptions::USE_TCP, local_port = 0, port_binding = NetVCOptions::ANY_PORT,
local_addr = 0, addr_binding = NetVCOptions::ANY_ADDR, f_blocking =
false, f_blocking_connect = false, socks_support = 0 '\000',
socks_version = 0 '\000', socket_recv_bufsize = 0, socket_send_bufsize =
0, sockopt_flags = 0, static SOCK_OPT_NO_DELAY = 1,
static SOCK_OPT_KEEP_ALIVE = 2, etype = 0}, socks_addr = {type = 0
'\000', addr = {ipv4 = \000\000\000, buf = 0x0}}, attributes = 0,
thread = 0xb6a7c008, local_addr = {ss_family = 0, __ss_align = 0,
__ss_padding = '\000' repeats 119 times}, remote_addr = {ss_family = 0,
__ss_align = 0, __ss_padding = '\000' repeats 119 times},
got_local_addr = 0, got_remote_addr = 0, is_internal_request = false,
is_transparent = 49, is_other_side_transparent = false}, magic =
2864434397, vc_type = PLUGIN_VC_ACTIVE, core_obj = 0x896a7e0,
other_side = 0x896a9fc, read_state = {vio = {_cont = 0x8970e30, nbytes =
9223372036854775807, ndone = 0, op = 1, buffer = {mbuf = 0x8995b40,
entry = 0x0, name = 0x0}, vc_server = 0x896a7fc, mutex = {m_ptr =
0x89b8a60}}, shutdown = false}, write_state = {vio = {
_cont = 0x8970e30, nbytes = 188, ndone = 0, op = 2, buffer = {mbuf =
0x8994d80, entry = 0x8994d94, name = 0x0}, vc_server = 0x896a7fc,
mutex = {m_ptr = 0x89b8a60}}, shutdown = false}, need_read_process =
true, need_write_process = true, closed = false,
sm_lock_retry_event = 0x8999890, core_lock_retry_event = 0x0, deletable =
false, reentrancy_count = 1, active_timeout = 0,
inactive_timeout = 0, active_event = 0x0, inactive_event = 0x0}
(gdb) print sm_lock_retry_event
$5 = (Event *) 0x8999890
(gdb) print call_event
$6 = (Event *) 0x8999890
(gdb) print this-write_state-vio-_cont-handler_name
$7 = 0x82fae82 FetchSM::fetch_handler
(gdb) print this-read_state-vio-_cont-handler_name
$8 = 0x82fae82 FetchSM::fetch_handler
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-866) Need way to clear contents of a cache entry
[ https://issues.apache.org/jira/browse/TS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-866: - Fix Version/s: 3.1.0 Need way to clear contents of a cache entry --- Key: TS-866 URL: https://issues.apache.org/jira/browse/TS-866 Project: Traffic Server Issue Type: New Feature Components: Cache Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor Fix For: 3.1.0 Attachments: cache_erase.diff I needed a way to clear a cache entry off of disk, not just forget about it. The worry was about if you got content on a server that was illegal or a privacy violation of some sort, we wanted a way to be able to tell customers that after this step there was no way that TS could serve the content again. The normal cache remove just clears the directory entry, but theoretically a bug could allow that data out in some way. This was not intended to prevent forensic analysis of the hardware being able to recover the data. And bugs in low level drivers or the kernel could theoretically allow data to survive due to block remapping or mis-management of disk caches. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-854) backdoor port 8084 should be bind on 127.0.0.1?
[
https://issues.apache.org/jira/browse/TS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-854:
-
Fix Version/s: 3.1.0
backdoor port 8084 should be bind on 127.0.0.1?
---
Key: TS-854
URL: https://issues.apache.org/jira/browse/TS-854
Project: Traffic Server
Issue Type: Improvement
Components: Management
Affects Versions: 3.1.0
Reporter: Zhao Yongming
Priority: Minor
Fix For: 3.1.0
8084 is now just for cop do health checking on server, it should not open to
the wild Internet by default.
{codes}
zym6400 trafficserver # netstat -lantp | grep 8084
tcp0 0 127.0.0.1:8084 0.0.0.0:* LISTEN
22919/traffic_serve
tcp0 0 127.0.0.1:8084 127.0.0.1:53968 TIME_WAIT
-
tcp0 0 127.0.0.1:8084 127.0.0.1:34967 TIME_WAIT
-
tcp0 0 127.0.0.1:8084 127.0.0.1:56713 TIME_WAIT
-
tcp0 0 127.0.0.1:8084 127.0.0.1:58371 TIME_WAIT
-
tcp0 0 127.0.0.1:8084 127.0.0.1:37322 TIME_WAIT
-
tcp0 0 127.0.0.1:8084 127.0.0.1:39422 TIME_WAIT
-
{codes}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-860) Built in error for host not found looks like Internet Explorer error
[ https://issues.apache.org/jira/browse/TS-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-860: - Fix Version/s: 3.1.0 Built in error for host not found looks like Internet Explorer error Key: TS-860 URL: https://issues.apache.org/jira/browse/TS-860 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.0, 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 Reporter: William Bardwell Fix For: 3.1.0 Attachments: host_not_found.diff There are built in error pages that look like Internet Explorer error pages. These might be copyright Microsoft, but are a bit odd in any case. I think that we should just use the text from the body_factory page instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-862) Need to be able to make keep alive connections not shared on a per-transaction basis
[ https://issues.apache.org/jira/browse/TS-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-862: - Fix Version/s: 3.1.0 Need to be able to make keep alive connections not shared on a per-transaction basis Key: TS-862 URL: https://issues.apache.org/jira/browse/TS-862 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor Fix For: 3.1.0 Attachments: keep_alive_private.diff I want to be able to be able to mark keep alive connections as not shared on a per-transaction (really per-origin server) basis. There is a config option proxy.config.http.share_server_session but making it be per-transaction is not quite enough because the code that checks that in HttpServerSession::release() doesn't have a transaction any more. So I thought that it was easier to just make HttpServerSession.private_session settable from the plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-867) PluginVC crashes with TSFetchURL
[
https://issues.apache.org/jira/browse/TS-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-867:
-
Fix Version/s: 3.1.0
PluginVC crashes with TSFetchURL
Key: TS-867
URL: https://issues.apache.org/jira/browse/TS-867
Project: Traffic Server
Issue Type: Bug
Reporter: Naveen
Labels: api, plugin
Fix For: 3.1.0
On TSFetchURL call, the call_event in PluginVC does not match with any of the
events(active_event,inactive_event,core_lock_retry_event,sm_lock_retry_event).
However, on trace analysis it actually matches with sm_lock_retry_event.
(gdb) bt
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb7a1ae71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7a1e34e in abort () at abort.c:92
#3 0xb7fad9a4 in ink_die_die_die (retval=1) at ink_error.cc:43
#4 0xb7fada79 in ink_fatal_va (return_code=1, message_format=0xb5767f5c
PluginVC.cc:193: failed assert `call_event == core_lock_retry_event`,
ap=0xb5767f38 ) at ink_error.cc:65
#5 0xb7fadabd in ink_fatal (return_code=1, message_format=0xb5767f5c
PluginVC.cc:193: failed assert `call_event == core_lock_retry_event`)
at ink_error.cc:73
#6 0xb7fac684 in _ink_assert (a=0x8302b10 call_event ==
core_lock_retry_event, f=0x8302a2d PluginVC.cc, l=193) at ink_assert.cc:44
#7 0x0813e0fa in PluginVC::main_handler (this=0x896a7fc, event=1,
data=0x8999890) at PluginVC.cc:193
#8 0x0810bd47 in Continuation::handleEvent (this=0x896a7fc, event=1,
data=0x8999890) at ../iocore/eventsystem/I_Continuation.h:146
#9 0x082f2a8a in EThread::process_event (this=0xb6577008, e=0x8999890,
calling_code=1) at UnixEThread.cc:140
#10 0x082f2f30 in EThread::execute (this=0xb6577008) at UnixEThread.cc:232
#11 0x082f1b75 in spawn_thread_internal (a=0x891a1e0) at Thread.cc:85
#12 0xb7f89e99 in start_thread (arg=0xb5768b70) at pthread_create.c:304
#13 0xb7ac073e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) f 7
#7 0x0813e0fa in PluginVC::main_handler (this=0x896a7fc, event=1,
data=0x8999890) at PluginVC.cc:193
193 ink_release_assert(call_event == core_lock_retry_event);
(gdb) print *this
$1 = {NetVConnection = {VConnection = {Continuation =
{force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x8303188}, handler = (
int (Continuation::*)(Continuation *, int, void *)) 0x813dc66
PluginVC::main_handler(int, void*),
handler_name = 0x8302a06 PluginVC::main_handler, mutex = {m_ptr =
0x8979c30}, link = {SLinkContinuation = {next = 0x0},
prev = 0x0}}, lerrno = 0}, options = {ip_proto =
NetVCOptions::USE_TCP, local_port = 0, port_binding = NetVCOptions::ANY_PORT,
local_addr = 0, addr_binding = NetVCOptions::ANY_ADDR, f_blocking =
false, f_blocking_connect = false, socks_support = 0 '\000',
socks_version = 0 '\000', socket_recv_bufsize = 0, socket_send_bufsize
= 0, sockopt_flags = 0, static SOCK_OPT_NO_DELAY = 1,
static SOCK_OPT_KEEP_ALIVE = 2, etype = 0}, socks_addr = {type = 0
'\000', addr = {ipv4 = \000\000\000, buf = 0x0}}, attributes = 0,
thread = 0xb6a7c008, local_addr = {ss_family = 0, __ss_align = 0,
__ss_padding = '\000' repeats 119 times}, remote_addr = {ss_family = 0,
__ss_align = 0, __ss_padding = '\000' repeats 119 times},
got_local_addr = 0, got_remote_addr = 0, is_internal_request = false,
is_transparent = 49, is_other_side_transparent = false}, magic =
2864434397, vc_type = PLUGIN_VC_ACTIVE, core_obj = 0x896a7e0,
other_side = 0x896a9fc, read_state = {vio = {_cont = 0x8970e30, nbytes =
9223372036854775807, ndone = 0, op = 1, buffer = {mbuf = 0x8995b40,
entry = 0x0, name = 0x0}, vc_server = 0x896a7fc, mutex = {m_ptr =
0x89b8a60}}, shutdown = false}, write_state = {vio = {
_cont = 0x8970e30, nbytes = 188, ndone = 0, op = 2, buffer = {mbuf =
0x8994d80, entry = 0x8994d94, name = 0x0}, vc_server = 0x896a7fc,
mutex = {m_ptr = 0x89b8a60}}, shutdown = false}, need_read_process =
true, need_write_process = true, closed = false,
sm_lock_retry_event = 0x8999890, core_lock_retry_event = 0x0, deletable =
false, reentrancy_count = 1, active_timeout = 0,
inactive_timeout = 0, active_event = 0x0, inactive_event = 0x0}
(gdb) print sm_lock_retry_event
$5 = (Event *) 0x8999890
(gdb) print call_event
$6 = (Event *) 0x8999890
(gdb) print this-write_state-vio-_cont-handler_name
$7 = 0x82fae82 FetchSM::fetch_handler
(gdb) print this-read_state-vio-_cont-handler_name
$8 = 0x82fae82 FetchSM::fetch_handler
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-865) Need to get address for a VConn from a plugin similar to how you can get it for the various things in a transaction
[ https://issues.apache.org/jira/browse/TS-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-865: - Fix Version/s: 3.1.0 Need to get address for a VConn from a plugin similar to how you can get it for the various things in a transaction --- Key: TS-865 URL: https://issues.apache.org/jira/browse/TS-865 Project: Traffic Server Issue Type: New Feature Reporter: William Bardwell Fix For: 3.1.0 Attachments: vconn_local_addr.diff I will add the patch to add TSNetVConnLocalAddrGet() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-864) Need more information from CacheHttpInfo (req time, resp time, size)
[ https://issues.apache.org/jira/browse/TS-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-864: - Fix Version/s: 3.1.0 Need more information from CacheHttpInfo (req time, resp time, size) Key: TS-864 URL: https://issues.apache.org/jira/browse/TS-864 Project: Traffic Server Issue Type: New Feature Reporter: William Bardwell Priority: Minor Fix For: 3.1.0 Attachments: cache_info.diff I needed access to more fields in the CacheHttpInfo that you get from doing cache scans. Patch enclosed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-856) ATS doesn't build on Solaris Studio 12.2 in 32 bit mode
[
https://issues.apache.org/jira/browse/TS-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-856:
-
Fix Version/s: 3.1.0
ATS doesn't build on Solaris Studio 12.2 in 32 bit mode
---
Key: TS-856
URL: https://issues.apache.org/jira/browse/TS-856
Project: Traffic Server
Issue Type: Bug
Components: Build, DNS
Affects Versions: 3.1.0, 3.0.0
Environment: Solaris 10, x86, Solaris Studio 12.2
Reporter: Igor Galić
Fix For: 3.1.0
Attachments: sunpro12.2-32bit.patch
Because our build system automatically adds -m64 on Solaris/SunPro, we're
unable to compile Traffic Server in 32bit mode: This is necessary because
some libraries simply aren't available in 64bit.
I've created a patch to alter this behaviour, except now it cannot link
traffic_server:
{noformat}
gmake[2]: Entering directory
`/buildr/mgar/pkg/trafficserver/trunk/work/build-isa-i386/trafficserver-3.0.0/proxy'
/bin/bash ../libtool --tag=CXX --mode=link /opt/solstudio12.2/bin/CC -m32
-xO3 -g -mt -library=stlport4 -erroff -R/opt/csw/lib -L/opt/csw/lib -L/lib
-L/usr/local/lib -o traffic_server AbstractBuffer.o CacheControl.o
ProxyConfig.o ControlBase.o ControlMatcher.o CoreUtils.o DiagsConfig.o
Error.o EventName.o ICP.o ICPConfig.o ICPProcessor.o ICPStats.o InkAPI.o
FetchSM.o InkIOCoreAPI.o InkXml.o IPAllow.o Main.o ParentSelection.o Plugin.o
PluginDB.o PluginVC.o Prefetch.o ReverseProxy.o signals.o SocksProxy.o
StatPages.o StatSystem.o Transform.o Update.o InkAPITest.o RegressionSM.o
TestHook.o http/libhttp.a http/remap/libhttp_remap.a
congest/libCongestionControl.a logging/liblogging.a logging/liblogcollation.a
stats/libstats.a hdrs/libhdrs.a ../mgmt/preparse/libpreparse.a
../mgmt/utils/libutils_p.a ../mgmt/libmgmt_p.a ../iocore/utils/libinkutils.a
../iocore/cluster/libinkcluster.a ../iocore/dns/libinkdns.a
../iocore/hostdb/libinkhostdb.a ../iocore/dns/libinkdns.a
../iocore/cluster/libinkcluster.a ../iocore/cache/libinkcache.a
../iocore/aio/libinkaio.a ../iocore/net/libinknet.a
../iocore/eventsystem/libinkevent.a ../lib/records/librecprocess.a
../iocore/eventsystem/libinkevent.a ../lib/ts/libtsutil.la -lpthread -lsocket
-lnsl -lresolv -lposix4 -lpcre -lssl -lcrypto -L/opt/csw/lib -ltcl8.4 -ldl
-lexpat -ldemangle -liconv -lm-lz
libtool: link: /opt/solstudio12.2/bin/CC -m32 -xO3 -g -mt -erroff -o
.libs/traffic_server AbstractBuffer.o CacheControl.o ProxyConfig.o
ControlBase.o ControlMatcher.o CoreUtils.o DiagsConfig.o Error.o EventName.o
ICP.o ICPConfig.o ICPProcessor.o ICPStats.o InkAPI.o FetchSM.o InkIOCoreAPI.o
InkXml.o IPAllow.o Main.o ParentSelection.o Plugin.o PluginDB.o PluginVC.o
Prefetch.o ReverseProxy.o signals.o SocksProxy.o StatPages.o StatSystem.o
Transform.o Update.o InkAPITest.o RegressionSM.o TestHook.o -L/opt/csw/lib
-L/lib -L/usr/local/lib http/libhttp.a http/remap/libhttp_remap.a
congest/libCongestionControl.a logging/liblogging.a logging/liblogcollation.a
stats/libstats.a hdrs/libhdrs.a ../mgmt/preparse/libpreparse.a
../mgmt/utils/libutils_p.a ../mgmt/libmgmt_p.a ../iocore/utils/libinkutils.a
../iocore/hostdb/libinkhostdb.a ../iocore/dns/libinkdns.a
../iocore/cluster/libinkcluster.a ../iocore/cache/libinkcache.a
../iocore/aio/libinkaio.a ../iocore/net/libinknet.a
../lib/records/librecprocess.a ../iocore/eventsystem/libinkevent.a
../lib/ts/.libs/libtsutil.so -library=stlport4 -lc -lpthread -lsocket -lnsl
-lresolv -lposix4 -lpcre -lssl -lcrypto -ltcl8.4 -ldl -lexpat -ldemangle
-liconv -lm -lz -mt -R/opt/csw/lib
Undefined first referenced
symbol in file
int ink_res_mkquery(__ink_res_state*,int,const char*,int,int,const unsigned
char*,int,const unsigned char*,unsigned char*,int)
../iocore/dns/libinkdns.a(DNS.o)
ld: fatal: Symbol referencing errors. No output written to
.libs/traffic_server
gmake[2]: *** [traffic_server] Error 2
gmake[2]: Leaving directory
`/buildr/mgar/pkg/trafficserver/trunk/work/build-isa-i386/trafficserver-3.0.0/proxy'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/buildr/mgar/pkg/trafficserver/trunk/work/build-isa-i386/trafficserver-3.0.0/proxy'
gmake: *** [all-recursive] Error 1
igalic@asd5inbld002:/buildr/mgar/pkg/trafficserver/trunk/work/build-isa-i386/trafficserver-3.0.0
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-844) ReadFromWriter fail in CacheRead.cc
[
https://issues.apache.org/jira/browse/TS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-844:
-
Fix Version/s: 3.1.0
ReadFromWriter fail in CacheRead.cc
---
Key: TS-844
URL: https://issues.apache.org/jira/browse/TS-844
Project: Traffic Server
Issue Type: Bug
Reporter: mohan_zl
Fix For: 3.1.0
Attachments: TS-844.patch
{code}
#6 0x006ab4d7 in CacheVC::openReadChooseWriter (this=0x2aaaf81523d0,
event=1, e=0x0) at CacheRead.cc:320
#7 0x006abdc9 in CacheVC::openReadFromWriter (this=0x2aaaf81523d0,
event=1, e=0x0) at CacheRead.cc:411
#8 0x004d302f in Continuation::handleEvent (this=0x2aaaf81523d0,
event=1, data=0x0) at I_Continuation.h:146
#9 0x006ae2b9 in Cache::open_read (this=0x2aaab0001c40,
cont=0x2aaab4472aa0, key=0x42100b10, request=0x2aaab44710f0,
params=0x2aaab4470928, type=CACHE_FRAG_TYPE_HTTP,
hostname=0x2aab09581049
js.tongji.linezing.comicon1.gifjs.tongji.linezing.com�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ���...,
host_len=22) at CacheRead.cc:228
#10 0x0068da30 in Cache::open_read (this=0x2aaab0001c40,
cont=0x2aaab4472aa0, url=0x2aaab4471108, request=0x2aaab44710f0,
params=0x2aaab4470928,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1068
#11 0x0067d32f in CacheProcessor::open_read (this=0xf2c030,
cont=0x2aaab4472aa0, url=0x2aaab4471108, request=0x2aaab44710f0,
params=0x2aaab4470928, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3011
#12 0x0054e058 in HttpCacheSM::do_cache_open_read
(this=0x2aaab4472aa0) at HttpCacheSM.cc:220
#13 0x0054e1a7 in HttpCacheSM::open_read (this=0x2aaab4472aa0,
url=0x2aaab4471108, hdr=0x2aaab44710f0, params=0x2aaab4470928,
pin_in_cache=0) at HttpCacheSM.cc:252
#14 0x00568404 in HttpSM::do_cache_lookup_and_read
(this=0x2aaab4470830) at HttpSM.cc:3893
#15 0x005734b5 in HttpSM::set_next_state (this=0x2aaab4470830) at
HttpSM.cc:6436
#16 0x0056115a in HttpSM::call_transact_and_set_next_state
(this=0x2aaab4470830, f=0) at HttpSM.cc:6328
#17 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at
HttpSM.cc:1516
#18 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830,
event=0, data=0x0) at HttpSM.cc:1448
#19 0x0056de77 in HttpSM::do_api_callout_internal
(this=0x2aaab4470830) at HttpSM.cc:4345
#20 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at
HttpSM.cc:497
#21 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at
HttpSM.cc:6362
#22 0x0056115a in HttpSM::call_transact_and_set_next_state
(this=0x2aaab4470830, f=0) at HttpSM.cc:6328
#23 0x00572faf in HttpSM::set_next_state (this=0x2aaab4470830) at
HttpSM.cc:6378
#24 0x0056115a in HttpSM::call_transact_and_set_next_state
(this=0x2aaab4470830, f=0) at HttpSM.cc:6328
#25 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at
HttpSM.cc:1516
#26 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830,
event=0, data=0x0) at HttpSM.cc:1448
#27 0x0056de77 in HttpSM::do_api_callout_internal
(this=0x2aaab4470830) at HttpSM.cc:4345
#28 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at
HttpSM.cc:497
#29 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at
HttpSM.cc:6362
#30 0x0056115a in HttpSM::call_transact_and_set_next_state
(this=0x2aaab4470830, f=0) at HttpSM.cc:6328
#31 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at
HttpSM.cc:1516
#32 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830,
event=0, data=0x0) at HttpSM.cc:1448
#33 0x0056de77 in HttpSM::do_api_callout_internal
(this=0x2aaab4470830) at HttpSM.cc:4345
#34 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at
HttpSM.cc:497
#35 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at
HttpSM.cc:6362
#36 0x0056115a in HttpSM::call_transact_and_set_next_state
(this=0x2aaab4470830, f=0x59e52e
HttpTransact::ModifyRequest(HttpTransact::State*)) at HttpSM.cc:6328
#37 0x0057490c in HttpSM::state_read_client_request_header
(this=0x2aaab4470830, event=100, data=0x2049f5e8) at HttpSM.cc:780
#38 0x0056e49f in HttpSM::main_handler (this=0x2aaab4470830,
event=100, data=0x2049f5e8) at HttpSM.cc:2436
#39 0x004d302f in
[jira] [Updated] (TS-863) I want to be able to set proxy.config.http.keep_alive_no_activity_timeout_out per-transaction
[ https://issues.apache.org/jira/browse/TS-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-863: - Fix Version/s: 3.1.0 I want to be able to set proxy.config.http.keep_alive_no_activity_timeout_out per-transaction - Key: TS-863 URL: https://issues.apache.org/jira/browse/TS-863 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor Fix For: 3.1.0 Attachments: keep_alive_out.diff I want to be able to set this the same as you can set proxy.config.http.keep_alive_no_activity_timeout_in. I have a patch, but it just turns off a couple of calls, which seems wrong because I suspect that those calls are supposed to re-set the 'active'-ness of the connections, but it works reasonably for me even so. (The calls are disabled because they are being made after the code doesn't have a transaction to check the config in.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-849) proxy.config.http.slow.log.threshold is unable to set from traffic_line -s
[
https://issues.apache.org/jira/browse/TS-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-849:
-
Fix Version/s: 3.1.0
proxy.config.http.slow.log.threshold is unable to set from traffic_line -s
--
Key: TS-849
URL: https://issues.apache.org/jira/browse/TS-849
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.1.0, 3.0.1
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.0
I am wondering how many config items from records have the same situation?
{code}
[root@cache164 trafficserver]# traffic_line -s
proxy.config.http.slow.log.threshold -v 30
Layout configuration
--prefix = '/usr'
--exec_prefix = '/usr'
--bindir = '/usr/bin'
--sbindir = '/usr/sbin'
--sysconfdir = '/etc/trafficserver'
--datadir = '/usr/share/trafficserver'
--includedir = '/usr/include/trafficserver'
--libdir = '/usr/lib64/trafficserver'
--libexecdir = '/usr/lib64/trafficserver/plugins'
--localstatedir = '/var/trafficserver'
--runtimedir = '/var/run/trafficserver'
--logdir = '/var/log/trafficserver'
--mandir = '/usr/share/man'
--infodir = '/usr/share/info'
--cachedir = '/var/cache/trafficserver'
traffic_line: Only configuration vars can be set
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-859) ATS requesting to origin instead to the parent server
[ https://issues.apache.org/jira/browse/TS-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-859: - Fix Version/s: 3.1.0 ATS requesting to origin instead to the parent server - Key: TS-859 URL: https://issues.apache.org/jira/browse/TS-859 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP, Network Affects Versions: 3.0.0 Environment: ATS 3.0 CentOS 5.6 Linux 2.6.18-238.12.1.el5 64 bit. gcc 4.1.2-50.el5 Compiled in this machine. Clean installation. Reporter: Francisco Sariego Fix For: 3.1.0 I'm trying to configure parent servers for hierarchical caching in a forward proxy mode, but I am showing strange effects. I have 3 servers: - The ATS 3.0 server (172.16.1.144) - The parents (172.16.1.195, 172.16.1.196) My installation is clean and I've changed only a few parameters. - records.config: CONFIG proxy.config.url_remap.remap_required INT 0 CONFIG proxy.config.http.parent_proxy_routing_enable INT 1 - parent.config dest_domain=. parent=172.16.1.195:8080; 172.16.1.196:8080 round_robin=strict If I request http://www.apache.org from my web browser, I see, using tcpdump port 8080 -nn in the ATS 3.0 machine connections to 140.211.11.131.8080 (www.apache.org) but nothing to the parent servers. Connectivity between the ATS and the parents are confirmed using telnet to the 8080 port, and is responding to HTTP requests. If I disable the parent config, ATS 3.0 works well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-852) hostdb and dns system hangup
[
https://issues.apache.org/jira/browse/TS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-852:
-
Fix Version/s: 3.1.0
hostdb and dns system hangup
Key: TS-852
URL: https://issues.apache.org/jira/browse/TS-852
Project: Traffic Server
Issue Type: Bug
Components: Core, DNS
Affects Versions: 3.1.0
Reporter: Zhao Yongming
Priority: Critical
Labels: dns, hostdb
Fix For: 3.1.0
in my testing, all request that need go OS, fails with 30s timeout, and the
slow query shows data from dns missed:
{code}
[Jun 22 15:33:47.183] Server {1106880832} ERROR: [8122411] Slow Request: url:
http://download.im.alisoft.com/aliim/AliIM6/update/packages//2011-5-4-10-10-40/0/modulesproxy/8203.xml.wwzip
status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 30.667 sm_finish: 30.667
[Jun 22 15:33:47.220] Server {1099663680} ERROR: [8122422] Slow Request: url:
http://img.uu1001.cn/materials/original/2010-11-22/22-48/a302876929a9c40a8272ac439a16ad25e74edf71.png
status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 30.318 sm_finish: 30.318
[Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122421] Slow Request: url:
http://img02.taobaocdn.com/bao/uploaded/i2/T1mp8QXopdXXblNIZ6_061203.jpg_b.jpg
status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 30.597 sm_finish: 30.597
[Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122409] Slow Request: url:
http://img04.taobaocdn.com/tps/i4/T1EM9gXltt-440-135.jpg status: 0
unique id: bytes: 0 fd: 0 client state: 6 server state: 0 ua_begin: 0.000
ua_read_header_done: 0.000 cache_open_read_begin: 0.000 cache_open_read_end:
0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000 server_connect: -1.000
server_first_read: -1.000 server_read_header_done: -1.000 server_close:
-1.000 ua_close: 30.948 sm_finish: 30.948
{code}
all http SM show from {http} in DNS_LOOKUP
and traffic.out show nothing with error, when I enable debug on
hostdb.*|dns.*:
{code}
[Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) probe
img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
[Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) timeout 64204
1308663404 300
[Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) delaying force 0
answer for img03.taobaocdn.com [timeout 0]
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) probe
img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) timeout 64204
1308663404 300
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) DNS
img03.taobaocdn.com
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) enqueuing
additional request
[Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) probe 127.0.0.1
E9B7563422C93608 1 [ignore_timeout = 0]
[Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) immediate
answer for 127.0.0.1
[Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) probe
img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
[Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) timeout 64281
1308663327 300
[Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) delaying force 0
answer for img08.taobaocdn.com [timeout 0]
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) probe
img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) timeout 64281
1308663327 300
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) DNS
img08.taobaocdn.com
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) enqueuing
additional request
[Jun 22 15:27:42.470] Server {1099663680} DEBUG: (hostdb) probe 127.0.0.1
E9B7563422C93608 1 [ignore_timeout = 0]
[Jun 22 15:27:42.470] Server {1099663680} DEBUG: (hostdb) immediate answer
for 127.0.0.1
[Jun 22 15:27:42.490] Server {1106880832} DEBUG: (hostdb) probe 127.0.0.1
E9B7563422C93608
[jira] [Updated] (TS-858) traffic_server segmentation_fault when cache storage value is below 65M
[ https://issues.apache.org/jira/browse/TS-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-858: - Fix Version/s: 3.1.0 traffic_server segmentation_fault when cache storage value is below 65M --- Key: TS-858 URL: https://issues.apache.org/jira/browse/TS-858 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.0.0 Environment: Fedora 14 Reporter: Kevin Giles Priority: Minor Fix For: 3.1.0 specify the storage as var/trafficserver 64M in the storage.conf, traffic_server will core dump upon launch, the following is the stack trace: FATAL: Cache.cc:2293: failed assert `dpb dpb-len == (uint64_t)b` traffic_server - STACK TRACE: traffic_server(ink_fatal_va+0x8e)[0x82ef221] traffic_server(ink_fatal+0x1e)[0x82ef252] traffic_server(_ink_assert+0x90)[0x82eeb6c] traffic_server(_Z18cplist_reconfigurev+0x2fd)[0x8283054] traffic_server(_ZN14CacheProcessor15diskInitializedEv+0x19b)[0x827b7d1] traffic_server(_ZN9CacheDisk8openDoneEiPv+0x40)[0x8291142] traffic_server(_ZN9CacheDisk9clearDoneEiPv+0xcc)[0x8290eb2] traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x810d871] traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x2c)[0x82862c8] traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x810d871] traffic_server(_ZN7EThread13process_eventEP5Eventi+0x10e)[0x82e83f2] traffic_server(_ZN7EThread7executeEv+0xa6)[0x82e862a] traffic_server[0x82e74b1] /lib/libpthread.so.0[0x658e99] /lib/libc.so.6(clone+0x5e)[0x59ed2e] It will core dump everytime, if the cache size is set to 65M, traffic_server will launch fine. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-851) unable to run TS without a real interface
[
https://issues.apache.org/jira/browse/TS-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-851:
-
Fix Version/s: 3.1.0
unable to run TS without a real interface
-
Key: TS-851
URL: https://issues.apache.org/jira/browse/TS-851
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.1.0
Environment: trunk after TS-845
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.0
Attachments: TS-851.patch
it seems like that start_HttpProxyServerBackDoor with port
8084(proxy.config.process_manager.mgmt_port) does some dirty job, we need to
track it down.
{code}
[Jun 21 22:51:02.915] Server {47475602368256} NOTE: cache clustering disabled
[Jun 21 22:51:02.915] Server {47475602368256} NOTE: clearing statistics
[Jun 21 22:51:02.916] Server {47475602368256} DEBUG: (dns) ink_dns_init:
called with init_called = 0
[Jun 21 22:51:02.926] Server {47475602368256} DEBUG: (dns) localhost=zym6400
[Jun 21 22:51:02.927] Server {47475602368256} DEBUG: (dns) Round-robin
nameservers = 0
[Jun 21 22:51:02.932] Server {47475602368256} NOTE: cache clustering disabled
[Jun 21 22:51:02.984] Server {47475602368256} NOTE: logging initialized[7],
logging_mode = 3
[Jun 21 22:51:02.989] Server {47475602368256} DEBUG: (http_init)
proxy.config.http.redirection_enabled = 0
[Jun 21 22:51:02.989] Server {47475602368256} DEBUG: (http_init)
proxy.config.http.number_of_redirections = 1
[Jun 21 22:51:02.989] Server {47475602368256} DEBUG: (http_init)
proxy.config.http.post_copy_size = 2048
[Jun 21 22:51:02.989] Server {47475602368256} DEBUG: (http_tproxy) Primary
listen socket transparency is off
[Jun 21 22:51:02.992] Server {47475602368256} ERROR: getaddrinfo error -2:
Name or service not known
[Jun 21 22:51:02.992] Server {47475602368256} WARNING: unable to listen on
port 8084: -1 2, No such file or directory
[Jun 21 22:51:02.993] Server {47475602368256} NOTE: traffic server running
[Jun 21 22:51:02.993] Server {47475602368256} DEBUG: (dns)
DNSHandler::startEvent: on thread 0
[Jun 21 22:51:02.993] Server {47475602368256} DEBUG: (dns) open_con: opening
connection 127.0.0.1:53
[Jun 21 22:51:02.993] Server {47475602368256} DEBUG: (dns) random port = 28547
[Jun 21 22:51:02.993] Server {47475602368256} DEBUG: (dns) opening connection
127.0.0.1:53 SUCCEEDED for 0
[Jun 21 22:51:03.308] Server {47475617863424} NOTE: cache enabled
[Jun 21 22:51:21.870] Manager {140119188903712} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Jun 21 22:51:21.870] Manager {140119188903712} FATAL: (last system error
104: Connection reset by peer)
[Jun 21 22:51:21.870] Manager {140119188903712} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Jun 21 22:51:21.870] Manager {140119188903712} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
[Jun 21 22:51:21.870] Manager {140119188903712} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Jun 21 22:51:21.870] Manager {140119188903712} ERROR: (last system error
32: Broken pipe)
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
{code}
--
This message is automatically generated by JIRA.
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
]
Leif Hedstrom updated TS-857:
-
Fix Version/s: 3.1.0
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
Fix For: 3.1.0
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.
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=13058160#comment-13058160
]
mohan_zl commented on TS-857:
-
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out) at ink_stack_trace.cc:68
68 fp = (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 0x0038ff016ef1 in ink_stack_trace_dump (sighandler_frame=value
optimized out) at ink_stack_trace.cc:114
#2 0x004ddc10 in signal_handler (sig=value optimized out) at
signals.cc:225
#3 signal handler called
#4 0x006990d9 in UnixNetVConnection::do_io_close (this=0x20efd5e0,
alerrno=value optimized out) at ../../iocore/eventsystem/I_Lock.h:297
#5 0x00513f5a in HttpClientSession::do_io_close (this=0x2aaab405c420,
alerrno=-1) at HttpClientSession.cc:310
#6 0x0052588c in HttpSM::tunnel_handler_ua (this=0x2aaab87fc4f0,
event=103, c=0x2aaab87fe218) at HttpSM.cc:3027
#7 0x0056f9dc in HttpTunnel::consumer_handler (this=0x2aaab87fe1e0,
event=103, c=0x2aaab87fe218) at HttpTunnel.cc:1232
#8 0x0057095e in HttpTunnel::finish_all_internal (this=0x2aaab87fe1e0,
p=0x2aaab87fe3d8, chain=false) at HttpTunnel.cc:1359
#9 0x00526e07 in HttpSM::tunnel_handler_server (this=0x2aaab87fc4f0,
event=104, p=0x2aaab87fe3d8) at HttpTunnel.h:311
#10 0x0056eb21 in HttpTunnel::producer_handler (this=0x2aaab87fe1e0,
event=104, p=0x2aaab87fe3d8) at HttpTunnel.cc:1136
#11 0x0056fca0 in HttpTunnel::main_handler (this=0x2aaab87fe1e0,
event=-1678707408, data=value optimized out) at HttpTunnel.cc:1452
#12 0x0069f097 in read_from_net (nh=0x2adfe688, vc=0x20eb4c40,
thread=value optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 0x006940e1 in NetHandler::mainNetEvent (this=0x2adfe688,
event=value optimized out, e=0x2b706028) at UnixNet.cc:389
#14 0x006c4fdf in EThread::process_event (this=0x2adfd010,
e=0x1fc96f60, calling_code=5) at I_Continuation.h:146
#15 0x006c58ec in EThread::execute (this=0x2adfd010) at
UnixEThread.cc:262
#16 0x004be112 in main (argc=value optimized out, argv=value
optimized out) at Main.cc:1957
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
Fix For: 3.1.0
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
[jira] [Issue Comment Edited] (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=13058160#comment-13058160
]
mohan_zl edited comment on TS-857 at 7/1/11 12:55 AM:
--
The following stack trace is similar to above, but the entry point is different.
{code}
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out) at ink_stack_trace.cc:68
68 fp = (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 0x0038ff016ef1 in ink_stack_trace_dump (sighandler_frame=value
optimized out) at ink_stack_trace.cc:114
#2 0x004ddc10 in signal_handler (sig=value optimized out) at
signals.cc:225
#3 signal handler called
#4 0x006990d9 in UnixNetVConnection::do_io_close (this=0x20efd5e0,
alerrno=value optimized out) at ../../iocore/eventsystem/I_Lock.h:297
#5 0x00513f5a in HttpClientSession::do_io_close (this=0x2aaab405c420,
alerrno=-1) at HttpClientSession.cc:310
#6 0x0052588c in HttpSM::tunnel_handler_ua (this=0x2aaab87fc4f0,
event=103, c=0x2aaab87fe218) at HttpSM.cc:3027
#7 0x0056f9dc in HttpTunnel::consumer_handler (this=0x2aaab87fe1e0,
event=103, c=0x2aaab87fe218) at HttpTunnel.cc:1232
#8 0x0057095e in HttpTunnel::finish_all_internal (this=0x2aaab87fe1e0,
p=0x2aaab87fe3d8, chain=false) at HttpTunnel.cc:1359
#9 0x00526e07 in HttpSM::tunnel_handler_server (this=0x2aaab87fc4f0,
event=104, p=0x2aaab87fe3d8) at HttpTunnel.h:311
#10 0x0056eb21 in HttpTunnel::producer_handler (this=0x2aaab87fe1e0,
event=104, p=0x2aaab87fe3d8) at HttpTunnel.cc:1136
#11 0x0056fca0 in HttpTunnel::main_handler (this=0x2aaab87fe1e0,
event=-1678707408, data=value optimized out) at HttpTunnel.cc:1452
#12 0x0069f097 in read_from_net (nh=0x2adfe688, vc=0x20eb4c40,
thread=value optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 0x006940e1 in NetHandler::mainNetEvent (this=0x2adfe688,
event=value optimized out, e=0x2b706028) at UnixNet.cc:389
#14 0x006c4fdf in EThread::process_event (this=0x2adfd010,
e=0x1fc96f60, calling_code=5) at I_Continuation.h:146
#15 0x006c58ec in EThread::execute (this=0x2adfd010) at
UnixEThread.cc:262
#16 0x004be112 in main (argc=value optimized out, argv=value
optimized out) at Main.cc:1957
{code}
was (Author: wahu0315210):
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out) at ink_stack_trace.cc:68
68 fp = (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 0x0038ff016ef1 in ink_stack_trace_dump (sighandler_frame=value
optimized out) at ink_stack_trace.cc:114
#2 0x004ddc10 in signal_handler (sig=value optimized out) at
signals.cc:225
#3 signal handler called
#4 0x006990d9 in UnixNetVConnection::do_io_close (this=0x20efd5e0,
alerrno=value optimized out) at ../../iocore/eventsystem/I_Lock.h:297
#5 0x00513f5a in HttpClientSession::do_io_close (this=0x2aaab405c420,
alerrno=-1) at HttpClientSession.cc:310
#6 0x0052588c in HttpSM::tunnel_handler_ua (this=0x2aaab87fc4f0,
event=103, c=0x2aaab87fe218) at HttpSM.cc:3027
#7 0x0056f9dc in HttpTunnel::consumer_handler (this=0x2aaab87fe1e0,
event=103, c=0x2aaab87fe218) at HttpTunnel.cc:1232
#8 0x0057095e in HttpTunnel::finish_all_internal (this=0x2aaab87fe1e0,
p=0x2aaab87fe3d8, chain=false) at HttpTunnel.cc:1359
#9 0x00526e07 in HttpSM::tunnel_handler_server (this=0x2aaab87fc4f0,
event=104, p=0x2aaab87fe3d8) at HttpTunnel.h:311
#10 0x0056eb21 in HttpTunnel::producer_handler (this=0x2aaab87fe1e0,
event=104, p=0x2aaab87fe3d8) at HttpTunnel.cc:1136
#11 0x0056fca0 in HttpTunnel::main_handler (this=0x2aaab87fe1e0,
event=-1678707408, data=value optimized out) at HttpTunnel.cc:1452
#12 0x0069f097 in read_from_net (nh=0x2adfe688, vc=0x20eb4c40,
thread=value optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 0x006940e1 in NetHandler::mainNetEvent (this=0x2adfe688,
event=value optimized out, e=0x2b706028) at UnixNet.cc:389
#14 0x006c4fdf in EThread::process_event (this=0x2adfd010,
e=0x1fc96f60, calling_code=5) at I_Continuation.h:146
#15 0x006c58ec in EThread::execute (this=0x2adfd010) at
UnixEThread.cc:262
#16 0x004be112 in main (argc=value optimized out, argv=value
optimized out) at Main.cc:1957
Crash Report: HttpTunnel::chain_abort_all - HttpServerSession::do_io_close
- UnixNetVConnection::do_io_close
