[jira] [Created] (TS-1213) Crash report: update will crash at HttpTransact::process_quick_http_filter
Crash report: update will crash at HttpTransact::process_quick_http_filter
--
Key: TS-1213
URL: https://issues.apache.org/jira/browse/TS-1213
Project: Traffic Server
Issue Type: Bug
Environment: git master with update enabled.
Reporter: Zhao Yongming
the new ip_allow & quick filter may affect the scheduled update functions:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/opt/ats/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x10bc0)[0x2ab9e4318bc0]
/opt/ats/bin/traffic_server(HttpTransact::process_quick_http_filter(HttpTransact::State*,
int)+0x3b)[0x5501db]
/opt/ats/bin/traffic_server(HttpTransact::EndRemapRequest(HttpTransact::State*)+0x3a1)[0x55ed91]
/opt/ats/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x62)[0x530202]
/opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x54a)[0x54031a]
/opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x41c)[0x5401ec]
/opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x41c)[0x5401ec]
/opt/ats/bin/traffic_server(HttpSM::state_add_to_list(int,
void*)+0x18f)[0x53b2df]
/opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x53c288]
/opt/ats/bin/traffic_server(HttpUpdateSM::start_scheduled_update(Continuation*,
HTTPHdr*)+0x1c7)[0x576d97]
/opt/ats/bin/traffic_server(UpdateSM::http_scheme(UpdateSM*)+0x197)[0x4fbd77]
/opt/ats/bin/traffic_server(UpdateSM::HandleSMEvent(int,
Event*)+0x378)[0x4f7198]
/opt/ats/bin/traffic_server(EThread::process_event(Event*, int)+0x90)[0x6b0250]
/opt/ats/bin/traffic_server(EThread::execute()+0x5eb)[0x6b0e0b]
/opt/ats/bin/traffic_server[0x6af042]
/lib64/libpthread.so.0(+0x8e2c)[0x2ab9e4310e2c]
/lib64/libc.so.6(clone+0x6d)[0x2ab9e6beb35d]
{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] [Created] (TS-1212) can not limit ram cache
can not limit ram cache
---
Key: TS-1212
URL: https://issues.apache.org/jira/browse/TS-1212
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 2.1.3
Environment: we are on v3.0.x but maybe affected v3.1 and later too.
Reporter: Zhao Yongming
ram cache limit is not activate at sometime:
{code}
[yonghao@cache177 ~]$ links -dump http://localhost:8080/stat/ | grep ram
proxy.config.cache.ram_cache.size=10737418240
proxy.config.cache.ram_cache_cutoff=131072
proxy.config.cache.ram_cache.algorithm=1
proxy.config.cache.ram_cache.compress=0
proxy.config.cache.ram_cache.ssd_percent=25
proxy.config.cache.ram_cache.compress_percent=90
proxy.process.cache.ram_cache.total_bytes=12884901886
proxy.process.cache.volume_0.ram_cache.total_bytes=-7301066
proxy.process.cache.ram_cache.bytes_used=11840122880
{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] [Created] (TS-1208) check_memory() in traffic_cop never active on linux
check_memory() in traffic_cop never active on linux --- Key: TS-1208 URL: https://issues.apache.org/jira/browse/TS-1208 Project: Traffic Server Issue Type: Bug Components: Management Reporter: Zhao Yongming Assignee: Zhao Yongming check_memory() will check system memory usage to prevent OOM. and it is still on linux v2.2 codes. -- 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-1207) request for plugin cacheurl move into master tree
request for plugin cacheurl move into master tree - Key: TS-1207 URL: https://issues.apache.org/jira/browse/TS-1207 Project: Traffic Server Issue Type: New Feature Components: Plugins Affects Versions: 3.1.3 Reporter: Zhao Yongming from my testing, the cacheurl plugin is stable and usable in any version of 2.x & 3.x, should we move into the meanline? -- 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-1206) stats snap file may crash during server crash
stats snap file may crash during server crash - Key: TS-1206 URL: https://issues.apache.org/jira/browse/TS-1206 Project: Traffic Server Issue Type: Bug Reporter: Zhao Yongming when sometimes traffic_server crashed, some or all of the stats counter are not updating anymore. -- 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-1205) Crash report: double free when RecDataSet in cluster mode
Crash report: double free when RecDataSet in cluster mode
-
Key: TS-1205
URL: https://issues.apache.org/jira/browse/TS-1205
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Configuration
Affects Versions: 3.1.3
Environment: v3.0.x, with cluster mode 2
Reporter: Zhao Yongming
Fix For: 3.3.0
we have seen some config system syncing config files in cluster mode.
{code}
*** glibc detected *** /usr/bin/traffic_server: double free or corruption
(fasttop): 0x2b639c0009a0 ***
=== Backtrace: =
/lib64/libc.so.6[0x3f8f0750c6]
/usr/bin/traffic_server(RecDataSet(RecDataT, RecData*, RecData*)+0xb8)[0x65dd58]
/usr/bin/traffic_server(RecForceInsert(RecRecord*)+0x74)[0x6584b4]
/usr/bin/traffic_server[0x65cd62]
/usr/bin/traffic_server(RecMessageRecvThis(void*, char*, int)+0x16)[0x65ed46]
/usr/bin/traffic_server(BaseManager::executeMgmtCallback(int, char*,
int)+0x3d)[0x5b562d]
/usr/bin/traffic_server(ProcessManager::processEventQueue()+0x29)[0x5b5d49]
/usr/bin/traffic_server(startProcessManager(void*)+0x8d)[0x5b633d]
/lib64/libpthread.so.0[0x3f8f4077f1]
/lib64/libc.so.6(clone+0x6d)[0x3f8f0e570d]
=== Memory map:
{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] [Created] (TS-1204) Crash report: HttpSM::main_handler HttpSM.cc:2412: failed assert `magic == HTTP_SM_MAGIC_ALIVE`
Crash report: HttpSM::main_handler HttpSM.cc:2412: failed assert `magic ==
HTTP_SM_MAGIC_ALIVE`
---
Key: TS-1204
URL: https://issues.apache.org/jira/browse/TS-1204
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.3
Environment: git master Sat Apr 7 03:29:50 2012. forwarding proxy on
centos 6.2 x86_64, with cacheurl plugin
Reporter: Zhao Yongming
{code}
FATAL: HttpSM.cc:2412: failed assert `magic == HTTP_SM_MAGIC_ALIVE`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ddba14368]
/usr/lib64/trafficserver/libtsutil.so.3(_ink_assert+0x1f)[0x3ddba12c6f]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x2e)[0x5163fe]
/usr/bin/traffic_server[0x628b4b]
/usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x353)[0x62c7a3]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x2fe)[0x624cce]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6494f4]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x649e83]
/usr/bin/traffic_server[0x648832]
/lib64/libpthread.so.0[0x380dc077f1]
/lib64/libc.so.6(clone+0x6d)[0x380d0e592d]
{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] [Created] (TS-1203) Crash report: HdrHeap::duplicate_str, in host_set
Crash report: HdrHeap::duplicate_str, in host_set
-
Key: TS-1203
URL: https://issues.apache.org/jira/browse/TS-1203
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.3
Environment: 3.0.x, new crashes
Reporter: Zhao Yongming
we get some new crashes in the production:
{code}
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x727fd000
Core was generated by `/usr/bin/traffic_server -M -A,12:X,13:X'.
Program terminated with signal 11, Segmentation fault.
#0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
(gdb) bt
#0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
#1 0x005aab68 in HdrHeap::duplicate_str (this=,
str=0x2aae474a6ec0 ,
nbytes=21) at HdrHeap.cc:344
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 , s_len=21,
d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at MIME.cc:3034
#3 0x005aef28 in host_set (this=0x2aae268f8c18, url=) at URL.h:541
#4 HTTPHdr::set_url_target_from_host_field (this=0x2aae268f8c18, url=) at HTTP.cc:1484
#5 0x0055dc69 in RemapProcessor::setup_for_remap (this=, s=0x2aae268f83c8) at RemapProcessor.cc:130
#6 0x005165d9 in HttpSM::do_remap_request (this=0x2aae268f8360,
run_inline=true) at HttpSM.cc:3666
#7 0x00526cbb in HttpSM::set_next_state (this=0x2aaabd62be12) at
HttpSM.cc:6392
#8 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=) at HttpSM.cc:6345
#9 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
HttpSM.cc:6553
#10 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=) at HttpSM.cc:6345
#11 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
HttpSM.cc:6553
#12 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=) at HttpSM.cc:6345
#13 0x00520f21 in HttpSM::state_read_client_request_header
(this=0x2aae268f8360, event=100, data=)
at HttpSM.cc:783
#14 0x005259b9 in HttpSM::main_handler (this=0x2aae268f8360, event=100,
data=0x2aae68aee6e0) at HttpSM.cc:2456
#15 0x0066d1fb in handleEvent (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010)
at ../../iocore/eventsystem/I_Continuation.h:146
#16 read_signal_and_update (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010) at UnixNetVConnection.cc:138
#17 read_from_net (nh=0x2b105668, vc=0x2aae68aee520, thread=0x2b104010)
at UnixNetVConnection.cc:320
#18 0x00666579 in NetHandler::mainNetEvent (this=0x2b105668,
event=, e=0x2b8ed028) at UnixNet.cc:389
#19 0x00691c8f in EThread::process_event (this=0x2b104010,
e=0x35681c0, calling_code=5) at I_Continuation.h:146
#20 0x0069259c in EThread::execute (this=0x2b104010) at
UnixEThread.cc:263
#21 0x0069115e in spawn_thread_internal (a=0x35621b0) at Thread.cc:88
#22 0x003e5b80673d in start_thread () from /lib64/libpthread.so.0
#23 0x003e5b0d44bd in clone () from /lib64/libc.so.6
(gdb) f 1
#1 0x005aab68 in HdrHeap::duplicate_str (this=,
str=0x2aae474a6ec0 ,
nbytes=21) at HdrHeap.cc:344
344 memcpy(new_str, str, nbytes);
(gdb) p str
$1 = 0x2aae474a6ec0
(gdb) p nbytes
$2 = 21
(gdb) f 2
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 , s_len=21,
d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at MIME.cc:3034
3034s_str = heap->duplicate_str(s_str, s_len);
(gdb) p s_str
$3 = 0x2aae474a6ec0
(gdb) f 3
#3 0x005aef28 in host_set (this=0x2aae268f8c18, url=) at URL.h:541
541 url_host_set(m_heap, m_url_impl, value, length, true);
(gdb) p value
$4 =
(gdb) p length
$5 =
(gdb) f 2
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 , s_len=21,
d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at MIME.cc:3034
3034s_str = heap->duplicate_str(s_str, s_len);
(gdb) l
3029 //either NULL or be valid ptr for a string already
3030 //the string heaps
3031 heap->free_string(*d_str, *d_len);
3032
3033 if (must_copy && s_str) {
3034s_str = heap->duplicate_str(s_str, s_len);
3035 }
3036 *d_str = s_str;
3037 *d_len = s_len;
3038 return s_str;
(gdb) p d_str
$6 = (const char **) 0x2aae3656f348
(gdb) p s_str
$7 = 0x2aae474a6ec0
(gdb) p s_length
No symbol "s_length" in current context.
(gdb) p s_len
$8 = 21
(gdb) p d_len
$9 = (uint16_t *) 0x2aae3656f322
(gdb) p *d_len
$10 = 0
(gdb) p must_copy
$11 = true
(gdb) p heap
$12 = (HdrHeap *) 0x2aaabd62be12
(gdb) p *heap
$13 = {m_magic = 4244214959, m_free_start = 0xf1895c4222d0b96a ,
m_data_start = 0x285db46ea5b18c6a ,
m_size = 3748408139, m_writeable = 72,
m_next = 0x4b5d55
[jira] [Created] (TS-1201) Crash report: hostdb multicache, double free
Crash report: hostdb multicache, double free
Key: TS-1201
URL: https://issues.apache.org/jira/browse/TS-1201
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: weijin
{code}
*** glibc detected *** /usr/bin/traffic_server: corrupted double-linked list:
0x1fe10ef0 ***
=== Backtrace: =
/lib64/libc.so.6[0x3db2072555]
/lib64/libc.so.6(cfree+0x4b)[0x3db20728bb]
/usr/bin/traffic_server(_ZN14MultiCacheSync7mcEventEiP5Event+0xa4)[0x5dae04]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x22f)[0x691c8f]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x6a1)[0x692681]
/usr/bin/traffic_server[0x69115e]
/lib64/libpthread.so.0[0x3db280673d]
/lib64/libc.so.6(clone+0x6d)[0x3db20d44bd]
=== Memory map:
{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] [Created] (TS-1196) the via metrix in PURGE response should be documented
the via metrix in PURGE response should be documented
-
Key: TS-1196
URL: https://issues.apache.org/jira/browse/TS-1196
Project: Traffic Server
Issue Type: Task
Components: Documentation
Affects Versions: 3.1.3
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Minor
{code}
[yonghao@cache161.cn50 trafficserver]$ echo -ne "PURGE
http://img01.taobaocdn.com/bao/uploaded/i1/000/160/T1RoNcXn5Qj0JX.jpg_60x60.jpg
HTTP/1.0\r\n\r\n" | nc -i 1 cache162.cn50 81
HTTP/1.0 200 Ok
Date: Tue, 10 Apr 2012 07:10:30 GMT
Via: http/1.1 cn50 (ApacheTrafficServer/3.0.2 [cRs f ])
Content-Length: 0
{code}
what does the cR mean? we should document it down!
--
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-1178) cop will kill manager & server, even cop it self
cop will kill manager & server, even cop it self
Key: TS-1178
URL: https://issues.apache.org/jira/browse/TS-1178
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.1.4
Environment: git master on RHEL6.1 x86_64
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.4
{code}
[root@test58 trafficserver]# cat /tmp/traffic_cop.trace
<1333239680.> [DEBUG]: Entering init()
<1333239680.> [DEBUG]: Entering init_signals()
<1333239680.> [DEBUG]: Entering set_alarm_death()
<1333239680.> [DEBUG]: Leaving set_alarm_death()
<1333239680.> [DEBUG]: Leaving init_signals()
<1333239680.> [DEBUG]: Entering init_config_dir()
<1333239680.> [DEBUG]: Leaving init_config_dir()
<1333239680.> [DEBUG]: Entering init_config_file()
<1333239680.> [DEBUG]: Leaving init_config_file()
<1333239680.> [DEBUG]: Entering init_lockfiles()
<1333239680.> [DEBUG]: Leaving init_lockfiles()
<1333239680.> [DEBUG]: Entering check_lockfile()
<1333239680.> [unknown]: --- Cop Starting [Version: Apache Traffic Server -
traffic_cop - 3.1.4-unstable - (build # 310 on Apr 1 2012 at 00:34:30)] ---
<1333239680.> [DEBUG]: Leaving check_lockfile()
<1333239680.> [DEBUG]: Leaving init()
<1333239680.> [DEBUG]: Entering check()
<1333239680.> [DEBUG]: Entering check_no_run()
<1333239680.> [DEBUG]: Entering transient_error(2, 500)
<1333239680.> [DEBUG]: Leaving transient_error(2, 500) --> false
<1333239680.> [DEBUG]: Leaving check_no_run() --> 0
<1333239680.> [DEBUG]: Entering read_config()
<1333239680.> [DEBUG]: Entering build_config_table(33932704)
<1333239680.> [DEBUG]: Leaving build_config_table(33932704)
<1333239680.> [DEBUG]: Entering process_syslog_config()
<1333239680.> [DEBUG]: Leaving process_syslog_config()
<1333239680.> [DEBUG]: Leaving read_config()
<1333239680.> [DEBUG]: Entering check_programs()
<1333239680.> [DEBUG]: Entering heartbeat_manager()
<1333239680.> [WARNING]: (cli test) unable to retrieve manager_binary
<1333239680.> [WARNING]: manager heartbeat [variable] failed [1]
<1333239680.> [DEBUG]: Leaving heartbeat_manager() --> -1
<1333239680.> [DEBUG]: Entering check_memory()
<1333239680.> [DEBUG]: Leaving check_memory()
<1333239680.> [DEBUG]: Entering millisleep(1)
<1333239680.> [DEBUG]: Leaving millisleep(1)
<1333239680.> [DEBUG]: Entering check_no_run()
<1333239680.> [DEBUG]: Entering transient_error(2, 500)
<1333239680.> [DEBUG]: Leaving transient_error(2, 500) --> false
<1333239680.> [DEBUG]: Leaving check_no_run() --> 0
<1333239680.> [DEBUG]: Entering read_config()
<1333239680.> [DEBUG]: Entering check_programs()
<1333239680.> [DEBUG]: Entering heartbeat_manager()
<1333239680.> [DEBUG]: Entering milliseconds()
<1333239680.> [DEBUG]: Leaving milliseconds()
<1333239680.> [DEBUG]: Entering open_socket(8088, (null), (null))
<1333239680.> [DEBUG]: Entering transient_error(115, 500)
<1333239680.> [DEBUG]: Leaving transient_error(115, 500) --> false
<1333239680.> [DEBUG]: Leaving open_socket(8088, 127.0.0.1, (null)) --> 8
<1333239680.> [DEBUG]: Entering milliseconds()
<1333239680.> [DEBUG]: Leaving milliseconds()
<1333239680.> [DEBUG]: Entering milliseconds()
<1333239680.> [DEBUG]: Leaving milliseconds()
<1333239680.> [DEBUG]: Entering milliseconds()
<1333239680.> [DEBUG]: Leaving milliseconds()
<1333239680.> [WARNING]: (manager test) bad response value
<1333239680.> [WARNING]: manager heartbeat [variable] failed [2]
<1333239680.> [WARNING]: killing manager
<1333239680.> [DEBUG]: Entering
safe_kill(/var/run/trafficserver/manager.lock, traffic_manager, 1)
<1333239680.> [DEBUG]: Entering set_alarm_warn()
<1333239680.> [DEBUG]: Leaving set_alarm_warn()
<1333239680.> [DEBUG]: Entering set_alarm_death()
<1333239680.> [DEBUG]: Leaving set_alarm_death()
<1333239680.> [DEBUG]: Leaving
safe_kill(/var/run/trafficserver/manager.lock, traffic_manager, 1)
<1333239680.> [DEBUG]: Leaving heartbeat_manager() --> -1
<1333239680.> [DEBUG]: Entering check_memory()
<1333239680.> [DEBUG]: Leaving check_memory()
<1333239680.> [DEBUG]: Entering millisleep(1)
<1333239680.> [DEBUG]: Leaving millisleep(1)
<1333239680.> [DEBUG]: Entering check_no_run()
<1333239680.> [DEBUG]: Entering transient_error(2, 500)
<1333239680.> [DEBUG]: Leaving transient_error(2, 500) --> false
<1333239680.> [DEBUG]: Leaving check_no_run() --> 0
<1333239680.> [DEBUG]: Entering read_config()
<1333239680.> [DEBUG]: Entering check_programs()
<1333239680.> [WARNING]: traffic_manager not running, making sure
traffic_server is dead
<1333239680.> [DEBUG]: Entering
safe_kill(/var/run/
[jira] [Created] (TS-1171) Crash report: http_ui cache lookup, double free
Crash report: http_ui cache lookup, double free
---
Key: TS-1171
URL: https://issues.apache.org/jira/browse/TS-1171
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.4
Reporter: Zhao Yongming
{code}
*** glibc detected *** /opt/ats/bin/traffic_server: double free or corruption
(!prev): 0x013e9a50 ***
=== Backtrace: =
/lib64/libc.so.6(+0x77856)[0x2b14ef973856]
/lib64/libc.so.6(cfree+0x6c)[0x2b14ef97774c]
/opt/ats/bin/traffic_server(ShowCache::~ShowCache()+0x20)[0x6428c0]
/opt/ats/bin/traffic_server(ShowCont::done(int, int, void*)+0x23)[0x5e1c63]
/opt/ats/bin/traffic_server(ShowCache::handleCacheEvent(int,
Event*)+0x15d7)[0x641ee7]
/opt/ats/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*,
CacheFragType, char*, int)+0x42c)[0x64e62c]
/opt/ats/bin/traffic_server(ShowCache::lookup_url(int, Event*)+0x1a5)[0x63f655]
/opt/ats/bin/traffic_server(EThread::process_event(Event*, int)+0x90)[0x6a6350]
/opt/ats/bin/traffic_server(EThread::execute()+0x31b)[0x6a6c3b]
/opt/ats/bin/traffic_server[0x6a5142]
/lib64/libpthread.so.0(+0x8e2c)[0x2b14ed0f5e2c]
/lib64/libc.so.6(clone+0x6d)[0x2b14ef9d63cd]
{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] [Created] (TS-1161) insafe raw device in storage.config
insafe raw device in storage.config --- Key: TS-1161 URL: https://issues.apache.org/jira/browse/TS-1161 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Zhao Yongming if you system is on /dev/sda and you put /dev/sda into storage.config, TS will destroy the data on /dev/sda without any hesitate. this is proved to be true, please do not try, trust me. -- 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-1154) quick_filter on HEAD does not work
quick_filter on HEAD does not work -- Key: TS-1154 URL: https://issues.apache.org/jira/browse/TS-1154 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Zhao Yongming Assignee: weijin we take quick filter as a good solution for some security concern, but when I set it to 0x0733, it does not allow HEAD in, but setting as 0x0723 does that. Weijin have the patch in our tree: https://gitorious.org/trafficserver/taobao/commit/cb23b87d167da4074e047fabc94786003ee94e9a/diffs/db7d0e5be69988b531e8d1e4eea717e6d46df5cd I will commit if no one complain in 2 days. -- 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-1151) in some strange situation, cop will crash
in some strange situation, cop will crash
-
Key: TS-1151
URL: https://issues.apache.org/jira/browse/TS-1151
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: Zhao Yongming
we get some strange crash, the manager & cop may die, we are not sure what that
is, but I'd like to start one Issue here if we have other same issue.
here is the log in /var/log/messages
{code}
Mar 19 10:11:06 cache162.cn77 kernel:: [2510081.212455] [ET_NET 3][319]:
segfault at 2aaae6e986bc ip 003f7f27bdbe sp 40be2188 error 4 in
libc-2.5.so[3f7f20+14d000]
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:
(last system error 104: Connection reset by peer)
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:
(last system error 32: Broken pipe)
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: cop received child status
signal [305 2816]
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: traffic_manager not running,
making sure traffic_server is dead
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: spawning traffic_manager
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: --- Manager Starting
---
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: Manager Version:
Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar 9 2012
at 09:55:44)
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: {0x7f8ae2f48720} STATUS:
opened /var/log/trafficserver/manager.log
Mar 19 10:11:23 cache162.cn77 traffic_cop[303]: (cli test) unable to retrieve
manager_binary
Mar 19 10:11:39 cache162.cn77 traffic_server[1260]: NOTE: --- Server Starting
---
Mar 19 10:11:39 cache162.cn77 traffic_server[1260]: NOTE: Server Version:
Apache Traffic Server - traffic_server - 3.0.2 - (build # 299 on Mar 9 2012 at
09:56:00)
Mar 19 10:11:46 cache162.cn77 traffic_server[1260]: {0x2ad4afd3d970} STATUS:
opened /var/log/trafficserver/diags.log
Mar 19 10:15:06 cache162.cn77 kernel:: [2510320.713808] [ET_NET 3][1277]:
segfault at 2aab1cfa6a03 ip 003f7f27bdbe sp 4141c188 error 4 in
libc-2.5.so[3f7f20+14d000]
Mar 19 10:15:06 cache162.cn77 traffic_manager[1227]: {0x7f8ae2f48720} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 11:
Segmentation fault
Mar 19 10:15:06 cache162.cn77 traffic_manager[1227]: {0x7f8ae2f48720} ERROR:
(last system error 2: No such file or directory)
Mar 19 10:15:06 cache162.cn77 traffic_manager[1227]: {0x7f8ae2f48720} ERROR:
[Alarms::signalAlarm] Server Process was reset
Mar 19 10:15:06 cache162.cn77 traffic_manager[1227]: {0x7f8ae2f48720} ERROR:
(last system error 2: No such file or directory)
Mar 19 10:15:08 cache162.cn77 traffic_server[2412]: NOTE: --- Server Starting
---
Mar 19 10:15:08 cache162.cn77 traffic_server[2412]: NOTE: Server Version:
Apache Traffic Server - traffic_server - 3.0.2 - (build # 299 on Mar 9 2012 at
09:56:00)
Mar 19 10:15:08 cache162.cn77 traffic_server[2412]: {0x2af4c2ad5970} STATUS:
opened /var/log/trafficserver/diags.log
Mar 19 10:54:53 cache162.cn77 ops.hdmon.power: [ OK ] Power Unit PSU 1:
OK;Power Unit PSU 2: OK.
{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] [Created] (TS-1142) we need to record ram hit in ram cache hit
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] [Created] (TS-1130) ink_time_t is 64bit on x86_64
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 Reporter: Zhao Yongming Assignee: weijin Fix For: 3.1.3 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] [Created] (TS-1128) gcc don't like break strict-aliasing in I_ProxyAllocator.h
gcc don't like break strict-aliasing in I_ProxyAllocator.h
--
Key: TS-1128
URL: https://issues.apache.org/jira/browse/TS-1128
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Affects Versions: 3.1.4
Reporter: Zhao Yongming
Priority: Minor
{code}
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* SSLNetAccept::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* UnixNetProcessor::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* SSLNetProcessor::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* NetAccept::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
make[2]: *** [SSLUnixNet.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [UnixNetProcessor.o] Error 1
mv -f .deps/NetVConnection.Tpo .deps/NetVConnection.Po
mv -f .deps/Net.Tpo .deps/Net.Po
mv -f .deps/UDPIOEvent.Tpo .deps/UDPIOEvent.Po
make[2]: *** [UnixNetAccept.o] Error 1
mv -f .deps/Connection.Tpo .deps/Connection.Po
mv -f .deps/SSLCertLookup.Tpo .deps/SSLCertLookup.Po
mv -f .deps/UnixConnection.Tpo .deps/UnixConnection.Po
mv -f .deps/SSLConfig.Tpo .deps/SSLConfig.Po
mv -f .deps/SSLNet.Tpo .deps/SSLNet.Po
mv -f .deps/UnixNet.Tpo .deps/UnixNet.Po
mv -f .deps/UnixNetPages.Tpo .deps/UnixNetPages.Po
mv -f .deps/Socks.Tpo .deps/Socks.Po
mv -f .deps/SSLNetVConnection.Tpo .deps/SSLNetVConnection.Po
mv -f .deps/UnixNetVConnection.Tpo .deps/UnixNetVConnection.Po
make[2]: Leaving directory `/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore/net'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.VFqSxi (%build)
{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] [Created] (TS-1114) Crash report: HttpTransactCache::SelectFromAlternates
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
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] [Created] (TS-1112) traffic_cop may crash at free()
traffic_cop may crash at free() --- Key: TS-1112 URL: https://issues.apache.org/jira/browse/TS-1112 Project: Traffic Server Issue Type: Bug Environment: v3.0.x Reporter: Zhao Yongming Assignee: weijin traffic_cop may crash, at memory free, that will leave the manager & server alone, or may die with the manager too, leave a system without service. -- 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-1111) crash in RangeTransform::handle_event
crash in RangeTransform::handle_event
-
Key: TS-
URL: https://issues.apache.org/jira/browse/TS-
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: weijin
we have some crashing in range requesting processing, it is on our own tree
based on 3.0.x, that maybe the root cause of the do_io_close issue, we are
still look at how to fix that, feedback is welcome
{code}
#0 0x004dc624 in RangeTransform::handle_event (this=0x2aaed0001fb0,
event=1, edata=) at Transform.cc:926
926 Debug("transform_range", "RangeTransform destroy: %d",
m_output_vio ? m_output_vio->ndone : 0);
(gdb) bt
#0 0x004dc624 in RangeTransform::handle_event (this=0x2aaed0001fb0,
event=1, edata=) at Transform.cc:926
#1 0x0069145f in EThread::process_event (this=0x2b332010,
e=0x591d410, calling_code=1) at I_Continuation.h:146
#2 0x00691b8b in EThread::execute (this=0x2b332010) at
UnixEThread.cc:218
#3 0x0069092e in spawn_thread_internal (a=0x440bfa0) at Thread.cc:88
#4 0x00359fe0673d in pthread_create@@GLIBC_2.2.5 () from
/lib64/libpthread.so.0
#5 0x in ?? ()
(gdb) p m_output_vio
$1 = (VIO *) 0x2aaed0029fe8
(gdb) p *m_output_vio
Cannot access memory at address 0x2aaed0029fe8
{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] [Created] (TS-1109) stack dump may crash too
stack dump may crash too Key: TS-1109 URL: https://issues.apache.org/jira/browse/TS-1109 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.2 Reporter: Zhao Yongming Assignee: weijin the codes doing stack dump may crash, in this case you will not able to get a core file, that will hide most of the rare issues. -- 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-1069) better handle of the gziped content
better handle of the gziped content --- Key: TS-1069 URL: https://issues.apache.org/jira/browse/TS-1069 Project: Traffic Server Issue Type: Sub-task Reporter: Zhao Yongming -- 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-1068) we should not wait all the prefetch clients finish
we should not wait all the prefetch clients finish -- Key: TS-1068 URL: https://issues.apache.org/jira/browse/TS-1068 Project: Traffic Server Issue Type: Sub-task Reporter: Zhao Yongming -- 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-1064) logging format update
logging format update - Key: TS-1064 URL: https://issues.apache.org/jira/browse/TS-1064 Project: Traffic Server Issue Type: Task Components: Documentation Reporter: Zhao Yongming Assignee: Zhao Yongming Priority: Trivial % is not documented so far, we should make sure all those hiding items documented. -- 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-1060) fail assert at CacheVC::handleReadDone
fail assert at CacheVC::handleReadDone
--
Key: TS-1060
URL: https://issues.apache.org/jira/browse/TS-1060
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 3.0.1
Environment: v3.0.x, with some patch from taobao
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.0.2
{code}
#0 0x003f96032a45 in raise () from /lib64/libc.so.6
#1 0x003f96034225 in abort () from /lib64/libc.so.6
#2 0x2b0dea6f6394 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b0dea6f6466 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1,
message_format=0x2b0deb9ed240 "Cache.cc:1959: failed assert `((Doc *)
buf->data())->magic == DOC_MAGIC`", ap=0x2b0deb9ed140) at ink_error.cc:65
#4 0x2b0dea6f6531 in ink_fatal (return_code=1,
message_format=0x2b0deb9ed240 "Cache.cc:1959: failed assert `((Doc *)
buf->data())->magic == DOC_MAGIC`") at ink_error.cc:73
#5 0x2b0dea6f4ece in _ink_assert (a=0x773770 "((Doc *) buf->data())->magic
== DOC_MAGIC", f=0x7726be "Cache.cc", l=1959) at ink_assert.cc:44
#6 0x0069429a in CacheVC::handleReadDone (this=0x3d51710, event=3900,
e=0x0) at Cache.cc:1959
#7 0x004e02fa in Continuation::handleEvent (this=0x3d51710,
event=3900, data=0x0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x006b7715 in Cache::open_read (this=0x3aeaf00,
cont=0x2b0e20737fa8, key=0x2b0deb9ed9c0, request=0x2b0e207365d0,
params=0x2b0e20735e08,
type=CACHE_FRAG_TYPE_HTTP,
hostname=0x2b0e300458cb
"img01.taobaocdn.combao/uploaded/i1/T1701bXfdDXXaCZpA__104916.jpg_160x160.jpgimg01.taobaocdn.comhttp://img01.taobaocdn.com/bao/uploaded/i1/T1701bXfdDXXaCZpA__104916.jpg_160x160.jpg";,
host_len=19) at CacheRead.cc:231
#9 0x0069cfcf in Cache::open_read (this=0x3aeaf00,
cont=0x2b0e20737fa8, url=0x2b0e207365e8, request=0x2b0e207365d0,
params=0x2b0e20735e08,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1080
#10 0x0069a9f6 in CacheProcessor::open_read (this=0xf44d30,
cont=0x2b0e20737fa8, url=0x2b0e207365e8, request=0x2b0e207365d0,
params=0x2b0e20735e08,
pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3041
#11 0x0055937c in HttpCacheSM::do_cache_open_read (this=0x2b0e20737fa8)
at HttpCacheSM.cc:220
#12 0x005594cd in HttpCacheSM::open_read (this=0x2b0e20737fa8,
url=0x2b0e207365e8, hdr=0x2b0e207365d0, params=0x2b0e20735e08, pin_in_cache=0)
at HttpCacheSM.cc:252
#13 0x0057802d in HttpSM::do_cache_lookup_and_read
(this=0x2b0e20735d10) at HttpSM.cc:3911
#14 0x005808d6 in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6455
#15 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#16 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at
HttpSM.cc:1519
#17 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at
HttpSM.cc:502
#18 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6380
#19 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#20 0x00580391 in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6396
#21 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#22 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at
HttpSM.cc:1519
#23 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at
HttpSM.cc:502
#24 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6380
#25 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#26 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at
HttpSM.cc:1519
#27 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at
HttpSM.cc:502
#28 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6380
#29 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0x58f002
)
at HttpSM.cc:6346
#30 0x0056d45a in HttpSM::state_read_client_request_header
(this=0x2b0e20735d10, event=100, data=0x2b0e440157c8) at HttpSM.cc:783
#31 0x0056caf5 in HttpSM::setup_client_read_request_header
(this=0x2b0e20735d10) at HttpSM.cc:645
#32 0x0056f74c in HttpSM::handle_api_return (this=0x2b0e20735d10) at
HttpSM.cc:1495
#33 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at
HttpSM.cc:502
#34 0x0056c32c in HttpSM::state_add_to_list (this=0x2b0e20735d10,
event=0, data=0x0) at HttpSM.cc:530
#35 0x0056ca1f in HttpSM::attach_client_session (this=0x2b0e20735d10,
client_vc=0x2b0e1c0112c0, buffer_reader=0x2b0e1c0193d8) at HttpSM.cc:632
#36
[jira] [Created] (TS-1034) reduce futex locking period
reduce futex locking period
---
Key: TS-1034
URL: https://issues.apache.org/jira/browse/TS-1034
Project: Traffic Server
Issue Type: Improvement
Components: Core, HTTP
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Zhao Yongming
we need to reduce futex locking period, here is a simple testing in my 24cores
HP380 system, with 24 ab:
{codes}
#!/bin/sh
for i in {1..24}
do
ab -n 1 -c 16 -X 127.0.0.$i:8080
http://img02.taobaocdn.com/tps/i2/T1o0ypXk4w-1000-40.png?$i &
done
{codes}
result:
{codes}
Every 2.0s: echo show:proxy-stats | traffic_shell
Mon Nov 28 16:06:42 2011
Successfully Initialized MgmtAPI in /var/run/trafficserver
Document Hit Rate 100.00 % *
Bandwidth Saving - 100.00 % *
Cache Percent Free --- 99.999619 %
Open Server Connections -- 0
Open Client Connections -- 9
Open Cache Connections --- 2
Client Throughput 6824.747070 MBit/Sec
Transaction Per Second --- 53914.925781
* Value represents 10 second average.
[r...@hp380g7test.sqa.cm4 ~]# strace -c -p 11712
Process 11712 attached - interrupt to quit
^CProcess 11712 detached
% time seconds usecs/call callserrors syscall
-- --- --- - -
26.850.890335 15 58920 writev
24.450.810866 7118147 epoll_ctl
22.270.738451 13 58920 close
11.500.381362 6 59227 getsockname
9.860.326843 3119192 59228 read
3.530.117058 16 7100 1931 futex
1.530.050884 58 884 epoll_wait
0.000.37 0 404 rt_sigprocmask
0.000.00 0 3 write
0.000.00 0 2 brk
0.000.00 010 msync
-- --- --- - -
100.003.315836422809 61159 total
[r...@hp380g7test.sqa.cm4 ~]#
{codes}
--
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-1031) reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions
reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions --- Key: TS-1031 URL: https://issues.apache.org/jira/browse/TS-1031 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.1.1 Reporter: Zhao Yongming Assignee: weijin Priority: Minor reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions. put your patch here for review :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] [Created] (TS-1030) hash collation in hdrtoken_hash
hash collation in hdrtoken_hash --- Key: TS-1030 URL: https://issues.apache.org/jira/browse/TS-1030 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.1, 3.1.2 Reporter: Zhao Yongming Priority: Critical we have find out a 3 characters collation: SPX == PUT that will crash TS, we need to take more care of those hash, or bad guys may put some magic headers and crash all TS in your production, that is the most powerful DOS -- 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-1029) DNS crash if we free the memory into system
DNS crash if we free the memory into system
---
Key: TS-1029
URL: https://issues.apache.org/jira/browse/TS-1029
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.1.2
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.2
when we start to testing free memory into system, the DNS will cause crashing
at:
dns_result()
{codes}
if (!e->post(h, ent)) {
for (int i = 0; i < MAX_DNS_RETRIES; i++) {
if (e->id[i] < 0)
break;
h->release_query_id(e->id[i]);
}
return;
}
{codes}
--
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-1006) memory management, cut down memory waste ?
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.3
when we review the memory usage in the production, there is something abnormal,
ie, looks like TS take much memory than index data + common system waste, and
here is some memory dump result by set "proxy.config.dump_mem_info_frequency"
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 | memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 | memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 | memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 | memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 | memory/ioBufAllocator[5]
1048576 | 14336 | 2048 | memory/ioBufAllocator[4]
131072 | 0 | 1024 | memory/ioBufAllocator[3]
65536 | 0 |512 | memory/ioBufAllocator[2]
32768 | 0 |256 | memory/ioBufAllocator[1]
16384 | 0 |128 | memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 | memory/INKVConnAllocator
0 | 0 | 96 | memory/INKContAllocator
4096 | 0 | 32 | memory/apiHookAllocator
0 | 0 |288 | memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 | memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 | memory/RemapPluginsAlloc
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |128 |
memory/CongestionDBContAllocator
5767168 | 704512 | 2048 | memory/hdrStrHeap
18350080 |1153024 | 2048 | memory/hdrHeap
53248 | 2912 |208 |
memory/httpCacheAltAllocator
0 | 0 |112 |
memory/OneWayTunnelAllocator
157696 | 1232 | 1232 |
memory/hostDBContAllocator
102240 | 17040 | 17040 | memory/dnsBufAllocator
323584 | 0 | 1264 | memory/dnsEntryAllocator
0 | 0 | 16 |
memory/DNSRequestDataAllocator
0 | 0 | 1072 | memory/SRVAllocator
0 | 0 | 48 |
memory/ClusterVConnectionCache::Entry
0 |
[jira] [Created] (TS-1003) prefetch: the config file
prefetch: the config file - Key: TS-1003 URL: https://issues.apache.org/jira/browse/TS-1003 Project: Traffic Server Issue Type: Sub-task Reporter: Zhao Yongming Assignee: Zhao Yongming -- 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-994) X-Forwarded-For should follow the squid way
X-Forwarded-For should follow the squid way --- Key: TS-994 URL: https://issues.apache.org/jira/browse/TS-994 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.1 Reporter: Zhao Yongming Assignee: Zhao Yongming Priority: Minor Fix For: 3.1.1 Attachments: XFF.patch TS will append the IP in the format of: X-Forwarded-For: 127.0.0.1, 10.32.102.41\r\n while http://en.wikipedia.org/wiki/X-Forwarded-For says: X-Forwarded-For: client1, proxy1, proxy2 there is 2 spaces -- 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-984) LogFile::roll crash at Machine::instance
LogFile::roll crash at Machine::instance
Key: TS-984
URL: https://issues.apache.org/jira/browse/TS-984
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.1.0
Reporter: Zhao Yongming
Assignee: Alan M. Carroll
Fix For: 3.1.1
this is a strange error when I testing the current trunk with logging colation
server enabled:
{code}
[Oct 16 01:24:48.643] Server {0x2b4967f51760} WARNING: File
/var/log/trafficserver/ex_squid.log will be rolled because a LogObject with
different format is requesting the same filename
FATAL: Machine.cc:37: failed assert `_instance || !"Machine instance accessed
before initialization"`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0xc5)[0x2b49651a5109]
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0xa3)[0x2b49651a51bb]
/usr/lib64/trafficserver/libtsutil.so.3(_ink_assert+0xc2)[0x2b49651a3aee]
/usr/bin/traffic_server(Machine::instance()+0x24)[0x634a04]
/usr/bin/traffic_server(LogFile::roll(long, long)+0x230)[0x5f8138]
/usr/bin/traffic_server(LogObjectManager::_solve_filename_conflicts(LogObject*,
int)+0x489)[0x603263]
/usr/bin/traffic_server(LogObjectManager::_manage_object(LogObject*, bool,
int)+0x126)[0x6029ea]
/usr/bin/traffic_server(LogObjectManager::manage_object(LogObject*,
int)+0x2d)[0x5e9e27]
/usr/bin/traffic_server(LogConfig::read_xml_log_config(int)+0x3189)[0x5f28c9]
/usr/bin/traffic_server(LogConfig::setup_log_objects()+0x229)[0x5edd63]
/usr/bin/traffic_server(LogConfig::init(LogConfig*)+0x254)[0x5ec3ea]
/usr/bin/traffic_server(Log::init(int)+0x30c)[0x5e8134]
/usr/bin/traffic_server(main+0xb6a)[0x5161a4]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x2b49673b4ebd]
/usr/bin/traffic_server[0x4cc789]
{code}
there is two problem here:
1, why the machine is not initialized?
2, what does "WARNING: File /var/log/trafficserver/ex_squid.log will be rolled
because a LogObject with different format is requesting the same filename"
mean? is that harm?
--
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-983) prefetch: the documents
prefetch: the documents --- Key: TS-983 URL: https://issues.apache.org/jira/browse/TS-983 Project: Traffic Server Issue Type: Sub-task Reporter: Zhao Yongming Assignee: Zhao Yongming -- 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-977) RecCore usage cleanup
RecCore usage cleanup
-
Key: TS-977
URL: https://issues.apache.org/jira/browse/TS-977
Project: Traffic Server
Issue Type: Task
Components: Cleanup
Affects Versions: 3.1.2
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Minor
in RecCore.*
{code}
int RecGetRecordInt(const char *name, RecInt * rec_int, bool lock = true);
//-
// RecGetRecordXXX
//-
int
RecGetRecordInt(const char *name, RecInt *rec_int, bool lock)
{
int err;
RecData data;
if ((err = RecGetRecord_Xmalloc(name, RECD_INT, &data, lock)) == REC_ERR_OKAY)
*rec_int = data.rec_int;
return err;
}
{code}
and there is something heavy used:
{code}
//-
// Backwards Compatibility Items (REC_ prefix)
//-
#define REC_ReadConfigInt32(_var,_config_var_name) do { \
RecInt tmp = 0; \
RecGetRecordInt(_config_var_name, (RecInt*) &tmp); \
_var = (int32_t)tmp; \
} while (0)
#define REC_ReadConfigInteger(_var,_config_var_name) do { \
RecInt tmp = 0; \
RecGetRecordInt(_config_var_name, &tmp); \
_var = tmp; \
} while (0)
{code}
and a real case, the REC_ReadConfigInteger is renamed to
IOCORE_ReadConfigInteger:
{code}
RecInt cache_config_threads_per_disk = 12;
#define IOCORE_ReadConfigIntegerREC_ReadConfigInteger
IOCORE_ReadConfigInteger(cache_config_threads_per_disk,
"proxy.config.cache.threads_per_disk");
{code}
my question is, why it is so complex in all these renaming? why not just:
{code}
RecGetRecordInt("proxy.config.cache.threads_per_disk",
&cache_config_threads_per_disk);
{code}
brief talk with Leif, we may need to cleanup the use of REC_*. make it a small
task here
--
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
