[jira] [Commented] (TS-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107719#comment-13107719
]
mohan_zl commented on TS-947:
-
One question:
The variable sleep_wait in struct AIOThreadInfo is not used now, why not nuke
it away or use it for Jplevyak's patch, looks like:
timespec ten_msec_timespec = ink_based_hrtime_to_timespec(ink_get_hrtime() +
HRTIME_MSECONDS(thr_info-sleep_wait));
AIO Race condition on non NT systems
Key: TS-947
URL: https://issues.apache.org/jira/browse/TS-947
Project: Traffic Server
Issue Type: Bug
Components: Core
Environment: stock build with static libts, running on a 4 core server
Reporter: B Wyatt
Fix For: 3.1.1
Attachments: lock-safe-AIO.patch
Refer to code below. The timeslice starting when a consumer thread
determines that the temp_list is empty (A) and ending when it releases the
aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
and as a result request producers enqueue items on the temporary atomic list
(D). As a consumer in this state will wait for a signal on aio_cond to
proceed before processing the temp_list again, any requests on the temp_list
are effectively stalled until a future request produces this signal or
manually processes the temp_list.
In the case of cache volume initialization, there is no future request and
the initialization sequence soft locks.
{code:title=iocore/aio/AIO.cc(annotated)}
void *
aio_thread_main(void *arg)
{
...
ink_mutex_acquire(my_aio_req-aio_mutex);
for (;;) {
do {
current_req = my_aio_req;
/* check if any pending requests on the atomic list */
A if (!INK_ATOMICLIST_EMPTY(my_aio_req-aio_temp_list))
aio_move(my_aio_req);
if (!(op = my_aio_req-aio_todo.pop()) !(op =
my_aio_req-http_aio_todo.pop()))
Bbreak;
...
service request
...
} while (1);
Cink_cond_wait(my_aio_req-aio_cond, my_aio_req-aio_mutex);
}
...
}
static void
aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
{
...
if (!ink_mutex_try_acquire(req-aio_mutex)) {
Dink_atomiclist_push(req-aio_temp_list, op);
} else {
/* check if any pending requests on the atomic list */
if (!INK_ATOMICLIST_EMPTY(req-aio_temp_list))
aio_move(req);
/* now put the new request */
aio_insert(op, req);
ink_cond_signal(req-aio_cond);
ink_mutex_release(req-aio_mutex);
}
...
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-880) Major performance problem with second request on same keep-alive connection
[ https://issues.apache.org/jira/browse/TS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-880: Attachment: performance_2nd_req_another_version.patch Thank you William for your work, we tested your first diff file, and found ts will crash, so we write another patch. Major performance problem with second request on same keep-alive connection --- Key: TS-880 URL: https://issues.apache.org/jira/browse/TS-880 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.0, 2.1.4 Environment: 32-bit TS on linux, using epoll. With proxy.config.http.keep_alive_enabled_out = 1 Reporter: William Bardwell Assignee: William Bardwell Fix For: 3.1.1 Attachments: performance.try3.diff, performance_2nd_req.diff, performance_2nd_req_another_version.patch, performance_2nd_req_try2.diff If I load the same URL through TS twice in a row to a server with keep-alives turned on I get really slow performance on the second request. E.g. (loading 212M over loopback with uncachable content, but results are similar with cachable content): % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 212M 100 212M0 0 140M 0 0:00:01 0:00:01 --:--:-- 142M* % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 212M 100 212M0 0 6397k 0 0:00:34 0:00:34 --:--:-- 6400k* If I turn off proxy.config.http.keep_alive_enabled_out the problem goes away, it can also be partially solved by making proxy.config.io.max_buffer_size really big (but it needs to be bigger for larger content, and that supports the comment below, and proves that it isn't the origin server's fault.) When I turn on debug messages it looks like the IO loop for the second request only wakes up every 10ms (when an epoll_wait times out) and then it reads and writes, for the first request it goes much faster without those pauses. My theory is that the issue is related to the the fact that the outgoing connection fd gets added to the epoll fd for the thread handling the first request and the first user agent fd is added to the same epoll fd, and it stays on that epoll fd. But the new user agent request is on a different epoll fd which I assume means is tied to a different thread. -- 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
]
mohan_zl updated TS-844:
Attachment: TS-844-2.patch
@John Plevyak
This problem is hard to reproduce now, but i think the reason is because: when
a write has been closed normally, something wrong happens to create a invalid
HttpInfo, leading to fail ink_assert(w-alternate.valid()); in
CacheVC::openReadChooseWriter, and ts crash. In my patch, i just prevent this
happen, maybe the better way is like this, see TS-844-2.patch, or just remove
that ink_assert line, because follow it is a if condition judgment.
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
Assignee: Zhao Yongming
Fix For: 3.1.0
Attachments: TS-844-2.patch, 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
[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
]
mohan_zl updated TS-844:
Attachment: (was: TS-844-2.patch)
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
Assignee: Zhao Yongming
Fix For: 3.1.0
Attachments: TS-844-2.patch, 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
[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
]
mohan_zl updated TS-844:
Comment: was deleted
(was: @John Plevyak
This problem is hard to reproduce now, but i think the reason is because: when
a write has been closed normally, something wrong happens to create a invalid
HttpInfo, leading to fail ink_assert(w-alternate.valid()); in
CacheVC::openReadChooseWriter, and ts crash. In my patch, i just prevent this
happen, maybe the better way is like this, see TS-844-2.patch, or just remove
that ink_assert line, because follow it is a if condition judgment.)
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
Assignee: Zhao Yongming
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
[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
]
mohan_zl updated TS-844:
Attachment: (was: TS-844-2.patch)
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
Assignee: Zhao Yongming
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
[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
]
mohan_zl updated TS-844:
Attachment: (was: TS-844-2.patch)
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
Assignee: Zhao Yongming
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
[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
]
mohan_zl updated TS-844:
Attachment: TS-844-2.patch
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
Assignee: Zhao Yongming
Fix For: 3.1.0
Attachments: TS-844-2.patch, 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
[jira] [Updated] (TS-909) code cleanup for format
[ https://issues.apache.org/jira/browse/TS-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-909: Attachment: TS-format-fix_1.patch Fix the net format error code cleanup for format --- Key: TS-909 URL: https://issues.apache.org/jira/browse/TS-909 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Attachments: TS-format-fix_1.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-887) Code cleanup
Code cleanup Key: TS-887 URL: https://issues.apache.org/jira/browse/TS-887 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Try to nuke some unused codes, not changing current logic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-887) Code cleanup
[ https://issues.apache.org/jira/browse/TS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-887: Attachment: code_cleanup1.patch Correct the code format Code cleanup Key: TS-887 URL: https://issues.apache.org/jira/browse/TS-887 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Attachments: code_cleanup1.patch, code_cleanup2.patch Try to nuke some unused codes, not changing current logic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-887) Code cleanup
[ https://issues.apache.org/jira/browse/TS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-887: Attachment: code_cleanup2.patch I think the enum structure is not used, so nuke it. Code cleanup Key: TS-887 URL: https://issues.apache.org/jira/browse/TS-887 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Attachments: code_cleanup1.patch, code_cleanup2.patch Try to nuke some unused codes, not changing current logic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-887) Code cleanup
[ https://issues.apache.org/jira/browse/TS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-887: Attachment: code_cleanup3.patch I don't know why current codes is implemented like this, in linux, kernel 2.6.38, i think i can cut down the codes, not changing current logic. Code cleanup Key: TS-887 URL: https://issues.apache.org/jira/browse/TS-887 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Attachments: code_cleanup1.patch, code_cleanup2.patch, code_cleanup3.patch Try to nuke some unused codes, not changing current logic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-654: Attachment: hc.patch request for support of Layer7 http health checking for Origin Servers - Key: TS-654 URL: https://issues.apache.org/jira/browse/TS-654 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 2.1.5 Reporter: Zhao Yongming Assignee: mohan_zl Fix For: 3.1.1 Attachments: HCUtil.cc, hc.patch this ticket is for the L7 health checking project: https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-726) Crash Report: DNSEntry::post in 2.1.7
[
https://issues.apache.org/jira/browse/TS-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mohan_zl closed TS-726.
---
Resolution: Fixed
Never reproduce this problem, close and wait for another issue.
Crash Report: DNSEntry::post in 2.1.7
-
Key: TS-726
URL: https://issues.apache.org/jira/browse/TS-726
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 2.1.7
Environment: 2.1.7
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.1.0
reported from user, for tracking.
{code:none}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/ts/bin/traffic_server - STACK TRACE:
[0x4001c420]
/usr/local/ts/bin/traffic_server(DNSEntry::post(DNSHandler*, HostEnt*,
bool)+0x5d5)[0x82503e5]
[0x0]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x1ff)[0x8320e9f]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x4be)[0x83216be]
/usr/local/ts/bin/traffic_server(main+0x1245)[0x8104505]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0x4050]
/usr/local/ts/bin/traffic_server[0x80bdec1]
/usr/local/ts/bin/traffic_server[0x80bdec1]
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-801) Crash Report: enable update will triger Segmentation fault
[
https://issues.apache.org/jira/browse/TS-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mohan_zl updated TS-801:
Fix Version/s: (was: 3.1.0)
3.1.1
Crash Report: enable update will triger Segmentation fault
--
Key: TS-801
URL: https://issues.apache.org/jira/browse/TS-801
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 2.1.8
Environment: v2.1.8 and update function enabled.
Reporter: Zhao Yongming
Labels: update
Fix For: 3.1.1
{code}
b13621367...@hotmail.com: NOTE: Traffic Server received Sig 11: Segmentation
fault
/usr/local/ts/bin/traffic_server - STACK TRACE:
b13621367...@hotmail.com:
/usr/local/ts/bin/traffic_server[0x5260c9]
/lib64/libpthread.so.0[0x3088e0f4c0]
[0x6e]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x6e)[0x57e0e2]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x18b)[0x57e369]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x56d9aa]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x13b13621367...@hotmail.com:
8)[0x56d9aa]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x36)[0x5b5cb0]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::state_add_to_list(int,
void*)+0x2aa)[0x56a51c]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x2cb)[0x570c13]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x6c)[0x4e0486]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::start_scheduled_update(Continuation*,
HTTPHdr*)+0x168)[0x5b5c1c]
/usr/local/ts/bin/traffic_server(UpdateSM::http_scheme(UpdateSM*)+0x335)[0x53599f]
/usr/local/ts/bin/traffic_server(UpdateSM::HandleSMEvent(int,
Event*)+0x1ab)[0x535437]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x6c)[0x4e0486]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x12c)[0x6fa9dc]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x9b)[0x6fabef]
/usr/local/ts/bin/traffic_server[0x6f9b4c]
/lib64/libpthread.so.0[0x3088e077e1]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
[May 26 16:25:14.569] Manager {140030245394400} ERROR:
[LocalManager::-PollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[May 26 16:25:14.569] Manager {140030245394400} ERROR: (last system error
32: Broken pipe)
[[May 26 16:25:14.569] Manager {140030245394400} ERROR:
[Alarms::-SignalAlarm] Server Process was reset
[May 26 16:25:14.569] Manager {140030245394400} ERROR: (last system error
32: Broken pipe)
[May 26 16:25:15.577] Manager {140030245394400} NOTE:
[LocalManager::-StartProxy] Launching ts process
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-835) Crash Report: heartbeat_manager - test_mgmt_cli_port in traffic_cop
[
https://issues.apache.org/jira/browse/TS-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mohan_zl closed TS-835.
---
Resolution: Fixed
Not reproduce this problem again, now first close it and wait for another
report.
Crash Report: heartbeat_manager - test_mgmt_cli_port in traffic_cop
Key: TS-835
URL: https://issues.apache.org/jira/browse/TS-835
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.1.0
Environment: current trunk, v3.0 stable time
Reporter: Zhao Yongming
Labels: cop
Fix For: 3.1.0
bt #1
{code}
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
warning: Can't read pathname for load map: Input/output error.
warning: Can't read pathname for load map: Input/output error.
Core was generated by `/usr/bin/traffic_cop'.
Program terminated with signal 6, Aborted.
[New process 27092]
#0 0x003c33030265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x003c33030265 in raise () from /lib64/libc.so.6
#1 0x003c33031d10 in abort () from /lib64/libc.so.6
#2 0x003c3306a84b in __libc_message () from /lib64/libc.so.6
#3 0x003c330722ef in _int_free () from /lib64/libc.so.6
#4 0x003c3307273b in free () from /lib64/libc.so.6
#5 0x2b95bf2a2da7 in ink_free (ptr=Could not find the frame base for
ink_free.
) at ink_memory.cc:175
#6 0x2b95bf2a7251 in _xfree (mem=Could not find the frame base for
_xfree(void*).
) at ink_resource.cc:710
#7 0x2b95bf07b42b in _TSfree (ptr=Could not find the frame base for
_TSfree.
) at ../INKMgmtAPI.cc:88
#8 0x00403b17 in test_mgmt_cli_port () at TrafficCop.cc:1180
#9 0x00404fa7 in heartbeat_manager () at TrafficCop.cc:1265
#10 0x004052fb in check_programs () at TrafficCop.cc:1500
#11 0x00405879 in check (arg=0x0) at TrafficCop.cc:1670
#12 0x00405a87 in main (argc=1, argv=0x7fff8c071c88) at
TrafficCop.cc:1942
(gdb) info f
Stack level 0, frame at 0x7fff8c06ef00:
rip = 0x3c33030265 in raise; saved rip 0x3c33031d10
called by frame at 0x7fff8c06f040
Arglist at 0x7fff8c06eef0, args:
Locals at 0x7fff8c06eef0, Previous frame's sp is 0x7fff8c06ef00
Saved registers:
rip at 0x7fff8c06eef8
{code}
bt #2
{code}
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /lib64/libsepol.so.1...done.
Loaded symbols for /lib64/libsepol.so.1
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
warning: Can't read pathname for load map: Input/output error.
warning: Can't read pathname for load map: Input/output error.
Core was generated by `/usr/bin/traffic_cop'.
Program terminated with signal 6, Aborted.
[New process 26537]
#0 0x003f57e30265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x003f57e30265 in raise () from /lib64/libc.so.6
#1 0x003f57e31d10 in abort () from /lib64/libc.so.6
#2 0x003f57e6a84b in __libc_message () from /lib64/libc.so.6
#3 0x003f57e722ef in _int_free () from /lib64/libc.so.6
#4 0x003f57e7273b in free () from /lib64/libc.so.6
#5 0x2b682f2f8da7 in ink_free (ptr=Could not find the frame base for
ink_free.
) at ink_memory.cc:175
#6 0x2b682f2fd251 in _xfree (mem=Could not find the frame base for
_xfree(void*).
) at ink_resource.cc:710
#7 0x2b682f0d142b in _TSfree (ptr=Could not find the frame base for
_TSfree.
) at ../INKMgmtAPI.cc:88
#8 0x00403b17 in test_mgmt_cli_port () at TrafficCop.cc:1180
#9 0x00404fa7 in heartbeat_manager () at TrafficCop.cc:1265
#10 0x004052fb in check_programs () at TrafficCop.cc:1500
#11 0x00405879 in check (arg=0x0) at TrafficCop.cc:1670
#12 0x00405a87 in main (argc=1, argv=0x7fff396dede8) at
TrafficCop.cc:1942
(gdb) info f
Stack level 0, frame at 0x7fff396dc060:
rip = 0x3f57e30265 in raise; saved rip 0x3f57e31d10
called by frame at 0x7fff396dc1a0
Arglist at 0x7fff396dc050, args:
Locals at 0x7fff396dc050, Previous frame's sp is 0x7fff396dc060
Saved registers:
rip at 0x7fff396dc058
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (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
]
mohan_zl closed TS-851.
---
Resolution: Fixed
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
]
mohan_zl updated TS-857:
Fix Version/s: (was: 3.1.0)
3.1.1
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.1
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] [Resolved] (TS-874) asf-dist should be git nice
[ https://issues.apache.org/jira/browse/TS-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl resolved TS-874. - Resolution: Fixed fixed, and closed asf-dist should be git nice --- Key: TS-874 URL: https://issues.apache.org/jira/browse/TS-874 Project: Traffic Server Issue Type: Improvement Components: Build Affects Versions: 3.1.0 Reporter: Zhao Yongming Assignee: Zhao Yongming Priority: Trivial Fix For: 3.1.0 Attachments: TS-874.txt the asf-dist make target should be git nice, I think many of us on git. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-813) http_ui /stat/ should response with content type
[
https://issues.apache.org/jira/browse/TS-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mohan_zl updated TS-813:
Fix Version/s: (was: 3.1.0)
3.1.1
http_ui /stat/ should response with content type
Key: TS-813
URL: https://issues.apache.org/jira/browse/TS-813
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Affects Versions: 2.1.8
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Minor
Labels: http_ui
Fix For: 3.1.1
Attachments: TS-813.patch
when requesting /stat/
the header missing content type, and that will confusing browsers
{code}
HTTP/1.0 200 Ok^M
Date: Wed, 01 Jun 2011 02:34:02 GMT^M
Connection: close^M
Server: ATS/2.1.9-unstable^M
Content-Length: 54952^M
^M
pre
proxy.config.proxy_name=
{code}
the others should be checked too.
--
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
]
mohan_zl updated TS-849:
Fix Version/s: (was: 3.1.0)
3.1.1
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.1
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-796) Crash Report: mime_str_u16_set, possible
[
https://issues.apache.org/jira/browse/TS-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mohan_zl updated TS-796:
Fix Version/s: (was: 3.1.0)
3.1.1
Crash Report: mime_str_u16_set, possible
Key: TS-796
URL: https://issues.apache.org/jira/browse/TS-796
Project: Traffic Server
Issue Type: Bug
Affects Versions: 2.1.8
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.1.1
report from user, may need more detail
{code}
/usr/local/ts/bin/traffic_server(mime_str_u16_set(HdrHeap*, char const*,
unsigned short, char const**, unsigned short*,
bool)+0x5d)[0x821b16d]/usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*,
URLImpl*, char const*, int, bool)+0x51)[0x82251c1]
/usr/local/ts/bin/traffic_server(HTTPHdr::set_url_target_from_host_field(URL*)+0x84)[0x8215a74]
/usr/local/ts/bin/traffic_server(RemapProcessor::setup_for_remap(HttpTransact::State*)+0x272)[0x81c6132]
/usr/local/ts/bin/traffic_server(HttpSM::do_remap_request(bool)+0x3a)[0x816bf8a]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0xad3)[0x81855b3]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816903b]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x19f)[0x818278f]
/usr/local/ts/bin/traffic_server(HttpSM::state_api_callout(int,
void*)+0x340)[0x8178f60]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x160)[0x8184c40]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816903b]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x19f)[0x818278f]
/usr/local/ts/bin/traffic_server(HttpSM::state_api_callout(int,
void*)+0x340)[0x8178f60]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x160)[0x8184c40]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816903b]
/usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x31d)[0x817cf9d]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x1a4)[0x8181154]
/usr/local/ts/bin/traffic_server[0x82f6d4c]
/usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x515)[0x82eb295]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x1ff)[0x831fa9f]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x449)[0x8320249]
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-852) hostdb and dns system hangup
[
https://issues.apache.org/jira/browse/TS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mohan_zl closed TS-852.
---
Resolution: Fixed
This issue is covered by TS-833
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
Attachments: TS-852.patch
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
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-745: Attachment: TS-ssd-2.patch TS-ssd-2.patch correct the log stats, and add a proxy.config.cache.ram_cache.ssd_percent variable for ssd. For example, if user has 8G cache, and want ssd use 4G, just set this variable to 50. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1.1 Attachments: TS-ssd-2.patch, TS-ssd.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-873) Wrong code in iocore/net/UnixNet.cc
Wrong code in iocore/net/UnixNet.cc --- Key: TS-873 URL: https://issues.apache.org/jira/browse/TS-873 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl I think somebody write a wrong code in iocore/net/UnixNet.cc -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-869) The stat code for ram_cache miss is lost
The stat code for ram_cache miss is lost Key: TS-869 URL: https://issues.apache.org/jira/browse/TS-869 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Use echo show:cache-stats | traffic_shell, i found the Misses for RAM CACHE is always -1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-869) The stat code for ram_cache miss is lost
[ https://issues.apache.org/jira/browse/TS-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-869: Attachment: ram_cache_miss.patch The patch have fixed this problem. The stat code for ram_cache miss is lost Key: TS-869 URL: https://issues.apache.org/jira/browse/TS-869 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Attachments: ram_cache_miss.patch Use echo show:cache-stats | traffic_shell, i found the Misses for RAM CACHE is always -1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-870) Something wrong with the evacuate relevant codes in cache
Something wrong with the evacuate relevant codes in cache - Key: TS-870 URL: https://issues.apache.org/jira/browse/TS-870 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-870) Something wrong with the evacuate relevant codes in cache
[ https://issues.apache.org/jira/browse/TS-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060434#comment-13060434 ] mohan_zl commented on TS-870: - Try to fix this problem, the default behavior is not use the evacuate feature in cache. Something wrong with the evacuate relevant codes in cache - Key: TS-870 URL: https://issues.apache.org/jira/browse/TS-870 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Attachments: TS-evacuate-correct.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-869) The stat code for ram_cache miss is lost
[ https://issues.apache.org/jira/browse/TS-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060436#comment-13060436 ] mohan_zl commented on TS-869: - The attached patch fixes this problem. The stat code for ram_cache miss is lost Key: TS-869 URL: https://issues.apache.org/jira/browse/TS-869 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Attachments: ram_cache_miss.patch Use echo show:cache-stats | traffic_shell, i found the Misses for RAM CACHE is always -1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-869) The stat code for ram_cache miss is lost
[ https://issues.apache.org/jira/browse/TS-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-869: Comment: was deleted (was: The attached patch fixes this problem.) The stat code for ram_cache miss is lost Key: TS-869 URL: https://issues.apache.org/jira/browse/TS-869 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Attachments: ram_cache_miss.patch Use echo show:cache-stats | traffic_shell, i found the Misses for RAM CACHE is always -1. -- 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
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-745: Attachment: TS-ssd.patch Latest ssd patch. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1.0 Attachments: TS-ssd.patch, ssd_cache.patch, ssd_cache2.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-745: Attachment: TS-ssd.patch Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1.0 Attachments: TS-ssd.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-745: Attachment: (was: ssd_cache2.patch) Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1.0 Attachments: TS-ssd.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-745: Attachment: TS-ssd.patch Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1.0 Attachments: TS-ssd.patch A patch for supporting, not work well for a long time with --enable-debug -- 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
]
mohan_zl updated TS-844:
Attachment: TS-844.patch
Use TS-844.patch and test again, now no related problem coming.
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
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
[jira] [Commented] (TS-833) Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef, ink_freelist_free related
[
https://issues.apache.org/jira/browse/TS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052302#comment-13052302
]
mohan_zl commented on TS-833:
-
{code}
#0 0x0063f9f5 in get_dns (h=0x18ea3070, id=27816) at DNS.cc:752
752 if (e-once_written_flag)
(gdb) bt
#0 0x0063f9f5 in get_dns (h=0x18ea3070, id=27816) at DNS.cc:752
#1 0x00643e33 in dns_process (handler=0x18ea3070, buf=0x2aaab1292010,
len=159) at DNS.cc:1170
#2 0x00645cfc in DNSHandler::recv_dns (this=0x18ea3070, event=5,
e=0x18e7df50) at DNS.cc:690
#3 0x0064655f in DNSHandler::mainEvent (this=0x18ea3070, event=5,
e=0x18e7df50) at DNS.cc:703
#4 0x004d302f in Continuation::handleEvent (this=0x18ea3070, event=5,
data=0x18e7df50) at I_Continuation.h:146
#5 0x006f9978 in EThread::process_event (this=0x2ae29010,
e=0x18e7df50, calling_code=5) at UnixEThread.cc:140
#6 0x006f9e96 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:262
#7 0x004ff74d in main (argc=3, argv=0x7fff21439ac8) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff214382c0:
rip = 0x63f9f5 in get_dns (DNS.cc:752); saved rip 0x643e33
called by frame at 0x7fff214390a0
source language c++.
Arglist at 0x7fff214382b0, args: h=0x18ea3070, id=27816
Locals at 0x7fff214382b0, Previous frame's sp is 0x7fff214382c0
Saved registers:
rbp at 0x7fff214382b0, rip at 0x7fff214382b8
(gdb) info args
h = (DNSHandler *) 0x18ea3070
id = 27816
(gdb) p h
$1 = (DNSHandler *) 0x18ea3070
(gdb) p h-handler_name
$2 = 0x755f55 DNSHandler::mainEvent
{code}
Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef,
ink_freelist_free related
---
Key: TS-833
URL: https://issues.apache.org/jira/browse/TS-833
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0
Environment: current trunk, with --enable-debug
Reporter: Zhao Yongming
Labels: freelist
Fix For: 3.1.0
Attachments: TS-833-2.diff, TS-833-3.diff, TS-833.diff
bt #1
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x197c4fc0, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff76c41528) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff76c40e40:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff76c40eb0
source language c++.
Arglist at 0x7fff76c40e30, args: this=0x19581df0, event=2, data=0x197c4fc0
Locals at 0x7fff76c40e30, Previous frame's sp is 0x7fff76c40e40
Saved registers:
rbp at 0x7fff76c40e30, rip at 0x7fff76c40e38
(gdb) x/40x this
0x19581df0: 0x19581901 0x 0xefbeadde 0xefbeadde
0x19581e00: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e10: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e20: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e30: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e40: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e50: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e60: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e70: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e80: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
{code}
bt #2
{code}
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
#1 0x0070364c in EThread::process_event (this=0x2ae29010,
e=0xc4408a0, calling_code=2) at UnixEThread.cc:140
#2 0x0070398e in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x00502aac in main (argc=3, argv=0x7fff32ef2f58) at Main.cc:1961
(gdb) p *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of
bounds, mutex = {m_ptr =
[jira] [Commented] (TS-844) ReadFromWriter fail in CacheRead.cc
[
https://issues.apache.org/jira/browse/TS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051760#comment-13051760
]
mohan_zl commented on TS-844:
-
The enviroment is like this:
{quota}
[root@cache180 ~]# uname -a
Linux cache180.cn63 2.6.18-164.11.1.el5 #1 SMP Sun Mar 7 17:26:09 CST 2010
x86_64 x86_64 x86_64 GNU/Linux
{quota}
We use the latest trunk, plus the patch TS-833-3.diff which John submit in
TS-833, with enable debug info.
I think this problem occured when some illegal request came and TS try to
update it in cache, and fail. The hostname in gdb debug is a dirty data.
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
{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
[jira] [Commented] (TS-833) Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef, ink_freelist_free related
[
https://issues.apache.org/jira/browse/TS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051784#comment-13051784
]
mohan_zl commented on TS-833:
-
By the way, now we found an interesting problem, we use 20 machines for
testing, and each node use single mode. We found if the nodes have run for a
while, then some machine have a very very low qps, but not crash, and if one
node crashed, then when it restart, it can run well as before. I think maybe
this problem is not caused by cache, but the proxy or net module.
Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef,
ink_freelist_free related
---
Key: TS-833
URL: https://issues.apache.org/jira/browse/TS-833
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0
Environment: current trunk, with --enable-debug
Reporter: Zhao Yongming
Labels: freelist
Fix For: 3.1.0
Attachments: TS-833-2.diff, TS-833-3.diff, TS-833.diff
bt #1
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x197c4fc0, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff76c41528) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff76c40e40:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff76c40eb0
source language c++.
Arglist at 0x7fff76c40e30, args: this=0x19581df0, event=2, data=0x197c4fc0
Locals at 0x7fff76c40e30, Previous frame's sp is 0x7fff76c40e40
Saved registers:
rbp at 0x7fff76c40e30, rip at 0x7fff76c40e38
(gdb) x/40x this
0x19581df0: 0x19581901 0x 0xefbeadde 0xefbeadde
0x19581e00: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e10: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e20: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e30: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e40: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e50: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e60: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e70: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e80: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
{code}
bt #2
{code}
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
#1 0x0070364c in EThread::process_event (this=0x2ae29010,
e=0xc4408a0, calling_code=2) at UnixEThread.cc:140
#2 0x0070398e in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x00502aac in main (argc=3, argv=0x7fff32ef2f58) at Main.cc:1961
(gdb) p *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of
bounds, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {SLinkContinuation
= {
next = 0xefbeaddeefbeadde}, prev = 0xefbeaddeefbeadde}}
(gdb)
{code}
bt #3
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
event=2, data=0x2aaab00d1570) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
event=2, data=0x2aaab00d1570) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x2aaab00d1570, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff421f08d8) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff421f01f0:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff421f0260
source language c++.
Arglist at 0x7fff421f01e0, args: this=0x2aaab00615b0, event=2,
data=0x2aaab00d1570
Locals at
[jira] [Commented] (TS-833) Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef, ink_freelist_free related
[
https://issues.apache.org/jira/browse/TS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050836#comment-13050836
]
mohan_zl commented on TS-833:
-
@John yeah, i use TS-833-3.diff with the latest trunk.
Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef,
ink_freelist_free related
---
Key: TS-833
URL: https://issues.apache.org/jira/browse/TS-833
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0
Environment: current trunk, with --enable-debug
Reporter: Zhao Yongming
Labels: freelist
Attachments: TS-833-2.diff, TS-833-3.diff, TS-833.diff
bt #1
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x197c4fc0, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff76c41528) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff76c40e40:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff76c40eb0
source language c++.
Arglist at 0x7fff76c40e30, args: this=0x19581df0, event=2, data=0x197c4fc0
Locals at 0x7fff76c40e30, Previous frame's sp is 0x7fff76c40e40
Saved registers:
rbp at 0x7fff76c40e30, rip at 0x7fff76c40e38
(gdb) x/40x this
0x19581df0: 0x19581901 0x 0xefbeadde 0xefbeadde
0x19581e00: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e10: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e20: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e30: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e40: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e50: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e60: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e70: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e80: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
{code}
bt #2
{code}
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
#1 0x0070364c in EThread::process_event (this=0x2ae29010,
e=0xc4408a0, calling_code=2) at UnixEThread.cc:140
#2 0x0070398e in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x00502aac in main (argc=3, argv=0x7fff32ef2f58) at Main.cc:1961
(gdb) p *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of
bounds, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {SLinkContinuation
= {
next = 0xefbeaddeefbeadde}, prev = 0xefbeaddeefbeadde}}
(gdb)
{code}
bt #3
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
event=2, data=0x2aaab00d1570) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
event=2, data=0x2aaab00d1570) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x2aaab00d1570, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff421f08d8) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff421f01f0:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff421f0260
source language c++.
Arglist at 0x7fff421f01e0, args: this=0x2aaab00615b0, event=2,
data=0x2aaab00d1570
Locals at 0x7fff421f01e0, Previous frame's sp is 0x7fff421f01f0
Saved registers:
rbp at 0x7fff421f01e0, rip at 0x7fff421f01e8
(gdb) p this-handler
$1 = 0xefbeaddeefbeadde, this adjustment -1171307680053154338
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-833) Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef, ink_freelist_free related
[
https://issues.apache.org/jira/browse/TS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050861#comment-13050861
]
mohan_zl commented on TS-833:
-
@John, is there any possibilities that these problem is caused by some deep bug?
Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef,
ink_freelist_free related
---
Key: TS-833
URL: https://issues.apache.org/jira/browse/TS-833
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0
Environment: current trunk, with --enable-debug
Reporter: Zhao Yongming
Labels: freelist
Attachments: TS-833-2.diff, TS-833-3.diff, TS-833.diff
bt #1
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x197c4fc0, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff76c41528) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff76c40e40:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff76c40eb0
source language c++.
Arglist at 0x7fff76c40e30, args: this=0x19581df0, event=2, data=0x197c4fc0
Locals at 0x7fff76c40e30, Previous frame's sp is 0x7fff76c40e40
Saved registers:
rbp at 0x7fff76c40e30, rip at 0x7fff76c40e38
(gdb) x/40x this
0x19581df0: 0x19581901 0x 0xefbeadde 0xefbeadde
0x19581e00: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e10: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e20: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e30: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e40: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e50: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e60: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e70: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e80: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
{code}
bt #2
{code}
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
#1 0x0070364c in EThread::process_event (this=0x2ae29010,
e=0xc4408a0, calling_code=2) at UnixEThread.cc:140
#2 0x0070398e in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x00502aac in main (argc=3, argv=0x7fff32ef2f58) at Main.cc:1961
(gdb) p *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of
bounds, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {SLinkContinuation
= {
next = 0xefbeaddeefbeadde}, prev = 0xefbeaddeefbeadde}}
(gdb)
{code}
bt #3
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
event=2, data=0x2aaab00d1570) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
event=2, data=0x2aaab00d1570) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x2aaab00d1570, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff421f08d8) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff421f01f0:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff421f0260
source language c++.
Arglist at 0x7fff421f01e0, args: this=0x2aaab00615b0, event=2,
data=0x2aaab00d1570
Locals at 0x7fff421f01e0, Previous frame's sp is 0x7fff421f01f0
Saved registers:
rbp at 0x7fff421f01e0, rip at 0x7fff421f01e8
(gdb) p this-handler
$1 = 0xefbeaddeefbeadde, this adjustment -1171307680053154338
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
[jira] [Commented] (TS-833) Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef, ink_freelist_free related
[
https://issues.apache.org/jira/browse/TS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050173#comment-13050173
]
mohan_zl commented on TS-833:
-
{quote}
#0 0x004d2c5c in Continuation::handleEvent (this=0xda48180, event=2,
data=0xdb212d0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0xda48180, event=2,
data=0xdb212d0) at I_Continuation.h:146
#1 0x006f58c8 in EThread::process_event (this=0x2ae29010,
e=0xdb212d0, calling_code=2) at UnixEThread.cc:140
#2 0x006f5c0a in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff0e981f48) at Main.cc:1958
(gdb) x/40x this
0xda48180: 0x0da477a1 0x 0xefbeadde 0xefbeadde
0xda48190: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481a0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481b0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481c0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481d0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481e0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481f0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda48200: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda48210: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
(gdb) info f
Stack level 0, frame at 0x7fff0e981860:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f58c8
called by frame at 0x7fff0e9818d0
source language c++.
Arglist at 0x7fff0e981850, args: this=0xda48180, event=2, data=0xdb212d0
Locals at 0x7fff0e981850, Previous frame's sp is 0x7fff0e981860
Saved registers:
rbp at 0x7fff0e981850, rip at 0x7fff0e981858
(gdb) info args
this = (Continuation * const) 0xda48180
event = 2
data = (void *) 0xdb212d0
(gdb) p this-handler_name
$1 = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of bounds
(gdb) p *this
$2 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0xda477a1}, handler =
0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of bounds,
mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {SLinkContinuation = {
next = 0xefbeaddeefbeadde}, prev = 0xefbeaddeefbeadde}}
{quote}
Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef,
ink_freelist_free related
---
Key: TS-833
URL: https://issues.apache.org/jira/browse/TS-833
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0
Environment: current trunk, with --enable-debug
Reporter: Zhao Yongming
Labels: freelist
Attachments: TS-833-2.diff, TS-833-3.diff, TS-833.diff
bt #1
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x197c4fc0, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff76c41528) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff76c40e40:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff76c40eb0
source language c++.
Arglist at 0x7fff76c40e30, args: this=0x19581df0, event=2, data=0x197c4fc0
Locals at 0x7fff76c40e30, Previous frame's sp is 0x7fff76c40e40
Saved registers:
rbp at 0x7fff76c40e30, rip at 0x7fff76c40e38
(gdb) x/40x this
0x19581df0: 0x19581901 0x 0xefbeadde 0xefbeadde
0x19581e00: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e10: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e20: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e30: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e40: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e50: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e60: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e70: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e80: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
{code}
bt #2
{code}
#0
[jira] [Issue Comment Edited] (TS-833) Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef, ink_freelist_free related
[
https://issues.apache.org/jira/browse/TS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050173#comment-13050173
]
mohan_zl edited comment on TS-833 at 6/16/11 1:08 AM:
--
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0xda48180, event=2,
data=0xdb212d0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0xda48180, event=2,
data=0xdb212d0) at I_Continuation.h:146
#1 0x006f58c8 in EThread::process_event (this=0x2ae29010,
e=0xdb212d0, calling_code=2) at UnixEThread.cc:140
#2 0x006f5c0a in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff0e981f48) at Main.cc:1958
(gdb) x/40x this
0xda48180: 0x0da477a1 0x 0xefbeadde 0xefbeadde
0xda48190: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481a0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481b0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481c0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481d0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481e0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481f0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda48200: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda48210: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
(gdb) info f
Stack level 0, frame at 0x7fff0e981860:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f58c8
called by frame at 0x7fff0e9818d0
source language c++.
Arglist at 0x7fff0e981850, args: this=0xda48180, event=2, data=0xdb212d0
Locals at 0x7fff0e981850, Previous frame's sp is 0x7fff0e981860
Saved registers:
rbp at 0x7fff0e981850, rip at 0x7fff0e981858
(gdb) info args
this = (Continuation * const) 0xda48180
event = 2
data = (void *) 0xdb212d0
(gdb) p this-handler_name
$1 = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of bounds
(gdb) p *this
$2 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0xda477a1}, handler =
0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of bounds,
mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {SLinkContinuation = {
next = 0xefbeaddeefbeadde}, prev = 0xefbeaddeefbeadde}}
{code}
was (Author: wahu0315210):
{quote}
#0 0x004d2c5c in Continuation::handleEvent (this=0xda48180, event=2,
data=0xdb212d0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0xda48180, event=2,
data=0xdb212d0) at I_Continuation.h:146
#1 0x006f58c8 in EThread::process_event (this=0x2ae29010,
e=0xdb212d0, calling_code=2) at UnixEThread.cc:140
#2 0x006f5c0a in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff0e981f48) at Main.cc:1958
(gdb) x/40x this
0xda48180: 0x0da477a1 0x 0xefbeadde 0xefbeadde
0xda48190: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481a0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481b0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481c0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481d0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481e0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda481f0: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda48200: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0xda48210: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
(gdb) info f
Stack level 0, frame at 0x7fff0e981860:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f58c8
called by frame at 0x7fff0e9818d0
source language c++.
Arglist at 0x7fff0e981850, args: this=0xda48180, event=2, data=0xdb212d0
Locals at 0x7fff0e981850, Previous frame's sp is 0x7fff0e981860
Saved registers:
rbp at 0x7fff0e981850, rip at 0x7fff0e981858
(gdb) info args
this = (Continuation * const) 0xda48180
event = 2
data = (void *) 0xdb212d0
(gdb) p this-handler_name
$1 = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of bounds
(gdb) p *this
$2 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0xda477a1}, handler =
0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of bounds,
mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {SLinkContinuation = {
next = 0xefbeaddeefbeadde}, prev = 0xefbeaddeefbeadde}}
{quote}
Crash Report:
[jira] [Commented] (TS-833) Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef, ink_freelist_free related
[
https://issues.apache.org/jira/browse/TS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050174#comment-13050174
]
mohan_zl commented on TS-833:
-
@John I think this bug has not been fixed yet.
Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef,
ink_freelist_free related
---
Key: TS-833
URL: https://issues.apache.org/jira/browse/TS-833
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0
Environment: current trunk, with --enable-debug
Reporter: Zhao Yongming
Labels: freelist
Attachments: TS-833-2.diff, TS-833-3.diff, TS-833.diff
bt #1
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x197c4fc0, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff76c41528) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff76c40e40:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff76c40eb0
source language c++.
Arglist at 0x7fff76c40e30, args: this=0x19581df0, event=2, data=0x197c4fc0
Locals at 0x7fff76c40e30, Previous frame's sp is 0x7fff76c40e40
Saved registers:
rbp at 0x7fff76c40e30, rip at 0x7fff76c40e38
(gdb) x/40x this
0x19581df0: 0x19581901 0x 0xefbeadde 0xefbeadde
0x19581e00: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e10: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e20: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e30: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e40: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e50: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e60: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e70: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e80: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
{code}
bt #2
{code}
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
#1 0x0070364c in EThread::process_event (this=0x2ae29010,
e=0xc4408a0, calling_code=2) at UnixEThread.cc:140
#2 0x0070398e in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x00502aac in main (argc=3, argv=0x7fff32ef2f58) at Main.cc:1961
(gdb) p *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of
bounds, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {SLinkContinuation
= {
next = 0xefbeaddeefbeadde}, prev = 0xefbeaddeefbeadde}}
(gdb)
{code}
bt #3
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
event=2, data=0x2aaab00d1570) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
event=2, data=0x2aaab00d1570) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x2aaab00d1570, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff421f08d8) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff421f01f0:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff421f0260
source language c++.
Arglist at 0x7fff421f01e0, args: this=0x2aaab00615b0, event=2,
data=0x2aaab00d1570
Locals at 0x7fff421f01e0, Previous frame's sp is 0x7fff421f01f0
Saved registers:
rbp at 0x7fff421f01e0, rip at 0x7fff421f01e8
(gdb) p this-handler
$1 = 0xefbeaddeefbeadde, this adjustment -1171307680053154338
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-745: Attachment: ssd_cache2.patch I'm sorry John, maybe we could not use http://codereview.appspot.com/ for detailed reviews, because i am living in a magical country like Korea, i couldn't open that website... Current changes follow your advices: (1) Now the new patch delete 146 lines, and add 842 lines. I'm trying to avoid code duplicate (2) Now the patch support multi SSD, the config file is storage_ssd.config file, and the syntax to add file is the same as storage.config (3)(4)(5) I now use xmalloc to store and xfree to delete the docs. I don't understand how to use various allocators to malloc and free the docs. Besides, now i also use another CacheVC to write the docs to ssd, because i have no idea to write after calling back the user, so (4) and (5) is not done also. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1 Attachments: ssd_cache.patch, ssd_cache2.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038371#comment-13038371 ] mohan_zl commented on TS-745: - In my thoughts, if we use the same CacheVC to write after calling back the user, we can do it before free_CacheVC, but when i did this, i could not pass the function test. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1 Attachments: ssd_cache.patch, ssd_cache2.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038374#comment-13038374 ] mohan_zl commented on TS-745: - My boss have give me another passport to visit http://codereview.appspot.com/. John, i did not search the traffic server results in this site. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1 Attachments: ssd_cache.patch, ssd_cache2.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035178#comment-13035178 ] mohan_zl commented on TS-745: - +1 on a branch. I am busy on preparing ts for online use these days, sorry for looking at this so late. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1 Attachments: ssd_cache.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-745: Attachment: ssd_cache.patch Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Attachments: ssd_cache.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-654: Attachment: health_check.patch Add a new patch to keep up with trunk, right now the autoconfig is not supported, that is , if you want to update the health check config file, you must trafficserver restart, the traffic_line -x can't do it.. request for support of Layer7 http health checking for Origin Servers - Key: TS-654 URL: https://issues.apache.org/jira/browse/TS-654 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 2.1.5 Reporter: Zhao Yongming Fix For: 2.1.9 Attachments: health_check.patch this ticket is for the L7 health checking project: https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-654: Attachment: (was: Passive-L7-Health-Check.patch) request for support of Layer7 http health checking for Origin Servers - Key: TS-654 URL: https://issues.apache.org/jira/browse/TS-654 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 2.1.5 Reporter: Zhao Yongming Fix For: 2.1.9 Attachments: health_check.patch this ticket is for the L7 health checking project: https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-745) Support ssd
Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-745: Attachment: ssd_support.patch The demand is described in https://cwiki.apache.org/TS/ssdsupport.html, now i write a simple patch for supporting ssd. This is obviously a temporary scheme, and now it only supports one ssd plus several sata. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Attachments: ssd_support.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-745: Attachment: ssd_support2.patch Add missing file Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Attachments: ssd_support.patch, ssd_support2.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011903#comment-13011903 ] mohan_zl commented on TS-654: - Right now i don't want to push the new patch, because in current patch i use STL in it, so i will remove it and push it again.TS-720 request for support of Layer7 http health checking for Origin Servers - Key: TS-654 URL: https://issues.apache.org/jira/browse/TS-654 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 2.1.5 Reporter: Zhao Yongming Fix For: 2.1.8 Attachments: Passive-L7-Health-Check.patch, TS-654-v2.patch this ticket is for the L7 health checking project: https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-654: Attachment: TS-654-v2.patch Keep up with latest trunk request for support of Layer7 http health checking for Origin Servers - Key: TS-654 URL: https://issues.apache.org/jira/browse/TS-654 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 2.1.5 Reporter: Zhao Yongming Fix For: 2.1.8 Attachments: Passive-L7-Health-Check.patch, TS-654-v2.patch this ticket is for the L7 health checking project: https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TS-685) Rename partition.config ?
[ https://issues.apache.org/jira/browse/TS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003772#comment-13003772 ] mohan_zl commented on TS-685: - Why not use cache_partition.config directly, because the structure CachePart is corresponding for one virtual partition in partition.config Rename partition.config ? - Key: TS-685 URL: https://issues.apache.org/jira/browse/TS-685 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Fix For: 2.1.7 The name of partitions and partition.config is somewhat unfortunate, since it's easy to confuse this with disk partitions (e.g. /dev/sda1, /dev/sdb etc.). Our partition is a logical grouping of cache storage, and has no relation to the physical disk underneath. I feel this is an area of confusion, and we could / should improve on this by renaming configurations, stats and documentation referring to partitions as something else. Suggestions for a different name would be appreciated :). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TS-676) Logic wrong in the method of class Store
Logic wrong in the method of class Store Key: TS-676 URL: https://issues.apache.org/jira/browse/TS-676 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl The logic of method Store::clear and Store::read_config in iocore/cache/Store.cc is wrong -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TS-489) Seg Fault with Connection_Collapsing and clustering enabled.
[ https://issues.apache.org/jira/browse/TS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992262#comment-12992262 ] mohan_zl commented on TS-489: - I'm sorry, i think that is not a bug in the old code, just my fault when moving codes. Seg Fault with Connection_Collapsing and clustering enabled. Key: TS-489 URL: https://issues.apache.org/jira/browse/TS-489 Project: Traffic Server Issue Type: Bug Affects Versions: 2.0.0 Environment: Debian Lenny. 2.6.26-2-amd-64 Sun Blade X6240 (2 x Six-Core AMD Opteron(tm) Processor 2439 SE) 64G Memory Reporter: Ricky Chan Assignee: mohan_zl Priority: Critical Fix For: 2.1.6 Attachments: TS-489-zym-1.txt, TS-489.patch, code_clean_up.patch, collapse1.trace, collapse2.trace, ts_489_testing.txt Bug is easily reproduced, with the following setup. Traffic Server 2.0.0 Enable Clustering (so you'll need two machine and make sure cluster is actually working) (LOCAL proxy.local.cluster.type INT 1) Enable Connection Collapsing (CONFIG proxy.config.connection_collapsing.hashtable_enabled INT 1) Other changes to records.config which may or may affect it are changes to heuristics: CONFIG proxy.config.http.cache.heuristic_min_lifetime INT 5 CONFIG proxy.config.http.cache.heuristic_max_lifetime INT 86400 CONFIG proxy.config.http.cache.heuristic_lm_factor FLOAT 0.000100 CONFIG proxy.config.http.cache.fuzz.time INT 240 CONFIG proxy.config.http.cache.fuzz.probability FLOAT 0.05 Using a 3rd machine using apache benchmark (ab) and request with say -n 100 with keep alive (-k) and -c 8000 say. I found it happens all the time above 8000. I just fetched a file from origin on lighttpd which had a cache-control header of max-age 86400, so to reduce hitting origin. Size of file is 9 bytes only. Note: You need to set ulimit -n very high and set sysctl ip_local_port_range to larger than defaults to be able to run test, I did ulimit -n 100 and had sysctl -w net.ipv4.ip_local_port_range=1024 65000 to be able to run AB. Disabling clustering or connection Collapsing the program no longer. I then added GDB wrapper around traffic_server and it clearly shows it's the connection collapsing API which is at fault here. I'll add these traces as attachments. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TS-489) Seg Fault with Connection_Collapsing and clustering enabled.
[ https://issues.apache.org/jira/browse/TS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-489: Attachment: code_clean_up.patch The logic with connection collapsing break the logic of proxy/http and iocore/cache, and in actually it does not work very well. This patch nuke all the codes with connection collapsing. Seg Fault with Connection_Collapsing and clustering enabled. Key: TS-489 URL: https://issues.apache.org/jira/browse/TS-489 Project: Traffic Server Issue Type: Bug Affects Versions: 2.0.0 Environment: Debian Lenny. 2.6.26-2-amd-64 Sun Blade X6240 (2 x Six-Core AMD Opteron(tm) Processor 2439 SE) 64G Memory Reporter: Ricky Chan Assignee: mohan_zl Priority: Critical Fix For: 2.1.6 Attachments: code_clean_up.patch, collapse1.trace, collapse2.trace, TS-489-zym-1.txt, TS-489.patch, ts_489_testing.txt Bug is easily reproduced, with the following setup. Traffic Server 2.0.0 Enable Clustering (so you'll need two machine and make sure cluster is actually working) (LOCAL proxy.local.cluster.type INT 1) Enable Connection Collapsing (CONFIG proxy.config.connection_collapsing.hashtable_enabled INT 1) Other changes to records.config which may or may affect it are changes to heuristics: CONFIG proxy.config.http.cache.heuristic_min_lifetime INT 5 CONFIG proxy.config.http.cache.heuristic_max_lifetime INT 86400 CONFIG proxy.config.http.cache.heuristic_lm_factor FLOAT 0.000100 CONFIG proxy.config.http.cache.fuzz.time INT 240 CONFIG proxy.config.http.cache.fuzz.probability FLOAT 0.05 Using a 3rd machine using apache benchmark (ab) and request with say -n 100 with keep alive (-k) and -c 8000 say. I found it happens all the time above 8000. I just fetched a file from origin on lighttpd which had a cache-control header of max-age 86400, so to reduce hitting origin. Size of file is 9 bytes only. Note: You need to set ulimit -n very high and set sysctl ip_local_port_range to larger than defaults to be able to run test, I did ulimit -n 100 and had sysctl -w net.ipv4.ip_local_port_range=1024 65000 to be able to run AB. Disabling clustering or connection Collapsing the program no longer. I then added GDB wrapper around traffic_server and it clearly shows it's the connection collapsing API which is at fault here. I'll add these traces as attachments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-654: Attachment: Passive-L7-Health-Check.patch Imitating the http state machine, we write a l7 health check module. Trying our best not to change current codes, we create a directory named healthcheck in proxy/http, and implement the frame in this. Of course, we change or add some codes in exsiting files: (1) In iocore/hostdb, we change files I_HostDBProcessor.h, P_HostDBProcessor.h, and HostDB.cc. We add some members in HostDBInfo, and add or change some functions in the three files for supporting health check (2) In proxy/http, in order to implement a passive health check, we change the logic of function process_hostdb_info in HttpSM.cc (3) Add info in relevant Makefile.am files If you want to do health check for special origin server, you must write the relevant config information in healthcheck.config file, otherwise, traffic_server will not check health with that os. When you make install ts, the healthcheck.config file already exsits in the same place with records.config file, and some notes in this file tell you how to write config info for special origin server. When one client request is first coming and requesting info from the special origin server, http state machine will do dns resolve with the hostname of origin server and insert the result in hostdb, and immediately do health check with that origin server. Next time, because the hostname info is already in hostdb, the following client request will not cause immediate health check until the hostdb info is stale or bad in health, but periodically checking health with that os has been started. request for support of Layer7 http health checking for Origin Servers - Key: TS-654 URL: https://issues.apache.org/jira/browse/TS-654 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 2.1.5 Reporter: Zhao Yongming Attachments: Passive-L7-Health-Check.patch this ticket is for the L7 health checking project: https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-489) Seg Fault with Connection_Collapsing and clustering enabled.
[ https://issues.apache.org/jira/browse/TS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-489: Attachment: TS-489.patch I think there are two tasks for us to fix this problem: (1) There seems to be something wrong with the logic of ConnectionCollapsing (2) When cluster is enabled, ConnectionCollapsing in one server will get files from another server, but something is wrong with cluster to work it, so the cluster can not work well with ConnectionCollapsing The patch Zhao Yongming committed fixes the 80 percent of the first problem, and i do some code clean up based on it.Next step we will try our best to fix the second. Seg Fault with Connection_Collapsing and clustering enabled. Key: TS-489 URL: https://issues.apache.org/jira/browse/TS-489 Project: Traffic Server Issue Type: Bug Affects Versions: 2.0.0 Environment: Debian Lenny. 2.6.26-2-amd-64 Sun Blade X6240 (2 x Six-Core AMD Opteron(tm) Processor 2439 SE) 64G Memory Reporter: Ricky Chan Fix For: 2.1.6 Attachments: collapse1.trace, collapse2.trace, TS-489-zym-1.txt, TS-489.patch, ts_489_testing.txt Bug is easily reproduced, with the following setup. Traffic Server 2.0.0 Enable Clustering (so you'll need two machine and make sure cluster is actually working) (LOCAL proxy.local.cluster.type INT 1) Enable Connection Collapsing (CONFIG proxy.config.connection_collapsing.hashtable_enabled INT 1) Other changes to records.config which may or may affect it are changes to heuristics: CONFIG proxy.config.http.cache.heuristic_min_lifetime INT 5 CONFIG proxy.config.http.cache.heuristic_max_lifetime INT 86400 CONFIG proxy.config.http.cache.heuristic_lm_factor FLOAT 0.000100 CONFIG proxy.config.http.cache.fuzz.time INT 240 CONFIG proxy.config.http.cache.fuzz.probability FLOAT 0.05 Using a 3rd machine using apache benchmark (ab) and request with say -n 100 with keep alive (-k) and -c 8000 say. I found it happens all the time above 8000. I just fetched a file from origin on lighttpd which had a cache-control header of max-age 86400, so to reduce hitting origin. Size of file is 9 bytes only. Note: You need to set ulimit -n very high and set sysctl ip_local_port_range to larger than defaults to be able to run test, I did ulimit -n 100 and had sysctl -w net.ipv4.ip_local_port_range=1024 65000 to be able to run AB. Disabling clustering or connection Collapsing the program no longer. I then added GDB wrapper around traffic_server and it clearly shows it's the connection collapsing API which is at fault here. I'll add these traces as attachments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?
[ https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-608: Attachment: TS-608.patch change the logic: 1 if we trigger max server connections, remove one keep-alive connections from every dlist of every session bucket in HttpSessionManager 2 if we trigger per-origin limits, just remove all connections related with that origin server Is HttpSessionManager::purge_keepalives() too aggressive? -- Key: TS-608 URL: https://issues.apache.org/jira/browse/TS-608 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 3.1 Attachments: TS-608.patch It seems that if we trigger the max server connections, we call this purge function in the session manager, which will close all currently open keep-alive connections. This seems very aggressive, why not limit it to say only removing 10% of each bucket or some such? Also, how does this work together with per-origin limits? Ideally, if the per-origin limits are in place, we would only purge sessions that are for the IP we wish to connect to ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-435) SplitDNS doesn't work
[
https://issues.apache.org/jira/browse/TS-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933427#action_12933427
]
mohan_zl commented on TS-435:
-
Leif:
we did some change with splitdns in the following consideration:
1. we fix TS-435, and leave splitdns as a feature only in dns module
2. merge your patch with splitdns
we push a patch in TS-541, you can review it, thanks:D
FYI
SplitDNS doesn't work
-
Key: TS-435
URL: https://issues.apache.org/jira/browse/TS-435
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 2.0.1
Environment: Debian 5.0.5 kernel 2.6.26-1-686 #1 SMP
Reporter: Martin Leventan
Assignee: Leif Hedstrom
Priority: Trivial
Fix For: 2.1.5
Attachments: TS-435-3.diff, TS-435.patch
Server configured as forward proxy with SplitDNS enable. At start get system
DNS server but at client request fail to resolve URL.
record.config (DNS section)
CONFIG proxy.config.dns.search_default_domains INT 1
CONFIG proxy.config.dns.splitDNS.enabled INT 1
CONFIG proxy.config.dns.splitdns.def_domain STRING lapampa.gov.ar
CONFIG proxy.config.dns.url_expansions STRING NULL
CONFIG proxy.config.dns.round_robin_nameservers INT 0
CONFIG proxy.config.dns.nameservers STRING NULL
CONFIG proxy.config.dns.validate_query_name INT 0
splitdns.config
dest_domain=lapampa.gov.ar named=10.2.1.72 serach_list=lapampa.gov.ar
Debug:
[TrafficServer] using root directory '/opt/trafficserver-2'
[Sep 8 11:55:57.512] {3079767744} STATUS: opened
var/log/trafficserver/diags.log
[Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Config: etc/trafficserver/ae_ua.config
[Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Opening config
etc/trafficserver/ae_ua.config
[Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
[Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
[init_http_aeua_filter] - Total loaded 0 REGEXP for
Accept-Enconding/User-Agent filtering
[Sep 8 11:55:57.548] Server {3079767744} DEBUG: (dns) ink_dns_init: called
with init_called = 0
[Sep 8 11:55:57.587] Server {3079767744} DEBUG: (dns)
localhost=h6514asi106.glp.gov.ar
[Sep 8 11:55:57.587] Server {3079767744} DEBUG: (dns) Round-robin
nameservers = 0
[Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns)
DNSHandler::startEvent_sdns: on thread2
[Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns) open_con: opening
connection 10.2.1.73:53
[Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns) random port = 17507
[Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns) opening connection
10.2.1.73:53 SUCCEEDED for 0
[Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns)
DNSHandler::startEvent_sdns: on thread1
[Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns) open_con: opening
connection 10.2.1.73:53
[Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns) random port = 42681
[Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns) opening connection
10.2.1.73:53 SUCCEEDED for 0
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.connection_collapsing.hashtable_enabled = 0
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.connection_collapsing.rww_wait_time = 0
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.connection_collapsing.revalidate_window_period = 0
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.http.redirection_enabled = 0
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.http.number_of_redirections = 1
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.http.post_copy_size = 2048
[Sep 8 11:55:57.713] Server {3079767744} DEBUG: (dns)
DNSHandler::startEvent: on thread0
[Sep 8 11:55:57.713] Server {3079767744} DEBUG: (dns) open_con: opening
connection 10.2.1.73:53
[Sep 8 11:55:57.715] Server {3079767744} DEBUG: (dns) random port = 40576
[Sep 8 11:55:57.715] Server {3079767744} DEBUG: (dns) opening connection
10.2.1.73:53 SUCCEEDED for 0
.
+ Incoming Request +
-- State Machine Id: 0
GET http://www.lapampa.gov.ar/ HTTP/1.1^M
Host: www.lapampa.gov.ar^M
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19)
Gecko/2010072023 Iceweasel/3.0.6 (Debian-3.0.6-3)^M
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8^M
Accept-Language: en-us,en;q=0.5^M
Accept-Encoding: gzip,deflate^M
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7^M
Keep-Alive: 300^M
Proxy-Connection: keep-alive^M
Cookie: LaPampa2_tpl=LaPampa2^M
Cache-Control: max-age=0^M
^M
[Sep 8
[jira] Commented: (TS-435) SplitDNS doesn't work
[
https://issues.apache.org/jira/browse/TS-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12931001#action_12931001
]
mohan_zl commented on TS-435:
-
we have reproduce this problem when using latest trunk, and looks like
something messed during queue and handler match:
[Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns)
DNSHandler::startEvent_sdns: on thread2
[Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns) open_con: opening
connection 10.2.1.73:53
[Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns)
DNSHandler::startEvent_sdns: on thread1
[Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns) open_con: opening
connection 10.2.1.73:53
[Sep 8 11:55:57.713] Server {3079767744} DEBUG: (dns) DNSHandler::startEvent:
on thread0
[Sep 8 11:55:57.713] Server {3079767744} DEBUG: (dns) open_con: opening
connection 10.2.1.73:53
we have 3 thread connected to 10.2.1.73:53
unknown DNS id = 50074
show then dns result is mistake by other threads, it took the dns result a
unknown dns pkt, and dropped, so you can not resolve any dns
will patch it asap
SplitDNS doesn't work
-
Key: TS-435
URL: https://issues.apache.org/jira/browse/TS-435
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 2.0.1
Environment: Debian 5.0.5 kernel 2.6.26-1-686 #1 SMP
Reporter: Martin Leventan
Assignee: Leif Hedstrom
Priority: Trivial
Fix For: 2.1.5
Server configured as forward proxy with SplitDNS enable. At start get system
DNS server but at client request fail to resolve URL.
record.config (DNS section)
CONFIG proxy.config.dns.search_default_domains INT 1
CONFIG proxy.config.dns.splitDNS.enabled INT 1
CONFIG proxy.config.dns.splitdns.def_domain STRING lapampa.gov.ar
CONFIG proxy.config.dns.url_expansions STRING NULL
CONFIG proxy.config.dns.round_robin_nameservers INT 0
CONFIG proxy.config.dns.nameservers STRING NULL
CONFIG proxy.config.dns.validate_query_name INT 0
splitdns.config
dest_domain=lapampa.gov.ar named=10.2.1.72 serach_list=lapampa.gov.ar
Debug:
[TrafficServer] using root directory '/opt/trafficserver-2'
[Sep 8 11:55:57.512] {3079767744} STATUS: opened
var/log/trafficserver/diags.log
[Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Config: etc/trafficserver/ae_ua.config
[Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Opening config
etc/trafficserver/ae_ua.config
[Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
[Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
[init_http_aeua_filter] - Total loaded 0 REGEXP for
Accept-Enconding/User-Agent filtering
[Sep 8 11:55:57.548] Server {3079767744} DEBUG: (dns) ink_dns_init: called
with init_called = 0
[Sep 8 11:55:57.587] Server {3079767744} DEBUG: (dns)
localhost=h6514asi106.glp.gov.ar
[Sep 8 11:55:57.587] Server {3079767744} DEBUG: (dns) Round-robin
nameservers = 0
[Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns)
DNSHandler::startEvent_sdns: on thread2
[Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns) open_con: opening
connection 10.2.1.73:53
[Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns) random port = 17507
[Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns) opening connection
10.2.1.73:53 SUCCEEDED for 0
[Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns)
DNSHandler::startEvent_sdns: on thread1
[Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns) open_con: opening
connection 10.2.1.73:53
[Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns) random port = 42681
[Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns) opening connection
10.2.1.73:53 SUCCEEDED for 0
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.connection_collapsing.hashtable_enabled = 0
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.connection_collapsing.rww_wait_time = 0
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.connection_collapsing.revalidate_window_period = 0
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.http.redirection_enabled = 0
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.http.number_of_redirections = 1
[Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
proxy.config.http.post_copy_size = 2048
[Sep 8 11:55:57.713] Server {3079767744} DEBUG: (dns)
DNSHandler::startEvent: on thread0
[Sep 8 11:55:57.713] Server {3079767744} DEBUG: (dns) open_con: opening
connection 10.2.1.73:53
[Sep 8 11:55:57.715] Server {3079767744} DEBUG: (dns) random port = 40576
[Sep 8 11:55:57.715] Server {3079767744} DEBUG: (dns)
[jira] Updated: (TS-489) Seg Fault with Connection_Collapsing and clustering enabled.
[ https://issues.apache.org/jira/browse/TS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-489: Attachment: ts_489_testing.txt We did an experiment with ts2.0.1 stable version following the way you setup the cluster and changed the relevant arguments, and the results demonstrate that we can use the full cluster mode and connection_collapsing feature together in ts2.0.1 version. The attach file shows how each change affects the results. Seg Fault with Connection_Collapsing and clustering enabled. Key: TS-489 URL: https://issues.apache.org/jira/browse/TS-489 Project: Traffic Server Issue Type: Bug Affects Versions: 2.0.0 Environment: Debian Lenny. 2.6.26-2-amd-64 Sun Blade X6240 (2 x Six-Core AMD Opteron(tm) Processor 2439 SE) 64G Memory Reporter: Ricky Chan Fix For: 2.3.0 Attachments: collapse1.trace, collapse2.trace, ts_489_testing.txt Bug is easily reproduced, with the following setup. Traffic Server 2.0.0 Enable Clustering (so you'll need two machine and make sure cluster is actually working) (LOCAL proxy.local.cluster.type INT 1) Enable Connection Collapsing (CONFIG proxy.config.connection_collapsing.hashtable_enabled INT 1) Other changes to records.config which may or may affect it are changes to heuristics: CONFIG proxy.config.http.cache.heuristic_min_lifetime INT 5 CONFIG proxy.config.http.cache.heuristic_max_lifetime INT 86400 CONFIG proxy.config.http.cache.heuristic_lm_factor FLOAT 0.000100 CONFIG proxy.config.http.cache.fuzz.time INT 240 CONFIG proxy.config.http.cache.fuzz.probability FLOAT 0.05 Using a 3rd machine using apache benchmark (ab) and request with say -n 100 with keep alive (-k) and -c 8000 say. I found it happens all the time above 8000. I just fetched a file from origin on lighttpd which had a cache-control header of max-age 86400, so to reduce hitting origin. Size of file is 9 bytes only. Note: You need to set ulimit -n very high and set sysctl ip_local_port_range to larger than defaults to be able to run test, I did ulimit -n 100 and had sysctl -w net.ipv4.ip_local_port_range=1024 65000 to be able to run AB. Disabling clustering or connection Collapsing the program no longer. I then added GDB wrapper around traffic_server and it clearly shows it's the connection collapsing API which is at fault here. I'll add these traces as attachments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
