[jira] [Created] (TS-3160) traffic_cop mis-closed fd before forking traffic_manager
zouyu created TS-3160:
-
Summary: traffic_cop mis-closed fd before forking traffic_manager
Key: TS-3160
URL: https://issues.apache.org/jira/browse/TS-3160
Project: Traffic Server
Issue Type: Bug
Components: Cop
Reporter: zouyu
In traffic_cop 'main' function, before it forks traffic_manager, it will first
close stdin, stdout, and stderr and then redirect them to /dev/null.
But when it closes the fd opened by /dev/null, it doesn't check whether the fd
is 0, 1 or 2. So, in current code logic, the fd may be 1, and after close it,
later opened file will uses the fd 1, and printf will corrupt that file.
1826 if (!stdout_flag) {
1827 close(STDIN_FILENO);
1828 close(STDOUT_FILENO);
1829 close(STDERR_FILENO);
1830 if ((fd = open(/dev/null, O_WRONLY, 0)) = 0) {
1831 fcntl(fd, F_DUPFD, STDIN_FILENO);
1832 fcntl(fd, F_DUPFD, STDOUT_FILENO);
1833 fcntl(fd, F_DUPFD, STDERR_FILENO);
1834 close(fd); //zouyu this doesn't check the fd value 0, 1 or 2.
1835 } else {
1836 ink_fputln(stderr, Unable to open /dev/null);
1837 return 0;
1838 }
1839 }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3161) traffic_top shows some values incorrectly
Feifei Cai created TS-3161: -- Summary: traffic_top shows some values incorrectly Key: TS-3161 URL: https://issues.apache.org/jira/browse/TS-3161 Project: Traffic Server Issue Type: Bug Components: Tools Reporter: Feifei Cai The average time values in Cache Information do not show correctly, such as Fresh (ms), Reval (ms)... We use TSRecordGetInt to get all statistics. Some statistics are float value, we need to use TSRecordGetFloat. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3161) traffic_top shows some values incorrectly
[ https://issues.apache.org/jira/browse/TS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Feifei Cai updated TS-3161: --- Attachment: traffic_top-1.png The average time of Fresh, Reval, Cold, Change, Not, No (ms) do not show correctly. traffic_top shows some values incorrectly - Key: TS-3161 URL: https://issues.apache.org/jira/browse/TS-3161 Project: Traffic Server Issue Type: Bug Components: Tools Reporter: Feifei Cai Attachments: traffic_top-1.png The average time values in Cache Information do not show correctly, such as Fresh (ms), Reval (ms)... We use TSRecordGetInt to get all statistics. Some statistics are float value, we need to use TSRecordGetFloat. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3161) traffic_top shows some values incorrectly
[ https://issues.apache.org/jira/browse/TS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Feifei Cai updated TS-3161: --- Attachment: traffic_top-1.png traffic_top shows some values incorrectly - Key: TS-3161 URL: https://issues.apache.org/jira/browse/TS-3161 Project: Traffic Server Issue Type: Bug Components: Tools Reporter: Feifei Cai Attachments: traffic_top-1.png, traffic_top-1.png The average time values in Cache Information do not show correctly, such as Fresh (ms), Reval (ms)... We use TSRecordGetInt to get all statistics. Some statistics are float value, we need to use TSRecordGetFloat. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3161) traffic_top shows some values incorrectly
[ https://issues.apache.org/jira/browse/TS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Feifei Cai updated TS-3161: --- Attachment: (was: traffic_top-1.png) traffic_top shows some values incorrectly - Key: TS-3161 URL: https://issues.apache.org/jira/browse/TS-3161 Project: Traffic Server Issue Type: Bug Components: Tools Reporter: Feifei Cai Attachments: traffic_top-1.png The average time values in Cache Information do not show correctly, such as Fresh (ms), Reval (ms)... We use TSRecordGetInt to get all statistics. Some statistics are float value, we need to use TSRecordGetFloat. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3161) traffic_top shows some values incorrectly
[ https://issues.apache.org/jira/browse/TS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14189888#comment-14189888 ] Feifei Cai edited comment on TS-3161 at 10/30/14 10:09 AM: --- traffic_top-1: The average time of Fresh, Reval, Cold, Change, Not, No (ms) do not show correctly. was (Author: ffcai): The average time of Fresh, Reval, Cold, Change, Not, No (ms) do not show correctly. traffic_top shows some values incorrectly - Key: TS-3161 URL: https://issues.apache.org/jira/browse/TS-3161 Project: Traffic Server Issue Type: Bug Components: Tools Reporter: Feifei Cai Attachments: traffic_top-1.png The average time values in Cache Information do not show correctly, such as Fresh (ms), Reval (ms)... We use TSRecordGetInt to get all statistics. Some statistics are float value, we need to use TSRecordGetFloat. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3161) traffic_top shows some values incorrectly
[ https://issues.apache.org/jira/browse/TS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Feifei Cai updated TS-3161: --- Attachment: (was: traffic_top-2.png) traffic_top shows some values incorrectly - Key: TS-3161 URL: https://issues.apache.org/jira/browse/TS-3161 Project: Traffic Server Issue Type: Bug Components: Tools Reporter: Feifei Cai Attachments: traffic_top-1.png The average time values in Cache Information do not show correctly, such as Fresh (ms), Reval (ms)... We use TSRecordGetInt to get all statistics. Some statistics are float value, we need to use TSRecordGetFloat. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3161) traffic_top shows some values incorrectly
[ https://issues.apache.org/jira/browse/TS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Feifei Cai updated TS-3161: --- Attachment: traffic_top-2.png traffic_top shows some values incorrectly - Key: TS-3161 URL: https://issues.apache.org/jira/browse/TS-3161 Project: Traffic Server Issue Type: Bug Components: Tools Reporter: Feifei Cai Attachments: traffic_top-1.png, traffic_top-2.png The average time values in Cache Information do not show correctly, such as Fresh (ms), Reval (ms)... We use TSRecordGetInt to get all statistics. Some statistics are float value, we need to use TSRecordGetFloat. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3161) traffic_top shows some values incorrectly
[ https://issues.apache.org/jira/browse/TS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14189897#comment-14189897 ] Feifei Cai edited comment on TS-3161 at 10/30/14 10:27 AM: --- traffic_top-2: After the fix, it shows the correct values. I've tried a private fix on my local environment, will send pull request some later. was (Author: ffcai): traffic_top-2: After the fix, it shows the correct values. traffic_top shows some values incorrectly - Key: TS-3161 URL: https://issues.apache.org/jira/browse/TS-3161 Project: Traffic Server Issue Type: Bug Components: Tools Reporter: Feifei Cai Attachments: traffic_top-1.png, traffic_top-2.png The average time values in Cache Information do not show correctly, such as Fresh (ms), Reval (ms)... We use TSRecordGetInt to get all statistics. Some statistics are float value, we need to use TSRecordGetFloat. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3161) traffic_top shows some values incorrectly
[ https://issues.apache.org/jira/browse/TS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3161: -- Fix Version/s: 5.2.0 traffic_top shows some values incorrectly - Key: TS-3161 URL: https://issues.apache.org/jira/browse/TS-3161 Project: Traffic Server Issue Type: Bug Components: Tools Reporter: Feifei Cai Fix For: 5.2.0 Attachments: traffic_top-1.png, traffic_top-2.png The average time values in Cache Information do not show correctly, such as Fresh (ms), Reval (ms)... We use TSRecordGetInt to get all statistics. Some statistics are float value, we need to use TSRecordGetFloat. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3161) traffic_top shows some values incorrectly
[ https://issues.apache.org/jira/browse/TS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3161: -- Assignee: Bryan Call traffic_top shows some values incorrectly - Key: TS-3161 URL: https://issues.apache.org/jira/browse/TS-3161 Project: Traffic Server Issue Type: Bug Components: Tools Reporter: Feifei Cai Assignee: Bryan Call Fix For: 5.2.0 Attachments: traffic_top-1.png, traffic_top-2.png The average time values in Cache Information do not show correctly, such as Fresh (ms), Reval (ms)... We use TSRecordGetInt to get all statistics. Some statistics are float value, we need to use TSRecordGetFloat. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3160) traffic_cop mis-closed fd before forking traffic_manager
[
https://issues.apache.org/jira/browse/TS-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3160:
--
Fix Version/s: 5.2.0
traffic_cop mis-closed fd before forking traffic_manager
Key: TS-3160
URL: https://issues.apache.org/jira/browse/TS-3160
Project: Traffic Server
Issue Type: Bug
Components: Cop
Reporter: zouyu
Labels: review
Fix For: 5.2.0
In traffic_cop 'main' function, before it forks traffic_manager, it will
first close stdin, stdout, and stderr and then redirect them to /dev/null.
But when it closes the fd opened by /dev/null, it doesn't check whether the
fd is 0, 1 or 2. So, in current code logic, the fd may be 1, and after close
it, later opened file will uses the fd 1, and printf will corrupt that file.
1826 if (!stdout_flag) {
1827 close(STDIN_FILENO);
1828 close(STDOUT_FILENO);
1829 close(STDERR_FILENO);
1830 if ((fd = open(/dev/null, O_WRONLY, 0)) = 0) {
1831 fcntl(fd, F_DUPFD, STDIN_FILENO);
1832 fcntl(fd, F_DUPFD, STDOUT_FILENO);
1833 fcntl(fd, F_DUPFD, STDERR_FILENO);
1834 close(fd); //zouyu this doesn't check the fd value 0, 1 or 2.
1835 } else {
1836 ink_fputln(stderr, Unable to open /dev/null);
1837 return 0;
1838 }
1839 }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3160) traffic_cop mis-closed fd before forking traffic_manager
[
https://issues.apache.org/jira/browse/TS-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3160:
--
Labels: review (was: )
traffic_cop mis-closed fd before forking traffic_manager
Key: TS-3160
URL: https://issues.apache.org/jira/browse/TS-3160
Project: Traffic Server
Issue Type: Bug
Components: Cop
Reporter: zouyu
Labels: review
Fix For: 5.2.0
In traffic_cop 'main' function, before it forks traffic_manager, it will
first close stdin, stdout, and stderr and then redirect them to /dev/null.
But when it closes the fd opened by /dev/null, it doesn't check whether the
fd is 0, 1 or 2. So, in current code logic, the fd may be 1, and after close
it, later opened file will uses the fd 1, and printf will corrupt that file.
1826 if (!stdout_flag) {
1827 close(STDIN_FILENO);
1828 close(STDOUT_FILENO);
1829 close(STDERR_FILENO);
1830 if ((fd = open(/dev/null, O_WRONLY, 0)) = 0) {
1831 fcntl(fd, F_DUPFD, STDIN_FILENO);
1832 fcntl(fd, F_DUPFD, STDOUT_FILENO);
1833 fcntl(fd, F_DUPFD, STDERR_FILENO);
1834 close(fd); //zouyu this doesn't check the fd value 0, 1 or 2.
1835 } else {
1836 ink_fputln(stderr, Unable to open /dev/null);
1837 return 0;
1838 }
1839 }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3151) Segfault on background fill
[
https://issues.apache.org/jira/browse/TS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190215#comment-14190215
]
Alan M. Carroll commented on TS-3151:
-
I tried the patch but it doesn't compile -
{code}
server_entry server_entry-vc server_entry-vc-server_vc
{code}
{{server_entry-vc}} is a {{VConnection}} which doesn't have an exposed member
{{server_vc}}. The line of the crash uses {{server_session-get_netvc()}} with
the assertion that {{server_entry-vc == server_session}}. Based on the logic I
will presume the additional check in {{is_bg_fill_necessary}} is for
{{server_session-get_netvc()}} which seems reasonable, as the point is to
check that we have a valid origin server source.
Segfault on background fill
---
Key: TS-3151
URL: https://issues.apache.org/jira/browse/TS-3151
Project: Traffic Server
Issue Type: Bug
Reporter: Acacio Centeno
Assignee: Alan M. Carroll
On rare occasions, a background fill will fail and lead to a segfault, with
the following stacktrace:
#0 0x0060cb6d in HttpSM::tunnel_handler_ua (this=0x2aaac2bb0750,
event=104, char=0x2aaac2bb1c60) at HttpSM.cc:3171
#1 0x00652bbe in HttpTunnel::consumer_handler (this=0x2aaac2bb1b48,
event=104, char=0x2aaac2bb1c60) at HttpTunnel.cc:1294
#2 0x006532be in HttpTunnel::main_handler (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at HttpTunnel.cc:1525
#3 0x004ebc5e in Continuation::handleEvent (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at ../iocore/eventsystem/I_Continuation.h:146
#4 0x0076b140 in write_signal_and_update (event=104,
vc=0x2aab6c003560) at UnixNetVConnection.cc:153
#5 0x0076b23e in write_signal_done (event=104, nh=0x2f4e2ba0,
vc=0x2aab6c003560) at UnixNetVConnection.cc:180
#6 0x0076c047 in write_to_net_io (nh=0x2f4e2ba0,
vc=0x2aab6c003560, thread=0x2f4df010) at UnixNetVConnection.cc:471
#7 0x0076ba17 in write_to_net (nh=0x2f4e2ba0, vc=0x2aab6c003560,
thread=0x2f4df010) at UnixNetVConnection.cc:352
#8 0x00765216 in NetHandler::mainNetEvent (this=0x2f4e2ba0,
event=5, long double=0x1f87bd0) at UnixNet.cc:415
#9 0x004ebc5e in Continuation::handleEvent (this=0x2f4e2ba0,
event=5, data=0x1f87bd0) at ../iocore/eventsystem/I_Continuation.h:146
#10 0x0078beea in EThread::process_event (this=0x2f4df010, long
double=0x1f87bd0, calling_code=5) at UnixEThread.cc:145
#11 0x0078c3f4 in EThread::execute (this=0x2f4df010) at
UnixEThread.cc:269
#12 0x0078b448 in spawn_thread_internal (signed char=0x1f48c20) at
Thread.cc:88
#13 0x2c97a9d1 in start_thread () from /lib64/libpthread.so.0
#14 0x2d61c86d in clone () from /lib64/libc.so.6
This seems close to the issue reported on
https://issues.apache.org/jira/browse/TS-2705
Except that in our case, server_entry-vc-server_vc was NULL, so maybe the
appropriate solution would be to add that to the check done in
is_bg_fill_necessary, like:
if (c-producer-alive // something there to read
server_entry server_entry-vc server_entry-vc-server_vc //
from an origin server
c-producer-num_consumers 1 // with someone else reading it
) {
...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3105) Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond
[ https://issues.apache.org/jira/browse/TS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14189535#comment-14189535 ] Susan Hinrichs edited comment on TS-3105 at 10/30/14 3:20 PM: -- ts-3105-master-6 Trying to prevent tunnel_handler_ua from being called twice. Update: This patch has been run in a production environment for 3 hours so far. The key change between this patch and the previous patch was a changed in HttpTunnel::consumer_handler. In the case of a final event (e.g. write complete, eos, error, timeout), the original code was setting the final callback to execute, but this caused assertion failures in HttpSM::tunnel_handler_post_or_put() if p-handler_state was 0. Earlier versions of the patch would avoid setting the callback flag if p-handler_state was 0. This avoided the assert, but apparently caused the state machine to leak. This patch updated the logic to set the p-handler_state flag if it was not already set. It chooses a value based on the event and the c-vc_type. was (Author: shinrich): ts-3105-master-6 Trying to prevent tunnel_handler_ua from being called twice. Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond Key: TS-3105 URL: https://issues.apache.org/jira/browse/TS-3105 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 Attachments: ts-3073-and-3084-and-3105-against-510.patch, ts-3105-master-6.patch These two patches were run in a production environment on top of 5.0.1 without problem for several weeks. Now running with these patches on top of 5.1 causes either an assert or a segfault. Another person has reported the same segfault when running master in a production environment. In the assert, the handler_state of the producers is 0 (UNKNOWN) rather than a terminal state which is expected. I'm assuming either we are being directed into the terminal state from a connection that terminates too quickly. Or an event has hung around for too long and is being executed against the state machine after it has been recycled. The event is HTTP_TUNNEL_EVENT_DONE The assert stack trace is FATAL: HttpSM.cc:2632: failed assert `0` /z/bin/traffic_server - STACK TRACE: /z/lib/libtsutil.so.5(+0x25197)[0x2b8bd08dc197] /z/lib/libtsutil.so.5(+0x23def)[0x2b8bd08dadef] /z/bin/traffic_server(HttpSM::tunnel_handler_post_or_put(HttpTunnelProducer*)+0xcd)[0x5982ad] /z/bin/traffic_server(HttpSM::tunnel_handler_post(int, void*)+0x86)[0x5a32d6] /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5a1e18] /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0xee)[0x5dd6ae] /z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, EThread*)+0x136e)[0x721d1e] /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x28c)[0x7162fc] /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] /z/bin/traffic_server(EThread::execute()+0x4fc)[0x7458ac] /z/bin/traffic_server[0x7440ca] /lib64/libpthread.so.0(+0x7034)[0x2b8bd1ee4034] /lib64/libc.so.6(clone+0x6d)[0x2b8bd2c2875d] The segfault stack trace is /z/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf280)[0x2abccd0d8280] /z/bin/traffic_server(HttpSM::tunnel_handler_ua(int, HttpTunnelConsumer*)+0x122)[0x591462] /z/bin/traffic_server(HttpTunnel::consumer_handler(int, HttpTunnelConsumer*)+0x9e)[0x5dd15e] /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x117)[0x5dd6d7] /z/bin/traffic_server(UnixNetVConnection::mainEvent(int, Event*)+0x3f0)[0x725190] /z/bin/traffic_server(InactivityCop::check_inactivity(int, Event*)+0x275)[0x716b75] /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] /z/bin/traffic_server(EThread::execute()+0x2fb)[0x7456ab] /z/bin/traffic_server[0x7440ca] /lib64/libpthread.so.0(+0x7034)[0x2abccd0d0034] /lib64/libc.so.6(clone+0x6d)[0x2abccde1475d] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3156) Mutex[Try]Lock bool() operator change and unused API removal
[
https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190270#comment-14190270
]
Alan M. Carroll commented on TS-3156:
-
Some notes -
I think changing the bool operators to a method is reasonable. Normally that's
done to check for existence via a wrapper but in this case it's checking both
existence and state, so the false case is a bit ambiguous.
Let's nuke ink_scoped_mutex if we're going to clean up other things in this
area.
Style -
{code}
/**
* Auto lock class for ProxyMutex
*/
{code}
should be
{code}
/** Auto lock class for ProxyMutex.
*/
{code}
This will make Doxygen happier.
Mutex[Try]Lock bool() operator change and unused API removal
Key: TS-3156
URL: https://issues.apache.org/jira/browse/TS-3156
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Powell Molleti
Assignee: James Peach
Priority: Minor
Labels: review
Fix For: 5.2.0
Attachments: MutexLock-ats.patch
Removed unused constructor in MutexLock along with set_and_take() method, had
to change FORCE_PLUGIN_MUTEX() for that. Removed release() method.
default bool and ! operator from both MutexLock and MutexTryLock with
is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code
base.
Ran make test will be performing more system testing. Posted before for early
comments / feedback.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3151) Segfault on background fill
[
https://issues.apache.org/jira/browse/TS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190314#comment-14190314
]
Alan M. Carroll commented on TS-3151:
-
Instead of {{get_lock}} it should be {{get_mutex}}. Given the use of the work
lock in a different context everywhere nearby, the former could easily be
mistaken.
Segfault on background fill
---
Key: TS-3151
URL: https://issues.apache.org/jira/browse/TS-3151
Project: Traffic Server
Issue Type: Bug
Reporter: Acacio Centeno
Assignee: Alan M. Carroll
On rare occasions, a background fill will fail and lead to a segfault, with
the following stacktrace:
#0 0x0060cb6d in HttpSM::tunnel_handler_ua (this=0x2aaac2bb0750,
event=104, char=0x2aaac2bb1c60) at HttpSM.cc:3171
#1 0x00652bbe in HttpTunnel::consumer_handler (this=0x2aaac2bb1b48,
event=104, char=0x2aaac2bb1c60) at HttpTunnel.cc:1294
#2 0x006532be in HttpTunnel::main_handler (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at HttpTunnel.cc:1525
#3 0x004ebc5e in Continuation::handleEvent (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at ../iocore/eventsystem/I_Continuation.h:146
#4 0x0076b140 in write_signal_and_update (event=104,
vc=0x2aab6c003560) at UnixNetVConnection.cc:153
#5 0x0076b23e in write_signal_done (event=104, nh=0x2f4e2ba0,
vc=0x2aab6c003560) at UnixNetVConnection.cc:180
#6 0x0076c047 in write_to_net_io (nh=0x2f4e2ba0,
vc=0x2aab6c003560, thread=0x2f4df010) at UnixNetVConnection.cc:471
#7 0x0076ba17 in write_to_net (nh=0x2f4e2ba0, vc=0x2aab6c003560,
thread=0x2f4df010) at UnixNetVConnection.cc:352
#8 0x00765216 in NetHandler::mainNetEvent (this=0x2f4e2ba0,
event=5, long double=0x1f87bd0) at UnixNet.cc:415
#9 0x004ebc5e in Continuation::handleEvent (this=0x2f4e2ba0,
event=5, data=0x1f87bd0) at ../iocore/eventsystem/I_Continuation.h:146
#10 0x0078beea in EThread::process_event (this=0x2f4df010, long
double=0x1f87bd0, calling_code=5) at UnixEThread.cc:145
#11 0x0078c3f4 in EThread::execute (this=0x2f4df010) at
UnixEThread.cc:269
#12 0x0078b448 in spawn_thread_internal (signed char=0x1f48c20) at
Thread.cc:88
#13 0x2c97a9d1 in start_thread () from /lib64/libpthread.so.0
#14 0x2d61c86d in clone () from /lib64/libc.so.6
This seems close to the issue reported on
https://issues.apache.org/jira/browse/TS-2705
Except that in our case, server_entry-vc-server_vc was NULL, so maybe the
appropriate solution would be to add that to the check done in
is_bg_fill_necessary, like:
if (c-producer-alive // something there to read
server_entry server_entry-vc server_entry-vc-server_vc //
from an origin server
c-producer-num_consumers 1 // with someone else reading it
) {
...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3151) Segfault on background fill
[
https://issues.apache.org/jira/browse/TS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190373#comment-14190373
]
Acácio Centeno commented on TS-3151:
Oh, yes, sorry! the correct would be server_session-get_netvc().
Segfault on background fill
---
Key: TS-3151
URL: https://issues.apache.org/jira/browse/TS-3151
Project: Traffic Server
Issue Type: Bug
Reporter: Acacio Centeno
Assignee: Alan M. Carroll
On rare occasions, a background fill will fail and lead to a segfault, with
the following stacktrace:
#0 0x0060cb6d in HttpSM::tunnel_handler_ua (this=0x2aaac2bb0750,
event=104, char=0x2aaac2bb1c60) at HttpSM.cc:3171
#1 0x00652bbe in HttpTunnel::consumer_handler (this=0x2aaac2bb1b48,
event=104, char=0x2aaac2bb1c60) at HttpTunnel.cc:1294
#2 0x006532be in HttpTunnel::main_handler (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at HttpTunnel.cc:1525
#3 0x004ebc5e in Continuation::handleEvent (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at ../iocore/eventsystem/I_Continuation.h:146
#4 0x0076b140 in write_signal_and_update (event=104,
vc=0x2aab6c003560) at UnixNetVConnection.cc:153
#5 0x0076b23e in write_signal_done (event=104, nh=0x2f4e2ba0,
vc=0x2aab6c003560) at UnixNetVConnection.cc:180
#6 0x0076c047 in write_to_net_io (nh=0x2f4e2ba0,
vc=0x2aab6c003560, thread=0x2f4df010) at UnixNetVConnection.cc:471
#7 0x0076ba17 in write_to_net (nh=0x2f4e2ba0, vc=0x2aab6c003560,
thread=0x2f4df010) at UnixNetVConnection.cc:352
#8 0x00765216 in NetHandler::mainNetEvent (this=0x2f4e2ba0,
event=5, long double=0x1f87bd0) at UnixNet.cc:415
#9 0x004ebc5e in Continuation::handleEvent (this=0x2f4e2ba0,
event=5, data=0x1f87bd0) at ../iocore/eventsystem/I_Continuation.h:146
#10 0x0078beea in EThread::process_event (this=0x2f4df010, long
double=0x1f87bd0, calling_code=5) at UnixEThread.cc:145
#11 0x0078c3f4 in EThread::execute (this=0x2f4df010) at
UnixEThread.cc:269
#12 0x0078b448 in spawn_thread_internal (signed char=0x1f48c20) at
Thread.cc:88
#13 0x2c97a9d1 in start_thread () from /lib64/libpthread.so.0
#14 0x2d61c86d in clone () from /lib64/libc.so.6
This seems close to the issue reported on
https://issues.apache.org/jira/browse/TS-2705
Except that in our case, server_entry-vc-server_vc was NULL, so maybe the
appropriate solution would be to add that to the check done in
is_bg_fill_necessary, like:
if (c-producer-alive // something there to read
server_entry server_entry-vc server_entry-vc-server_vc //
from an origin server
c-producer-num_consumers 1 // with someone else reading it
) {
...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (TS-3151) Segfault on background fill
[
https://issues.apache.org/jira/browse/TS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-3151:
Comment: was deleted
(was: Instead of {{get_lock}} it should be {{get_mutex}}. Given the use of the
work lock in a different context everywhere nearby, the former could easily
be mistaken.)
Segfault on background fill
---
Key: TS-3151
URL: https://issues.apache.org/jira/browse/TS-3151
Project: Traffic Server
Issue Type: Bug
Reporter: Acacio Centeno
Assignee: Alan M. Carroll
On rare occasions, a background fill will fail and lead to a segfault, with
the following stacktrace:
#0 0x0060cb6d in HttpSM::tunnel_handler_ua (this=0x2aaac2bb0750,
event=104, char=0x2aaac2bb1c60) at HttpSM.cc:3171
#1 0x00652bbe in HttpTunnel::consumer_handler (this=0x2aaac2bb1b48,
event=104, char=0x2aaac2bb1c60) at HttpTunnel.cc:1294
#2 0x006532be in HttpTunnel::main_handler (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at HttpTunnel.cc:1525
#3 0x004ebc5e in Continuation::handleEvent (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at ../iocore/eventsystem/I_Continuation.h:146
#4 0x0076b140 in write_signal_and_update (event=104,
vc=0x2aab6c003560) at UnixNetVConnection.cc:153
#5 0x0076b23e in write_signal_done (event=104, nh=0x2f4e2ba0,
vc=0x2aab6c003560) at UnixNetVConnection.cc:180
#6 0x0076c047 in write_to_net_io (nh=0x2f4e2ba0,
vc=0x2aab6c003560, thread=0x2f4df010) at UnixNetVConnection.cc:471
#7 0x0076ba17 in write_to_net (nh=0x2f4e2ba0, vc=0x2aab6c003560,
thread=0x2f4df010) at UnixNetVConnection.cc:352
#8 0x00765216 in NetHandler::mainNetEvent (this=0x2f4e2ba0,
event=5, long double=0x1f87bd0) at UnixNet.cc:415
#9 0x004ebc5e in Continuation::handleEvent (this=0x2f4e2ba0,
event=5, data=0x1f87bd0) at ../iocore/eventsystem/I_Continuation.h:146
#10 0x0078beea in EThread::process_event (this=0x2f4df010, long
double=0x1f87bd0, calling_code=5) at UnixEThread.cc:145
#11 0x0078c3f4 in EThread::execute (this=0x2f4df010) at
UnixEThread.cc:269
#12 0x0078b448 in spawn_thread_internal (signed char=0x1f48c20) at
Thread.cc:88
#13 0x2c97a9d1 in start_thread () from /lib64/libpthread.so.0
#14 0x2d61c86d in clone () from /lib64/libc.so.6
This seems close to the issue reported on
https://issues.apache.org/jira/browse/TS-2705
Except that in our case, server_entry-vc-server_vc was NULL, so maybe the
appropriate solution would be to add that to the check done in
is_bg_fill_necessary, like:
if (c-producer-alive // something there to read
server_entry server_entry-vc server_entry-vc-server_vc //
from an origin server
c-producer-num_consumers 1 // with someone else reading it
) {
...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3156) Mutex[Try]Lock bool() operator change and unused API removal
[
https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190379#comment-14190379
]
Alan M. Carroll commented on TS-3156:
-
Instead of {{get_lock}} it should be {{get_mutex}}. Given the use of the work
lock in a different context everywhere nearby, the former could easily be
mistaken.
Mutex[Try]Lock bool() operator change and unused API removal
Key: TS-3156
URL: https://issues.apache.org/jira/browse/TS-3156
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Powell Molleti
Assignee: James Peach
Priority: Minor
Labels: review
Fix For: 5.2.0
Attachments: MutexLock-ats.patch
Removed unused constructor in MutexLock along with set_and_take() method, had
to change FORCE_PLUGIN_MUTEX() for that. Removed release() method.
default bool and ! operator from both MutexLock and MutexTryLock with
is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code
base.
Ran make test will be performing more system testing. Posted before for early
comments / feedback.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3151) Segfault on background fill
[
https://issues.apache.org/jira/browse/TS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-3151.
-
Resolution: Fixed
Segfault on background fill
---
Key: TS-3151
URL: https://issues.apache.org/jira/browse/TS-3151
Project: Traffic Server
Issue Type: Bug
Reporter: Acacio Centeno
Assignee: Alan M. Carroll
On rare occasions, a background fill will fail and lead to a segfault, with
the following stacktrace:
#0 0x0060cb6d in HttpSM::tunnel_handler_ua (this=0x2aaac2bb0750,
event=104, char=0x2aaac2bb1c60) at HttpSM.cc:3171
#1 0x00652bbe in HttpTunnel::consumer_handler (this=0x2aaac2bb1b48,
event=104, char=0x2aaac2bb1c60) at HttpTunnel.cc:1294
#2 0x006532be in HttpTunnel::main_handler (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at HttpTunnel.cc:1525
#3 0x004ebc5e in Continuation::handleEvent (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at ../iocore/eventsystem/I_Continuation.h:146
#4 0x0076b140 in write_signal_and_update (event=104,
vc=0x2aab6c003560) at UnixNetVConnection.cc:153
#5 0x0076b23e in write_signal_done (event=104, nh=0x2f4e2ba0,
vc=0x2aab6c003560) at UnixNetVConnection.cc:180
#6 0x0076c047 in write_to_net_io (nh=0x2f4e2ba0,
vc=0x2aab6c003560, thread=0x2f4df010) at UnixNetVConnection.cc:471
#7 0x0076ba17 in write_to_net (nh=0x2f4e2ba0, vc=0x2aab6c003560,
thread=0x2f4df010) at UnixNetVConnection.cc:352
#8 0x00765216 in NetHandler::mainNetEvent (this=0x2f4e2ba0,
event=5, long double=0x1f87bd0) at UnixNet.cc:415
#9 0x004ebc5e in Continuation::handleEvent (this=0x2f4e2ba0,
event=5, data=0x1f87bd0) at ../iocore/eventsystem/I_Continuation.h:146
#10 0x0078beea in EThread::process_event (this=0x2f4df010, long
double=0x1f87bd0, calling_code=5) at UnixEThread.cc:145
#11 0x0078c3f4 in EThread::execute (this=0x2f4df010) at
UnixEThread.cc:269
#12 0x0078b448 in spawn_thread_internal (signed char=0x1f48c20) at
Thread.cc:88
#13 0x2c97a9d1 in start_thread () from /lib64/libpthread.so.0
#14 0x2d61c86d in clone () from /lib64/libc.so.6
This seems close to the issue reported on
https://issues.apache.org/jira/browse/TS-2705
Except that in our case, server_entry-vc-server_vc was NULL, so maybe the
appropriate solution would be to add that to the check done in
is_bg_fill_necessary, like:
if (c-producer-alive // something there to read
server_entry server_entry-vc server_entry-vc-server_vc //
from an origin server
c-producer-num_consumers 1 // with someone else reading it
) {
...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3156) Mutex[Try]Lock bool() operator change and unused API removal
[ https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190538#comment-14190538 ] James Peach commented on TS-3156: - Thanks @amc, I'll merge after these changes. Mutex[Try]Lock bool() operator change and unused API removal Key: TS-3156 URL: https://issues.apache.org/jira/browse/TS-3156 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Powell Molleti Assignee: James Peach Priority: Minor Labels: review Fix For: 5.2.0 Attachments: MutexLock-ats.patch Removed unused constructor in MutexLock along with set_and_take() method, had to change FORCE_PLUGIN_MUTEX() for that. Removed release() method. default bool and ! operator from both MutexLock and MutexTryLock with is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code base. Ran make test will be performing more system testing. Posted before for early comments / feedback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3156) Mutex[Try]Lock bool() operator change and unused API removal
[ https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190661#comment-14190661 ] Powell Molleti commented on TS-3156: Hi James, are you going to make the changes or should I? I started to address Alan's suggestions. Mutex[Try]Lock bool() operator change and unused API removal Key: TS-3156 URL: https://issues.apache.org/jira/browse/TS-3156 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Powell Molleti Assignee: James Peach Priority: Minor Labels: review Fix For: 5.2.0 Attachments: MutexLock-ats.patch Removed unused constructor in MutexLock along with set_and_take() method, had to change FORCE_PLUGIN_MUTEX() for that. Removed release() method. default bool and ! operator from both MutexLock and MutexTryLock with is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code base. Ran make test will be performing more system testing. Posted before for early comments / feedback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3149) Move Via decoder out of traffic_line, and make a separate traffic_via tool
[ https://issues.apache.org/jira/browse/TS-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190684#comment-14190684 ] ASF GitHub Bot commented on TS-3149: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/133 Move Via decoder out of traffic_line, and make a separate traffic_via tool -- Key: TS-3149 URL: https://issues.apache.org/jira/browse/TS-3149 Project: Traffic Server Issue Type: New Feature Components: Management API, Tools Reporter: Meera Mosale Nataraja Assignee: James Peach Fix For: 5.2.0 Move Via decoder out of traffic_line, and make a separate traffic_via tool traffic_line requires traffic_manger to be running. Hence move via decoder out of traffic_line to make via decoder tool independent of traffic_manager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2417) Add forward secrecy support with DHE (SSL related)
[ https://issues.apache.org/jira/browse/TS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190826#comment-14190826 ] Leif Hedstrom commented on TS-2417: --- [~shinrich] Can you review John's patch please? Add forward secrecy support with DHE (SSL related) -- Key: TS-2417 URL: https://issues.apache.org/jira/browse/TS-2417 Project: Traffic Server Issue Type: Improvement Components: HTTP, SSL Reporter: Bryan Call Assignee: John Eaglesham Fix For: sometime Attachments: ats_dhe-2.patch mod_ssl bug and changes: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Discussion on httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2683) Add some control for which content to activate the background_fetch plugin
[ https://issues.apache.org/jira/browse/TS-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-2683: - Assignee: Sudheer Vinukonda Add some control for which content to activate the background_fetch plugin -- Key: TS-2683 URL: https://issues.apache.org/jira/browse/TS-2683 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Sudheer Vinukonda Fix For: sometime This would be both in global and per-remap configurations. Such as, only trigger background_fetch for certain content types. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2682) Add per remap configuration / activation to background_fetch
[ https://issues.apache.org/jira/browse/TS-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-2682: - Assignee: Sudheer Vinukonda (was: Leif Hedstrom) Add per remap configuration / activation to background_fetch Key: TS-2682 URL: https://issues.apache.org/jira/browse/TS-2682 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Sudheer Vinukonda Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2683) Add some control for which content to activate the background_fetch plugin
[ https://issues.apache.org/jira/browse/TS-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190872#comment-14190872 ] Sudheer Vinukonda commented on TS-2683: --- Enhanced the plugin to support the below exclusion criteria to start: The plugin now supports a config file that can specify exclusion of background fetch based on the below criteria: 1. Client-Ip 2. Content-Type 3. User-Agent To specify the exclusion criteria, the plugin needs to be activated as below with: client-ip, user-agent, content-type. Activation: background_fetch.so relative-path-to-install-dir/config-file The contents of the config-file could be as below: Client-Ip 127.0.0.1 User-Agent ABCDEF Content-Type text Add some control for which content to activate the background_fetch plugin -- Key: TS-2683 URL: https://issues.apache.org/jira/browse/TS-2683 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Sudheer Vinukonda Fix For: sometime This would be both in global and per-remap configurations. Such as, only trigger background_fetch for certain content types. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-2683) Add some control for which content to activate the background_fetch plugin
[ https://issues.apache.org/jira/browse/TS-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190872#comment-14190872 ] Sudheer Vinukonda edited comment on TS-2683 at 10/30/14 9:27 PM: - Enhanced the plugin to support a config file that can specify exclusion of background fetch based on the below criteria: 1. Client-Ip 2. Content-Type 3. User-Agent To specify the exclusion criteria, the plugin needs to be activated as below with: background_fetch.so --config relative-path-to-install-dir/config-file The contents of the config-file could be as below: Client-Ip 127.0.0.1 User-Agent ABCDEF Content-Type text was (Author: sudheerv): Enhanced the plugin to support the below exclusion criteria to start: The plugin now supports a config file that can specify exclusion of background fetch based on the below criteria: 1. Client-Ip 2. Content-Type 3. User-Agent To specify the exclusion criteria, the plugin needs to be activated as below with: client-ip, user-agent, content-type. Activation: background_fetch.so relative-path-to-install-dir/config-file The contents of the config-file could be as below: Client-Ip 127.0.0.1 User-Agent ABCDEF Content-Type text Add some control for which content to activate the background_fetch plugin -- Key: TS-2683 URL: https://issues.apache.org/jira/browse/TS-2683 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Sudheer Vinukonda Fix For: sometime This would be both in global and per-remap configurations. Such as, only trigger background_fetch for certain content types. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2682) Add per remap configuration / activation to background_fetch
[ https://issues.apache.org/jira/browse/TS-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14191021#comment-14191021 ] Sudheer Vinukonda commented on TS-2682: --- Added per-remap support for background_fetch plugin. To activate the plugin per-remap, simply append the below to the specific remap rule: @plugin=background_fetch.so @pparam=relative-path-to-install-dir/config-file Add per remap configuration / activation to background_fetch Key: TS-2682 URL: https://issues.apache.org/jira/browse/TS-2682 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Sudheer Vinukonda Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
