[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-tabpanel&focusedCommentId=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()))
> B>>>break;
> ...
> <>
> ...
> } while (1);
> C>>>ink_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)) {
> D>>>ink_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] [Commented] (TS-915) potential logical problem in net_io, especially for those whose buffer blocks exceed NET_MAX_IOV
[ https://issues.apache.org/jira/browse/TS-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088251#comment-13088251 ] mohan_zl commented on TS-915: - Remember i have discussed with weijin, these functions have no problem, we can close this issue, and do nothing. Of course, these functions maybe contain some nonsense lines, like the codes processing "lock.m.m_ptr != s->vio.mutex.m_ptr". > potential logical problem in net_io, especially for those whose buffer blocks > exceed NET_MAX_IOV > > > Key: TS-915 > URL: https://issues.apache.org/jira/browse/TS-915 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.0.1 >Reporter: weijin >Assignee: John Plevyak > Fix For: 3.1.1 > > Attachments: io_net.patch > > > think about this scenario, when read/write socket more than one time in every > call read_net_io/write_to_net_io. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (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 closed TS-844.
---
Resolution: Fixed
Seems not reproduced now, and close it temporarily.
> 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: sometime
>
> 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
> ) 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
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13086737#comment-13086737 ] mohan_zl commented on TS-880: - @William 1. I think function initialize_thread_for_net will assign value for trigger_event and signal_hook. 2. When i test your first patch, i found it will crash, and from the debug info, i found when the second time a thread use the connection which the last thread created, it will cause two thread switch, so i just add a "thread = t" in your do_reown_to_this_thread function, and change some function name. In my test environment, it do solve the problem. It seems odd, what is your test version? I use the latest trunk. 3. Agree with you, try3 is the perfect patch so far. weijin always solve one problem with only a few lines, i admire him... > 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.0 > > 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-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
> 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
> ) 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,
>
[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
> ) 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,
> even
[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
> ) 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,
>
[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-tabpanel&focusedCommentId=13082981#comment-13082981
]
mohan_zl commented on TS-844:
-
@John Plevyak
The crash resulted from "ink_assert (w->alternate.valid());" in
CacheVC::openReadChooseWriter. I think when traverse the writer list, the code
logic in this function is like this:
(1) If !w->closed && !w->alternate.valid(), then clear and retry, else go down
to (2)
(2) Now if we can go to this step, then the condition is w->closed or
w->alternate.valid(), this can be split into four category:
1) w->closed && w->alternate.valid()
2) w->closed && !w->alternate.valid()
3) !w->closed && w->alternate.valid()
Go on, now if w->f.update, then we will process the condition 2), but what if
!w->f.update? The code logic seems to think that if !w->f.update, then
condition 2) will never meet, and add the code line
"ink_assert (w->alternate.valid());". But why?
Based on these thoughts, i use TS-844.patch to prevent it from occurring, but i
think the TS-844-2.patch is more logical.
> 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 Http
[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
> ) 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,
> even
[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) a
[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
> ) 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,
>
[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
> ) 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=0x2aaab
[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=0x
[jira] [Created] (TS-909) code cleanup for format
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] [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] [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-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_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] [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-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] [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: 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 >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] [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=, len= out>, signalhandler_frame=)
> at ink_stack_trace.cc:68
> 68fp = (void **) (*fp);
> (gdb) bt
> #0 ink_stack_trace_get (stack=, len= out>, signalhandler_frame=)
> at ink_stack_trace.cc:68
> #1 0x2ba641dccef1 in ink_stack_trace_dump (sighandler_frame= optimized out>) at ink_stack_trace.cc:114
> #2 0x004df020 in signal_handler (sig=) at
> signals.cc:225
> #3
> #4 0x006a1ea9 in UnixNetVConnection::do_io_close (this=0x1cc9bd20,
> alerrno=)
> 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=)
> at HttpTunnel.cc:1456
> #10 0x006a6307 in write_to_net_io (nh=0x2b12d688, vc=0x1cc876e0,
> thread=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #11 0x0069ce97 in NetHandler::mainNetEvent (this=0x2b12d688,
> event=, 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=, len= optimized out>, signalhandler_frame=
> 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] [Updated] (TS-848) Crash Report: ShowNet::showConnectionsOnThread -> ShowCont::show
[
https://issues.apache.org/jira/browse/TS-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mohan_zl updated TS-848:
Fix Version/s: (was: 3.1.0)
3.1.1
> Crash Report: ShowNet::showConnectionsOnThread -> ShowCont::show
>
>
> Key: TS-848
> URL: https://issues.apache.org/jira/browse/TS-848
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.0
>Reporter: Zhao Yongming
> Labels: http_ui, network
> Fix For: 3.1.1
>
>
> when we use the {net} http_ui network interface, it crashed with the
> following information
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /usr/bin/traffic_server[0x51ba3e]
> /lib64/libpthread.so.0[0x3f89c0e7c0]
> [0x7fffd20544f8]
> /lib64/libc.so.6(vsnprintf+0x9a)[0x3f8906988a]
> /usr/bin/traffic_server(ShowCont::show(char const*, ...)+0x262)[0x638184]
> /usr/bin/traffic_server(ShowNet::showConnectionsOnThread(int,
> Event*)+0x481)[0x6ec7bf]
> /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6f)[0x4d302f]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x6f9978]
> /usr/bin/traffic_server(EThread::execute()+0x94)[0x6f9b6a]
> /usr/bin/traffic_server(main+0x10c7)[0x4ff74d]
> /lib64/libc.so.6(__libc_start_main+0xf4)[0x3f8901d994]
> /usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4b2149]
> /usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4b2149]
> [New process 31182]
> #0 0x003f890796d0 in strlen () from /lib64/libc.so.6
> (gdb) bt
> #0 0x003f890796d0 in strlen () from /lib64/libc.so.6
> #1 0x003f89046b69 in vfprintf () from /lib64/libc.so.6
> #2 0x003f8906988a in vsnprintf () from /lib64/libc.so.6
> #3 0x00638184 in ShowCont::show (this=0x2aaab44af600,
> s=0x7732b8
> "%d%s%d%d%s%d%d
> secs
> ago%d%d%d%d%d%d%d%d
> secs%d secs<"...) at ../../proxy/Show.h:62
> #4 0x006ec7bf in ShowNet::showConnectionsOnThread
> (this=0x2aaab44af600, event=1, e=0x2aaab5cc2080) at UnixNetPages.cc:75
> #5 0x004d302f in Continuation::handleEvent (this=0x2aaab44af600,
> event=1, data=0x2aaab5cc2080) at I_Continuation.h:146
> #6 0x006f9978 in EThread::process_event (this=0x2ae29010,
> e=0x2aaab5cc2080, calling_code=1) at UnixEThread.cc:140
> #7 0x006f9b6a in EThread::execute (this=0x2ae29010) at
> UnixEThread.cc:189
> #8 0x004ff74d in main (argc=3, argv=0x7fffd2054d88) at Main.cc:1958
> {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] [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] [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] [Updated] (TS-832) Crash Report: RecMessageMarshal_Realloc in cluster mode 2
[
https://issues.apache.org/jira/browse/TS-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mohan_zl updated TS-832:
Fix Version/s: (was: 3.1.0)
3.1.1
> Crash Report: RecMessageMarshal_Realloc in cluster mode 2
> -
>
> Key: TS-832
> URL: https://issues.apache.org/jira/browse/TS-832
> Project: Traffic Server
> Issue Type: Bug
> Components: Clustering, Core
>Affects Versions: 3.1.0
> Environment: version trunk, aka v3.0 after, cluster mode set to 2(
> management cluster ), --enable-debug
>Reporter: Zhao Yongming
> Labels: cluster, realloc
> Fix For: 3.1.1
>
>
> here is two core dumps:
> {code}
> #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 0x003c33075421 in realloc () from /lib64/libc.so.6
> #4 0x2acf28ff4e01 in ink_realloc (ptr=Could not find the frame base
> for "ink_realloc".
> ) at ink_memory.cc:88
> #5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
> record=0x2acf29248f50) at RecMessage.cc:350
> #6 0x006eced8 in send_push_message () at P_RecCore.i:154
> #7 0x006efef9 in sync_cont::sync (this=0x20034150, event=1,
> e=0x20033d30) at RecProcess.cc:263
> #8 0x004d2c5f in Continuation::handleEvent (this=0x20034150,
> event=1, data=0x20033d30) at I_Continuation.h:146
> #9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
> UnixEThread.cc:287
> #10 0x006f5181 in spawn_thread_internal (a=0x200441b0) at
> Thread.cc:88
> #11 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
> #12 0x003c330d3c2d in clone () from /lib64/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0x41f4c3e0:
> rip = 0x3c33030265 in raise; saved rip 0x3c33031d10
> called by frame at 0x41f4c520
> Arglist at 0x41f4c3d0, args:
> Locals at 0x41f4c3d0, Previous frame's sp is 0x41f4c3e0
> Saved registers:
> rip at 0x41f4c3d8
> {code}
> {code}
> #0 0x0038aa230265 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0 0x0038aa230265 in raise () from /lib64/libc.so.6
> #1 0x0038aa231d10 in abort () from /lib64/libc.so.6
> #2 0x0038aa26a84b in __libc_message () from /lib64/libc.so.6
> #3 0x0038aa275421 in realloc () from /lib64/libc.so.6
> #4 0x2ab28042ce01 in ink_realloc (ptr=Could not find the frame base
> for "ink_realloc".
> ) at ink_memory.cc:88
> #5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
> record=0x2ab280680f50) at RecMessage.cc:350
> #6 0x006eced8 in send_push_message () at P_RecCore.i:154
> #7 0x006efef9 in sync_cont::sync (this=0x16a6f150, event=1,
> e=0x16a6ed30) at RecProcess.cc:263
> #8 0x004d2c5f in Continuation::handleEvent (this=0x16a6f150,
> event=1, data=0x16a6ed30) at I_Continuation.h:146
> #9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
> UnixEThread.cc:287
> #10 0x006f5181 in spawn_thread_internal (a=0x16a7f1b0) at
> Thread.cc:88
> #11 0x0038aae064a7 in start_thread () from /lib64/libpthread.so.0
> #12 0x0038aa2d3c2d in clone () from /lib64/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0x406b03e0:
> rip = 0x38aa230265 in raise; saved rip 0x38aa231d10
> called by frame at 0x406b0520
> Arglist at 0x406b03d0, args:
> Locals at 0x406b03d0, Previous frame's sp is 0x406b03e0
> Saved registers:
> rip at 0x406b03d8
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-725) Crash Report: url_host_set in 2.1.6
[
https://issues.apache.org/jira/browse/TS-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mohan_zl updated TS-725:
Fix Version/s: (was: 3.1.0)
3.1.1
> Crash Report: url_host_set in 2.1.6
> ---
>
> Key: TS-725
> URL: https://issues.apache.org/jira/browse/TS-725
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 2.1.6
>Reporter: Zhao Yongming
> Labels: crash
> Fix For: 3.1.1
>
>
> reported by user:
> {code:none}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/ts/bin/traffic_server - STACK TRACE:
> [0x4001c420]
> /lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
> [0xf]
> /usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char
> const*, int, bool)+0x51)[0x8229631]
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/ts/bin/traffic_server - STACK TRACE:
> [0x4001c420]
> /lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
> [0xf]
> /usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char
> const*, int, bool)+0x51)[0x8229631]
> /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0xab)[0x816a8eb]
> /usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x321)[0x817acc1]
> /usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
> void*)+0x1a4)[0x8184894]
> /usr/local/ts/bin/traffic_server[0x82f880c]
> /usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
> Event*)+0x4ce)[0x82edffe]
> /usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
> int)+0x1ff)[0x83226bf]
> /usr/local/ts/bin/traffic_server(EThread::execute()+0x449)[0x8322e69]
> /usr/local/ts/bin/traffic_server[0x8321abc]
> /lib/tls/i686/cmov/libpthread.so.0[0x400284fb]
> /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
> /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
> [Mar 8 11:02:52.960] Manager {3080226496} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmenta
> tion fault
> [Mar 8 11:02:52.960] Manager {3080226496} ERROR: (last system error 2: No
> such file or directory)
> [Mar 8 11:02:52.961] Manager {3080226496} ERROR: [Alarms::signalAlarm]
> Server Process was reset
> [Mar 8 11:02:52.961] Manager {3080226496} ERROR: (last system error 2: No
> such file or directory)
> [Mar 8 11:02:53.964] Manager {3080226496} NOTE: [LocalManager::startProxy]
> Launching ts process
> [TrafficServer] using root directory '/usr/local/ts'
> [Mar 8 11:02:53.973] Manager {3080226496} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
> [Mar 8 11:02:53.973] Manager {3080226496} NOTE: [Alarms::signalAlarm] Server
> Process born
> [Mar 8 11:02:55.015] {1079500240} STATUS: opened
> /usr/local/ts/var/log/trafficserver/diags.log
> [Mar 8 11:02:55.015] {1079500240} NOTE: updated diags config
> [Mar 8 11:02:55.024] Server {1079500240} NOTE: cache clustering disabled
> [Mar 8 11:02:55.069] Server {1079500240} NOTE: cache clustering disabled
> [Mar 8 11:02:55.274] Server {1079500240} STATUS: Rolling disabled for
> /usr/local/ts/var/log/trafficserver/access.log.pipe
> [Mar 8 11:02:55.325] Server {1079500240} NOTE: logging initialized[7],
> logging_mode = 3
> [Mar 8 11:02:55.368] Server {1079500240} NOTE: traffic server running
> [Mar 8 11:02:58.584] Server {1096645520} NOTE: cache enabled
> {code}
--
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] [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} D
[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] [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-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
>
> 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] [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-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] [Updated] (TS-873) Wrong code in iocore/net/UnixNet.cc
[ https://issues.apache.org/jira/browse/TS-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-873: Attachment: TS-net2.patch In iocore/net/UnixNet.cc, line95, s/read_ready_list/write_read_list > 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 > Attachments: TS-net2.patch > > > 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-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] [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-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-tabpanel&focusedCommentId=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-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:all-tabpanel ] mohan_zl updated TS-870: Attachment: TS-evacuate-correct.patch Try to fix this problem, the default behavior is not use this feature. > 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-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-tabpanel&focusedCommentId=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] [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] [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-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] [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-tabpanel&focusedCommentId=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=, len=, signalhandler_frame=) at ink_stack_trace.cc:68
68 fp = (void **) (*fp);
(gdb) bt
#0 ink_stack_trace_get (stack=, len=, signalhandler_frame=) at ink_stack_trace.cc:68
#1 0x0038ff016ef1 in ink_stack_trace_dump (sighandler_frame=) at ink_stack_trace.cc:114
#2 0x004ddc10 in signal_handler (sig=) at
signals.cc:225
#3
#4 0x006990d9 in UnixNetVConnection::do_io_close (this=0x20efd5e0,
alerrno=) 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=) at HttpTunnel.cc:1452
#12 0x0069f097 in read_from_net (nh=0x2adfe688, vc=0x20eb4c40,
thread=) at ../../iocore/eventsystem/I_Continuation.h:146
#13 0x006940e1 in NetHandler::mainNetEvent (this=0x2adfe688,
event=, 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=, argv=) at Main.cc:1957
{code}
was (Author: wahu0315210):
#0 ink_stack_trace_get (stack=, len=, signalhandler_frame=) at ink_stack_trace.cc:68
68 fp = (void **) (*fp);
(gdb) bt
#0 ink_stack_trace_get (stack=, len=, signalhandler_frame=) at ink_stack_trace.cc:68
#1 0x0038ff016ef1 in ink_stack_trace_dump (sighandler_frame=) at ink_stack_trace.cc:114
#2 0x004ddc10 in signal_handler (sig=) at
signals.cc:225
#3
#4 0x006990d9 in UnixNetVConnection::do_io_close (this=0x20efd5e0,
alerrno=) 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=) at HttpTunnel.cc:1452
#12 0x0069f097 in read_from_net (nh=0x2adfe688, vc=0x20eb4c40,
thread=) at ../../iocore/eventsystem/I_Continuation.h:146
#13 0x006940e1 in NetHandler::mainNetEvent (this=0x2adfe688,
event=, 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=, argv=) 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}
[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-tabpanel&focusedCommentId=13058160#comment-13058160
]
mohan_zl commented on TS-857:
-
#0 ink_stack_trace_get (stack=, len=, signalhandler_frame=) at ink_stack_trace.cc:68
68 fp = (void **) (*fp);
(gdb) bt
#0 ink_stack_trace_get (stack=, len=, signalhandler_frame=) at ink_stack_trace.cc:68
#1 0x0038ff016ef1 in ink_stack_trace_dump (sighandler_frame=) at ink_stack_trace.cc:114
#2 0x004ddc10 in signal_handler (sig=) at
signals.cc:225
#3
#4 0x006990d9 in UnixNetVConnection::do_io_close (this=0x20efd5e0,
alerrno=) 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=) at HttpTunnel.cc:1452
#12 0x0069f097 in read_from_net (nh=0x2adfe688, vc=0x20eb4c40,
thread=) at ../../iocore/eventsystem/I_Continuation.h:146
#13 0x006940e1 in NetHandler::mainNetEvent (this=0x2adfe688,
event=, 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=, argv=) 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=, len= out>, signalhandler_frame=)
> at ink_stack_trace.cc:68
> 68fp = (void **) (*fp);
> (gdb) bt
> #0 ink_stack_trace_get (stack=, len= out>, signalhandler_frame=)
> at ink_stack_trace.cc:68
> #1 0x2ba641dccef1 in ink_stack_trace_dump (sighandler_frame= optimized out>) at ink_stack_trace.cc:114
> #2 0x004df020 in signal_handler (sig=) at
> signals.cc:225
> #3
> #4 0x006a1ea9 in UnixNetVConnection::do_io_close (this=0x1cc9bd20,
> alerrno=)
> 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=)
> at HttpTunnel.cc:1456
> #10 0x006a6307 in write_to_net_io (nh=0x2b12d688, vc=0x1cc876e0,
> thread=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #11 0x0069ce97 in NetHandler::mainNetEvent (this=0x2b12d688,
> event=, 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
> call
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056348#comment-13056348 ] mohan_zl commented on TS-745: - I have been testing this patch for some days, and now it looks stable. 1. The created config file storage_ssd.config has the same syntax with the storage.config file, users can use one or more ssd, if there is no storage_ssd.config file or the file have no content, then ssd is disabled. 2. I disable the multi-fragment feature in this version, ssd can save file whose size is between [0, proxy.config.cache.target_fragment_size). In the next step i will consider to add multi-fragment feature. > 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-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-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_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 > 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: 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: 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: 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] [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-tabpanel&focusedCommentId=13053568#comment-13053568
]
mohan_zl commented on TS-833:
-
{code}
#0 ink_stack_trace_get (stack=, len=, signalhandler_frame=) at ink_stack_trace.cc:68
68 fp = (void **) (*fp);
(gdb) bt
#0 ink_stack_trace_get (stack=, len=, signalhandler_frame=) at ink_stack_trace.cc:68
#1 0x2ab9bd500ef1 in ink_stack_trace_dump (sighandler_frame=) at ink_stack_trace.cc:114
#2 0x004df020 in signal_handler (sig=) at
signals.cc:225
#3
#4 HostDBContinuation::dnsEvent (this=0x1f5d7b30, event=600, e=0x0) at
HostDB.cc:1337
#5 0x00607417 in DNSEntry::postEvent (this=0x20dad940, event=, e=) at
../../iocore/eventsystem/I_Continuation.h:146
#6 0x006cdccf in EThread::process_event (this=0x2ae29010,
e=0x29c3f220, calling_code=2) at I_Continuation.h:146
#7 0x006ce3fb in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#8 0x004bf5fe in main (argc=, argv=) at Main.cc:1962
(gdb) info f
Stack level 0, frame at 0x7fff382da560:
rip = 0x2ab9bd500df3 in ink_stack_trace_get(void**, int, int)
(ink_stack_trace.cc:68); saved rip 0x2ab9bd500ef1
called by frame at 0x7fff382da9b0
source language c++.
Arglist at 0x7fff382da540, args: stack=, len=, signalhandler_frame=
Locals at 0x7fff382da540, Previous frame's sp is 0x7fff382da560
Saved registers:
rbx at 0x7fff382da548, rbp at 0x7fff382da550, rip at 0x7fff382da558
(gdb) info args
stack =
len =
signalhandler_frame =
{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 = { = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
> handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
> handler_name = 0xefbeaddeefbeadde bounds>, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {>
> = {
> next
[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
> ) 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=0x20
[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-tabpanel&focusedCommentId=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 = { = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
> handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
> handler_name = 0xefbeaddeefbeadde bounds>, mutex =
[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-tabpanel&focusedCommentId=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 = { = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
> handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
> handler_name = 0xefbeaddeefbeadde bounds>, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {>
> = {
> 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,
> d
[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-tabpanel&focusedCommentId=13051761#comment-13051761
]
mohan_zl commented on TS-833:
-
@John, when i use your patch TS-833-3.diff in latest trunk, with debug enabled,
then one assert fail in openReadFromWriter, i file a bug in TS-844.
> 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 = { = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
> handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
> handler_name = 0xefbeaddeefbeadde bounds>, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {>
> = {
> 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 -1
[jira] [Issue Comment Edited] (TS-844) ReadFromWriter fail in CacheRead.cc
[
https://issues.apache.org/jira/browse/TS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051760#comment-13051760
]
mohan_zl edited comment on TS-844 at 6/20/11 1:38 AM:
--
The enviroment is like this:
{code}
[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
{code}
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.
was (Author: wahu0315210):
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
[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-tabpanel&focusedCommentId=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
[jira] [Created] (TS-844) ReadFromWriter fail in CacheRead.cc
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
(this=0x2aaab4470830, f=0x59e52e
) at HttpSM.cc:6328
#37 0x0057490c in HttpSM::state_read_client_request_header
(this=0x2aaab4470830, event=100, data=0x2049f5e8) at HttpSM.cc:780
#38 0x0056e49f in HttpSM::main_handler (this=0x2aaab4470830, event=100,
data=0x2049f5e8) at HttpSM.cc:2436
#39 0x004d302f in Continuation::handleEvent (this=0x2aaab4470830,
event=100, data=0x2049f5e8) at I_Continuation.h:146
#40 0x006d6b61 in read_signal_and_update (event=100, vc=0x2049f420) at
UnixNetVConnection.cc:138
#41 0x006d739e in read_from_net (nh=0x2b32f688, vc=0x2049f420,
thread=0x2b32e010) at UnixNetVConnection.cc:320
#42 0x006d74b9 in UnixNetVConnection::net_read_io (this=0x2049f420,
nh=0x2a
[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-tabpanel&focusedCommentId=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 = { = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
> handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
> handler_name = 0xefbeaddeefbeadde bounds>, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {>
> = {
> 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 informati
[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-tabpanel&focusedCommentId=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 = { = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
> handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
> handler_name = 0xefbeaddeefbeadde bounds>, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {>
> = {
> 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://ww
[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-tabpanel&focusedCommentId=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
(gdb) p *this
$2 = { = {_vptr.force_VFPT_to_top = 0xda477a1}, handler =
0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde ,
mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {> = {
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
(gdb) p *this
$2 = { = {_vptr.force_VFPT_to_top = 0xda477a1}, handler =
0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde ,
mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {> = {
next = 0xefbeaddeefbeadde}, prev = 0xefbeaddeefbeadde}}
{quote}
> Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef,
> ink_freelist_free related
> ---
>
> Key: TS-833
> URL: https://issue
[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-tabpanel&focusedCommentId=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 = { = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
> handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
> handler_name = 0xefbeaddeefbeadde bounds>, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {>
> = {
> 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.atlass
[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-tabpanel&focusedCommentId=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
(gdb) p *this
$2 = { = {_vptr.force_VFPT_to_top = 0xda477a1}, handler =
0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde ,
mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {> = {
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 0x004d637c in Continuation::handleEvent (this=0xc3cc390
[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-tabpanel&focusedCommentId=13049666#comment-13049666
]
mohan_zl commented on TS-833:
-
John, i wanna know where can i get your theory paper?
> 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 = { = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
> handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
> handler_name = 0xefbeaddeefbeadde bounds>, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {>
> = {
> 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
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040598#comment-13040598 ] mohan_zl commented on TS-745: - I'm considering the multi-fragment problem, i wanna know besides large file examples, when will use multi fragments? > 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: 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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-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] [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: TS-654-v2.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] [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-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_support.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-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-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_support2.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-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] [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] [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-567) Cleanup of memory allocation in libinktomi++
[
https://issues.apache.org/jira/browse/TS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mohan_zl updated TS-567:
Attachment: clear_memory.patch
in build/aux/ltmain.sh, i wanna know whether or not should we support xfree
like xmalloc
change
#define XFREE(stale) do { \
if (stale) { free ((void *) stale); stale = 0; } \
} while (0)
to
#define XFREE(stale) do { \
if (stale) { xfree ((void *) stale); stale = 0; } \
} while (0)
and add function xfree
void
xfree (void *mem)
{
if (mem != NULL)
free (p);
else
lt_fatal ("Freeing a NULL pointer");
}
considering WIN32 support, i did not remove the relevant codes in iocore/cache,
but change the function, like:
CacheDisk::open
#if defined(_WIN32)
- header = (DiskHeader *) malloc(header_len);
+ header = (DiskHeader *) xmalloc(header_len);
#else
- header = (DiskHeader *) valloc(header_len);
+ header = (DiskHeader *) ink_memalign(sysconf(_SC_PAGESIZE), header_len);
in iocore/net/SSLNet.cc
void
SSLNetProcessor::initSSLLocks(void)
{
#if !defined (_IOCORE_WIN32)
sslMutexArray = (ProxyMutex **) OPENSSL_malloc(CRYPTO_num_locks() *
sizeof(ProxyMutex *));
#else
sslMutexArray = (ProxyMutex **) Malloc(CRYPTO_num_locks() * sizeof(ProxyMutex
*)); // this is not defined, and maybe we should remove it
#endif
...
}
> Cleanup of memory allocation in libinktomi++
>
>
> Key: TS-567
> URL: https://issues.apache.org/jira/browse/TS-567
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Leif Hedstrom
>Priority: Critical
> Fix For: 3.1
>
> Attachments: clear_memory.patch, malloc.txt
>
>
> There's a lot of ifdef's and debugging code paths around various allocation
> schemes in libinktomi++. We should clean this up, and simplify. It'd also be
> great to make it easy to enable various other allocators, e.g. jemalloc or
> tcmalloc, as part of the build system, causing ink_malloc / xmalloc and STL
> containers to use the new allocator. In particular for STL containers, it
> means we might need to have some allocator setup / initialization?
> Also, when should we use ink_malloc() vs xmalloc() ? It's quite
> inconsistently used right now I think. And, there are a few places using
> malloc() (etc.) directly, which we ought to fix.
--
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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] Updated: (TS-676) Logic wrong in the method of class Store
[ https://issues.apache.org/jira/browse/TS-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-676: Attachment: TS676.patch The attached patch modify some logic in these method. > 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 > Attachments: TS676.patch > > > 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] 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=12985104#action_12985104 ] mohan_zl commented on TS-489: - Besides, i placed the hashtable which is used for ConnectionCollapsing in proxy/http/Hash_Table.h and Hash_Table.cc, but i don't think this is a good way. Based on HashTable, should we construct a structer like HttpSessionManager, named like ConnectionCollapsingManager, to be used for CC? > 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-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-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-tabpanel&focusedCommentId=12980522#action_12980522 ] mohan_zl commented on TS-489: - Just leave it to ming_zym, he has time to do it:D > 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_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] Commented: (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?
[ https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976179#action_12976179 ] mohan_zl commented on TS-608: - Now we are writing a l7 health check module, and i agree with your idea. Maybe we can do it when finish current work, if it is not very urgent. > 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: 2.1.6 > > > 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] Updated: (TS-541) SplitDNS cleanup in project HostDBandDNS
[ https://issues.apache.org/jira/browse/TS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-541: Attachment: TS-541.patch > SplitDNS cleanup in project HostDBandDNS > > > Key: TS-541 > URL: https://issues.apache.org/jira/browse/TS-541 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup, DNS >Reporter: Zhao Yongming >Priority: Minor > Attachments: TS-541.patch > > > as per https://cwiki.apache.org/confluence/display/TS/HostDBandDNS, we will > need to cleanup SplitDNS, make it out of HostDB codes, merge with common dns > processor. this may be another fix for TS-435. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-541) SplitDNS cleanup in project HostDBandDNS
[ https://issues.apache.org/jira/browse/TS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-541: Attachment: (was: TS-541SplitDNS-cleanup-in-project-HostDBandDNS.patch) > SplitDNS cleanup in project HostDBandDNS > > > Key: TS-541 > URL: https://issues.apache.org/jira/browse/TS-541 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup, DNS >Reporter: Zhao Yongming >Priority: Minor > Attachments: TS-541.patch > > > as per https://cwiki.apache.org/confluence/display/TS/HostDBandDNS, we will > need to cleanup SplitDNS, make it out of HostDB codes, merge with common dns > processor. this may be another fix for TS-435. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-541) SplitDNS cleanup in project HostDBandDNS
[ https://issues.apache.org/jira/browse/TS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-541: Attachment: TS-541SplitDNS-cleanup-in-project-HostDBandDNS.patch > SplitDNS cleanup in project HostDBandDNS > > > Key: TS-541 > URL: https://issues.apache.org/jira/browse/TS-541 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup, DNS >Reporter: Zhao Yongming >Priority: Minor > Attachments: TS-541SplitDNS-cleanup-in-project-HostDBandDNS.patch > > > as per https://cwiki.apache.org/confluence/display/TS/HostDBandDNS, we will > need to cleanup SplitDNS, make it out of HostDB codes, merge with common dns > processor. this may be another fix for TS-435. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
