[jira] [Commented] (TS-758) HostDB fails to insert RR entries (allocation fails) claiming DB is full
[
https://issues.apache.org/jira/browse/TS-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492139#comment-14492139
]
Greg O'Rawe commented on TS-758:
I am seeing this problem on a customer deployment, and the hostdb allocates
memory for DNS entries which return multiple IP addresses as described.
However, if an entry is added to the hostdb and a request is made to that
domain after the TTL has expired, heap memory is allocated again for the same
domain which already exists in the table. The entry itself is removed and
re-inserted, but there is a further immediate allocation for any round-robin
data returned. The memory steadily grows (e.g. by 160 bytes each time). This
looks like a bug. It is version 3.2.0 being used here, but I don't think the
code has changed in later versions. If the entry already exists in the hostdb
but the TTL has expired, then surely there should not be another allocation for
the same round robin entries after the DNS lookup?
Greg
> HostDB fails to insert RR entries (allocation fails) claiming DB is full
>
>
> Key: TS-758
> URL: https://issues.apache.org/jira/browse/TS-758
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Affects Versions: 2.1.8
>Reporter: Leif Hedstrom
>
> After running in forward proxy for a few days, I got a bunch of these errors:
> [May 3 17:13:11.574] Server {140488838387680} WARNING: out of room in hostdb
> for round-robin DNS data
> [May 3 17:13:11.726] Server {140488838387680} WARNING: out of room in hostdb
> for round-robin DNS data
> [May 3 17:13:11.736] Server {140488838387680} WARNING: out of room in hostdb
> for round-robin DNS data
> [May 3 17:13:14.072] Server {140488821982992} WARNING: out of room in hostdb
> for round-robin DNS data
> [May 3 17:13:17.114] Server {140488838387680} WARNING: out of room in hostdb
> for round-robin DNS data
> I'm not sure why it thinks it's out of room, there is no way I've filled my
> hostdb cache (I'm fairly certain). I'm not able to reproduce the problem
> (easily).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492503#comment-14492503
]
Bryan Call commented on TS-3513:
I tracked down the place where the cursor is going beyond end:
{code}
case HPACK_FIELD_NEVERINDEX_LITERAL:
read_bytes = decode_literal_header_field(header, cursor, buf_end,
dynamic_table);
if (read_bytes == HPACK_ERROR_COMPRESSION_ERROR) {
if (cont) {
// Parsing a part of headers is done
return cursor - buf_start;
} else {
// Parse error
return HPACK_ERROR_COMPRESSION_ERROR;
}
}
cursor += read_bytes;
assert(cursor <= buf_end);
break;
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492503#comment-14492503
]
Bryan Call edited comment on TS-3513 at 4/13/15 3:22 PM:
-
I tracked down the place where the cursor is going beyond end:
{code}
case HPACK_FIELD_NEVERINDEX_LITERAL:
read_bytes = decode_literal_header_field(header, cursor, buf_end,
dynamic_table);
if (read_bytes == HPACK_ERROR_COMPRESSION_ERROR) {
if (cont) {
// Parsing a part of headers is done
return cursor - buf_start;
} else {
// Parse error
return HPACK_ERROR_COMPRESSION_ERROR;
}
}
cursor += read_bytes;
assert(cursor <= buf_end); <--- this asserted
break;
{code}
was (Author: bcall):
I tracked down the place where the cursor is going beyond end:
{code}
case HPACK_FIELD_NEVERINDEX_LITERAL:
read_bytes = decode_literal_header_field(header, cursor, buf_end,
dynamic_table);
if (read_bytes == HPACK_ERROR_COMPRESSION_ERROR) {
if (cont) {
// Parsing a part of headers is done
return cursor - buf_start;
} else {
// Parse error
return HPACK_ERROR_COMPRESSION_ERROR;
}
}
cursor += read_bytes;
assert(cursor <= buf_end);
break;
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492503#comment-14492503
]
Bryan Call edited comment on TS-3513 at 4/13/15 3:26 PM:
-
I tracked down the place where the cursor is going beyond end:
{code}
case HPACK_FIELD_NEVERINDEX_LITERAL:
read_bytes = decode_literal_header_field(header, cursor, buf_end,
dynamic_table);
if (read_bytes == HPACK_ERROR_COMPRESSION_ERROR) {
if (cont) {
// Parsing a part of headers is done
return cursor - buf_start;
} else {
// Parse error
return HPACK_ERROR_COMPRESSION_ERROR;
}
}
cursor += read_bytes;
assert(cursor <= buf_end); <--- this asserted
break;
(gdb) p cursor - buf_end
$3 = 2
{code}
was (Author: bcall):
I tracked down the place where the cursor is going beyond end:
{code}
case HPACK_FIELD_NEVERINDEX_LITERAL:
read_bytes = decode_literal_header_field(header, cursor, buf_end,
dynamic_table);
if (read_bytes == HPACK_ERROR_COMPRESSION_ERROR) {
if (cont) {
// Parsing a part of headers is done
return cursor - buf_start;
} else {
// Parse error
return HPACK_ERROR_COMPRESSION_ERROR;
}
}
cursor += read_bytes;
assert(cursor <= buf_end); <--- this asserted
break;
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1774) Make ink_hrtime_get() in Thread.cc member of the Thread class
[ https://issues.apache.org/jira/browse/TS-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492512#comment-14492512 ] ASF GitHub Bot commented on TS-1774: Github user jpeach commented on the pull request: https://github.com/apache/trafficserver/pull/185#issuecomment-92401379 Doe we even need the new Thread APIs? Can we just use Thread::cur_time directly? > Make ink_hrtime_get() in Thread.cc member of the Thread class > - > > Key: TS-1774 > URL: https://issues.apache.org/jira/browse/TS-1774 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > Labels: newbie > Fix For: 6.0.0 > > > It's somewhat confusing that e..g ink_get_hrtime() is not a member of the > Thread class, yet, relies on Thread::cur_time. Why is that ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1774) Make ink_hrtime_get() in Thread.cc member of the Thread class
[ https://issues.apache.org/jira/browse/TS-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492522#comment-14492522 ] ASF GitHub Bot commented on TS-1774: Github user SolidWallOfCode commented on the pull request: https://github.com/apache/trafficserver/pull/185#issuecomment-92403352 Isolation and modularity? It seems better to discuss this on the original bug - it's not really a problem with the pull request. > Make ink_hrtime_get() in Thread.cc member of the Thread class > - > > Key: TS-1774 > URL: https://issues.apache.org/jira/browse/TS-1774 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > Labels: newbie > Fix For: 6.0.0 > > > It's somewhat confusing that e..g ink_get_hrtime() is not a member of the > Thread class, yet, relies on Thread::cur_time. Why is that ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492634#comment-14492634
]
Bryan Call commented on TS-3513:
Tracked it down inside of decode_literal_header_field():
{code}
// Decode header field value
char *value_str = NULL;
uint32_t value_str_len = 0;
len = decode_string(arena, &value_str, value_str_len, p, buf_end);
if (len == HPACK_ERROR_COMPRESSION_ERROR)
return HPACK_ERROR_COMPRESSION_ERROR;
p += len;
assert(p <= buf_end); <--- this asserted
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492681#comment-14492681
]
Bryan Call commented on TS-3513:
It looks like the problem is in decode_string() when detecting a compression
error:
{code}
const uint8_t *p = buf_start;
bool isHuffman = *p & 0x80;
uint32_t encoded_string_len = 0;
int64_t len = 0;
len = decode_integer(encoded_string_len, p, buf_end, 7);
if (len == HPACK_ERROR_COMPRESSION_ERROR)
return HPACK_ERROR_COMPRESSION_ERROR;
p += len;
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || buf_start +
encoded_string_len >= buf_end) { <--- encoded_string_len should be 0 and
buf_start will always be less ehtne buf_end
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492681#comment-14492681
]
Bryan Call edited comment on TS-3513 at 4/13/15 5:15 PM:
-
It looks like the problem is in decode_string() when detecting a compression
error:
{code}
const uint8_t *p = buf_start;
bool isHuffman = *p & 0x80;
uint32_t encoded_string_len = 0;
int64_t len = 0;
len = decode_integer(encoded_string_len, p, buf_end, 7);
if (len == HPACK_ERROR_COMPRESSION_ERROR)
return HPACK_ERROR_COMPRESSION_ERROR;
p += len;
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || buf_start +
encoded_string_len >= buf_end) { <--- encoded_string_len is always 0 and
buf_start will always be less than buf_end, so this conditional will always be
false
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
was (Author: bcall):
It looks like the problem is in decode_string() when detecting a compression
error:
{code}
const uint8_t *p = buf_start;
bool isHuffman = *p & 0x80;
uint32_t encoded_string_len = 0;
int64_t len = 0;
len = decode_integer(encoded_string_len, p, buf_end, 7);
if (len == HPACK_ERROR_COMPRESSION_ERROR)
return HPACK_ERROR_COMPRESSION_ERROR;
p += len;
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || buf_start +
encoded_string_len >= buf_end) { <--- encoded_string_len should be 0 and
buf_start will always be less than buf_end, so this conditional will always be
false
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492681#comment-14492681
]
Bryan Call edited comment on TS-3513 at 4/13/15 5:18 PM:
-
It looks like the problem is in decode_string() when detecting a compression
error:
{code}
const uint8_t *p = buf_start;
bool isHuffman = *p & 0x80;
uint32_t encoded_string_len = 0;
int64_t len = 0;
len = decode_integer(encoded_string_len, p, buf_end, 7);
if (len == HPACK_ERROR_COMPRESSION_ERROR)
return HPACK_ERROR_COMPRESSION_ERROR;
p += len;
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || buf_start +
encoded_string_len >= buf_end) { <--- should be p + encoded_string_len >=
buf_end
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
was (Author: bcall):
It looks like the problem is in decode_string() when detecting a compression
error:
{code}
const uint8_t *p = buf_start;
bool isHuffman = *p & 0x80;
uint32_t encoded_string_len = 0;
int64_t len = 0;
len = decode_integer(encoded_string_len, p, buf_end, 7);
if (len == HPACK_ERROR_COMPRESSION_ERROR)
return HPACK_ERROR_COMPRESSION_ERROR;
p += len;
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || buf_start +
encoded_string_len >= buf_end) { <--- encoded_string_len is always 0 and
buf_start will always be less than buf_end, so this conditional will always be
false
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492681#comment-14492681
]
Bryan Call edited comment on TS-3513 at 4/13/15 5:14 PM:
-
It looks like the problem is in decode_string() when detecting a compression
error:
{code}
const uint8_t *p = buf_start;
bool isHuffman = *p & 0x80;
uint32_t encoded_string_len = 0;
int64_t len = 0;
len = decode_integer(encoded_string_len, p, buf_end, 7);
if (len == HPACK_ERROR_COMPRESSION_ERROR)
return HPACK_ERROR_COMPRESSION_ERROR;
p += len;
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || buf_start +
encoded_string_len >= buf_end) { <--- encoded_string_len should be 0 and
buf_start will always be less than buf_end, so this conditional will always be
false
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
was (Author: bcall):
It looks like the problem is in decode_string() when detecting a compression
error:
{code}
const uint8_t *p = buf_start;
bool isHuffman = *p & 0x80;
uint32_t encoded_string_len = 0;
int64_t len = 0;
len = decode_integer(encoded_string_len, p, buf_end, 7);
if (len == HPACK_ERROR_COMPRESSION_ERROR)
return HPACK_ERROR_COMPRESSION_ERROR;
p += len;
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || buf_start +
encoded_string_len >= buf_end) { <--- encoded_string_len should be 0 and
buf_start will always be less ehtne buf_end
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3302) Build failure on FreeBSD11
[
https://issues.apache.org/jira/browse/TS-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492943#comment-14492943
]
Felix Buenemann commented on TS-3302:
-
It is already fixed on 5.3.x and master, I backported the fix for the 5.2.1
homebrew formula.
Felix Bünemann
> Build failure on FreeBSD11
> --
>
> Key: TS-3302
> URL: https://issues.apache.org/jira/browse/TS-3302
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Critical
> Fix For: 5.3.0
>
>
> {code}
> gmake[2]: Entering directory '/usr/home/leif/apache/trafficserver/iocore/net'
> CXX Connection.o
> In file included from Connection.cc:32:
> In file included from ./P_Net.h:102:
> In file included from ./P_Socks.h:30:
> In file included from ../../proxy/ParentSelection.h:37:
> In file included from ../../proxy/ControlMatcher.h:91:
> In file included from ../../lib/ts/IpMap.h:8:
> ../../lib/ts/IntrusiveDList.h:121:18: error: reference to
> 'bidirectional_iterator_tag' is ambiguous
> typedef std::bidirectional_iterator_tag iterator_category;
> ^
> /usr/include/c++/v1/iterator:353:30: note: candidate found by name lookup is
> 'std::__1::bidirectional_iterator_tag'
> struct _LIBCPP_TYPE_VIS_ONLY bidirectional_iterator_tag : public
> forward_iterator_tag {};
> ^
> ../../lib/ts/IntrusiveDList.h:49:10: note: candidate found by name lookup is
> 'std::bidirectional_iterator_tag'
> struct bidirectional_iterator_tag;
> ^
> In file included from Connection.cc:32:
> In file included from ./P_Net.h:102:
> In file included from ./P_Socks.h:30:
> In file included from ../../proxy/ParentSelection.h:37:
> In file included from ../../proxy/ControlMatcher.h:91:
> ../../lib/ts/IpMap.h:140:18: error: reference to 'bidirectional_iterator_tag'
> is ambiguous
> typedef std::bidirectional_iterator_tag iterator_category;
> ^
> /usr/include/c++/v1/iterator:353:30: note: candidate found by name lookup is
> 'std::__1::bidirectional_iterator_tag'
> struct _LIBCPP_TYPE_VIS_ONLY bidirectional_iterator_tag : public
> forward_iterator_tag {};
> ^
> ../../lib/ts/IntrusiveDList.h:49:10: note: candidate found by name lookup is
> 'std::bidirectional_iterator_tag'
> struct bidirectional_iterator_tag;
> ^
> 2 errors generated.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492954#comment-14492954
]
Bryan Call commented on TS-3513:
I change the code above and I am getting a lot of compression errors:
Code Change:
{code}
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || (p +
encoded_string_len) > buf_end) {
Error("HPACK eror ran over the buffer: len: %lld over by: %lld buf size:
%lld", len, (p + encoded_string_len) - buf_end, buf_end - buf_start);
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
Logs:
{code}
[Apr 13 19:40:51.933] Server {0x2b50be120700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 367 buf size: 1002
[Apr 13 19:40:51.933] Server {0x2b50be120700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 40 buf size: 1002
[Apr 13 19:40:52.096] Server {0x2b50be625700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 548 buf size: 887
[Apr 13 19:40:52.241] Server {0x2b50bc706700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 130 buf size: 1002
[Apr 13 19:40:52.259] Server {0x2b50bc403700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 85 buf size: 1002
[Apr 13 19:40:52.778] Server {0x2b50bc403700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 321 buf size: 1002
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492954#comment-14492954
]
Bryan Call edited comment on TS-3513 at 4/13/15 8:16 PM:
-
I change the code above and I am getting a lot of compression errors:
Code Change:
{code}
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || (p +
encoded_string_len) > buf_end) {
Error("HPACK error ran over the buffer - len: %lld encoded_string_len: %u
over_by: %ld buf size: %ld",
len, encoded_string_len, (p + encoded_string_len) - buf_end, buf_end -
buf_start);
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
Logs:
{code}
[Apr 13 20:16:00.064] Server {0x2b2464241700} ERROR: HPACK error ran over the
buffer - len: 3 encoded_string_len: 1366 over_by: 367 buf size: 1002
[Apr 13 20:16:00.065] Server {0x2b2464241700} ERROR: HPACK error ran over the
buffer - len: 3 encoded_string_len: 1039 over_by: 40 buf size: 1002
[Apr 13 20:16:00.370] Server {0x2b2464342700} ERROR: HPACK error ran over the
buffer - len: 3 encoded_string_len: 1428 over_by: 460 buf size: 971
{code}
was (Author: bcall):
I change the code above and I am getting a lot of compression errors:
Code Change:
{code}
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || (p +
encoded_string_len) > buf_end) {
Error("HPACK eror ran over the buffer: len: %lld over by: %lld buf size:
%lld", len, (p + encoded_string_len) - buf_end, buf_end - buf_start);
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
Logs:
{code}
[Apr 13 19:40:51.933] Server {0x2b50be120700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 367 buf size: 1002
[Apr 13 19:40:51.933] Server {0x2b50be120700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 40 buf size: 1002
[Apr 13 19:40:52.096] Server {0x2b50be625700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 548 buf size: 887
[Apr 13 19:40:52.241] Server {0x2b50bc706700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 130 buf size: 1002
[Apr 13 19:40:52.259] Server {0x2b50bc403700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 85 buf size: 1002
[Apr 13 19:40:52.778] Server {0x2b50bc403700} ERROR: HPACK eror ran over the
buffer: len: 3 over by: 321 buf size: 1002
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492954#comment-14492954
]
Bryan Call edited comment on TS-3513 at 4/13/15 8:18 PM:
-
I changed the code above and I am getting a lot of compression errors:
Code Change:
{code}
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || (p +
encoded_string_len) > buf_end) {
Error("HPACK error ran over the buffer - len: %lld encoded_string_len: %u
over_by: %ld buf size: %ld",
len, encoded_string_len, (p + encoded_string_len) - buf_end, buf_end -
buf_start);
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
Logs:
{code}
[Apr 13 20:16:00.064] Server {0x2b2464241700} ERROR: HPACK error ran over the
buffer - len: 3 encoded_string_len: 1366 over_by: 367 buf size: 1002
[Apr 13 20:16:00.065] Server {0x2b2464241700} ERROR: HPACK error ran over the
buffer - len: 3 encoded_string_len: 1039 over_by: 40 buf size: 1002
[Apr 13 20:16:00.370] Server {0x2b2464342700} ERROR: HPACK error ran over the
buffer - len: 3 encoded_string_len: 1428 over_by: 460 buf size: 971
{code}
was (Author: bcall):
I change the code above and I am getting a lot of compression errors:
Code Change:
{code}
if (encoded_string_len > HEADER_FIELD_LIMIT_LENGTH || (p +
encoded_string_len) > buf_end) {
Error("HPACK error ran over the buffer - len: %lld encoded_string_len: %u
over_by: %ld buf size: %ld",
len, encoded_string_len, (p + encoded_string_len) - buf_end, buf_end -
buf_start);
return HPACK_ERROR_COMPRESSION_ERROR;
}
{code}
Logs:
{code}
[Apr 13 20:16:00.064] Server {0x2b2464241700} ERROR: HPACK error ran over the
buffer - len: 3 encoded_string_len: 1366 over_by: 367 buf size: 1002
[Apr 13 20:16:00.065] Server {0x2b2464241700} ERROR: HPACK error ran over the
buffer - len: 3 encoded_string_len: 1039 over_by: 40 buf size: 1002
[Apr 13 20:16:00.370] Server {0x2b2464342700} ERROR: HPACK error ran over the
buffer - len: 3 encoded_string_len: 1428 over_by: 460 buf size: 971
{code}
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3518) Multiple ssl_ca_name's in ssl_multicert breaks all intermediate CAs
Thomas Jackson created TS-3518:
--
Summary: Multiple ssl_ca_name's in ssl_multicert breaks all
intermediate CAs
Key: TS-3518
URL: https://issues.apache.org/jira/browse/TS-3518
Project: Traffic Server
Issue Type: Bug
Reporter: Thomas Jackson
In ssl_multicert you can specify multiple ssl_cert_name and ssl_key_name, such
as:
{code}
dest_ip=127.0.0.2 ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
{code}
Sometimes you need to specify an intermediate CA (a lot of the time TBH), which
from the docs sounds like you should be able to do:
{code}
dest_ip=127.0.0.2 ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
ssl_ca_name=RSA_intermediate,ECDSA,intermediate
{code}
Since you can specify ssl_ca_name for single certs, similar to cert_name and
key_name, but this currently doesn't work. In addition to not working for ECDSA
this seems to actually break *all* intermediate CAs from being served. I've
created a test case (https://github.com/apache/trafficserver/pull/186) which
shows the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3518) Multiple ssl_ca_name's in ssl_multicert breaks all intermediate CAs
[
https://issues.apache.org/jira/browse/TS-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Jackson reassigned TS-3518:
--
Assignee: Brian Geffon
> Multiple ssl_ca_name's in ssl_multicert breaks all intermediate CAs
> ---
>
> Key: TS-3518
> URL: https://issues.apache.org/jira/browse/TS-3518
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Brian Geffon
>
> In ssl_multicert you can specify multiple ssl_cert_name and ssl_key_name,
> such as:
> {code}
> dest_ip=127.0.0.2
> ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
> ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
> {code}
> Sometimes you need to specify an intermediate CA (a lot of the time TBH),
> which from the docs sounds like you should be able to do:
> {code}
> dest_ip=127.0.0.2
> ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
> ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
> ssl_ca_name=RSA_intermediate,ECDSA,intermediate
> {code}
> Since you can specify ssl_ca_name for single certs, similar to cert_name and
> key_name, but this currently doesn't work. In addition to not working for
> ECDSA this seems to actually break *all* intermediate CAs from being served.
> I've created a test case (https://github.com/apache/trafficserver/pull/186)
> which shows the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-2150) Add Milestone log tags
[
https://issues.apache.org/jira/browse/TS-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber reassigned TS-2150:
---
Assignee: John (was: Leif Hedstrom)
> Add Milestone log tags
> --
>
> Key: TS-2150
> URL: https://issues.apache.org/jira/browse/TS-2150
> Project: Traffic Server
> Issue Type: New Feature
> Components: Logging
>Reporter: Leif Hedstrom
>Assignee: John
> Fix For: 6.0.0
>
>
> We have a notion of milestones in the core, and plugin APIs
> (TSHttpTxnMilestoneGet() ). It'd be useful to expose these milestone timers
> as a log tag, something like:
> {code}
> %<{UA_BEGIN}mtms>
> {code}
> mtms is just an example / suggestion, "MilestoneTimeMilliSecond", we can make
> it whatever we like.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493040#comment-14493040
]
Bryan Call commented on TS-3513:
[~rokubo]
It looks like the return value HPACK_ERROR_COMPRESSION_ERROR is not a real
error in all the cases I was looking at it. It looks like the entire header
buffer is not there and it needs to continue.
I will commit my change and please review.
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3518) Multiple ssl_ca_name's in ssl_multicert breaks all intermediate CAs
[
https://issues.apache.org/jira/browse/TS-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Jackson updated TS-3518:
---
Description:
In ssl_multicert you can specify multiple ssl_cert_name and ssl_key_name, such
as:
{code}
dest_ip=127.0.0.2 ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
{code}
Sometimes you need to specify an intermediate CA (a lot of the time TBH), which
from the docs sounds like you should be able to do:
{code}
dest_ip=127.0.0.2 ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
ssl_ca_name=RSA_intermediate,ECDSA_intermediate
{code}
Since you can specify ssl_ca_name for single certs, similar to cert_name and
key_name, but this currently doesn't work. In addition to not working for ECDSA
this seems to actually break *all* intermediate CAs from being served. I've
created a test case (https://github.com/apache/trafficserver/pull/186) which
shows the issue.
was:
In ssl_multicert you can specify multiple ssl_cert_name and ssl_key_name, such
as:
{code}
dest_ip=127.0.0.2 ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
{code}
Sometimes you need to specify an intermediate CA (a lot of the time TBH), which
from the docs sounds like you should be able to do:
{code}
dest_ip=127.0.0.2 ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
ssl_ca_name=RSA_intermediate,ECDSA,intermediate
{code}
Since you can specify ssl_ca_name for single certs, similar to cert_name and
key_name, but this currently doesn't work. In addition to not working for ECDSA
this seems to actually break *all* intermediate CAs from being served. I've
created a test case (https://github.com/apache/trafficserver/pull/186) which
shows the issue.
> Multiple ssl_ca_name's in ssl_multicert breaks all intermediate CAs
> ---
>
> Key: TS-3518
> URL: https://issues.apache.org/jira/browse/TS-3518
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Brian Geffon
>
> In ssl_multicert you can specify multiple ssl_cert_name and ssl_key_name,
> such as:
> {code}
> dest_ip=127.0.0.2
> ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
> ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
> {code}
> Sometimes you need to specify an intermediate CA (a lot of the time TBH),
> which from the docs sounds like you should be able to do:
> {code}
> dest_ip=127.0.0.2
> ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
> ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
> ssl_ca_name=RSA_intermediate,ECDSA_intermediate
> {code}
> Since you can specify ssl_ca_name for single certs, similar to cert_name and
> key_name, but this currently doesn't work. In addition to not working for
> ECDSA this seems to actually break *all* intermediate CAs from being served.
> I've created a test case (https://github.com/apache/trafficserver/pull/186)
> which shows the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3518) Multiple ssl_ca_name's in ssl_multicert breaks all intermediate CAs
[
https://issues.apache.org/jira/browse/TS-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493157#comment-14493157
]
Susan Hinrichs commented on TS-3518:
Yes, the comma processing is currently only done for the ssl_key_name and
ssl_cert_name fields. It should be extended to the ssl_ca_field name as well.
> Multiple ssl_ca_name's in ssl_multicert breaks all intermediate CAs
> ---
>
> Key: TS-3518
> URL: https://issues.apache.org/jira/browse/TS-3518
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Brian Geffon
>
> In ssl_multicert you can specify multiple ssl_cert_name and ssl_key_name,
> such as:
> {code}
> dest_ip=127.0.0.2
> ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
> ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
> {code}
> Sometimes you need to specify an intermediate CA (a lot of the time TBH),
> which from the docs sounds like you should be able to do:
> {code}
> dest_ip=127.0.0.2
> ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
> ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
> ssl_ca_name=RSA_intermediate,ECDSA_intermediate
> {code}
> Since you can specify ssl_ca_name for single certs, similar to cert_name and
> key_name, but this currently doesn't work. In addition to not working for
> ECDSA this seems to actually break *all* intermediate CAs from being served.
> I've created a test case (https://github.com/apache/trafficserver/pull/186)
> which shows the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493167#comment-14493167
]
ASF subversion and git services commented on TS-3513:
-
Commit 661297dfae4d3a592a39249b74ef57e748b10805 in trafficserver's branch
refs/heads/5.3.x from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=661297d ]
TS-3513: HTTP/2 core dump - Fixed problem with cursor not advancing during
parsing
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493168#comment-14493168
]
ASF subversion and git services commented on TS-3513:
-
Commit 917db22c33fcdb41478e9c24ba0c09a219206ff8 in trafficserver's branch
refs/heads/5.3.x from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=917db22 ]
TS-3513: Updated CHANGES
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3438) npn list being created with garbage data
[
https://issues.apache.org/jira/browse/TS-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493170#comment-14493170
]
Sudheer Vinukonda commented on TS-3438:
---
Finally managed to generate a core when the npn list is corrupted. After
analyzing the core (basically, an assert on a hard-coded npn list's length for
34 (since, the list used in our prod is fixed -
{{"\bspdy/3.1\006spdy/3\bhttp/1.1\bhttp/1.0"}}) and it seems the npn end point
list, npn set etc are all fine, but, the length is messed up (*68* instead of
*34*)).
After further thinking, it seems to me that, it's possible that two threads
(basically, two ssl accepted connections) may try to create the npn list
simultaneously (since, both see the list is null) and the length could be
messed up due to interleaving. We need to either use a mutex to protect the
critical section or create the npn list not on the first accept, but, before
any accept is done. Will try to use a mutex and add logs to confirm that this
is indeed the issue.
Below's some data from gdb:
{code}
(gdb) f 7
#7 0x00729209 in SSLNextProtocolSet::advertiseProtocols
(this=0x46961518, out=0x2b7722a14830, len=0x2b7722a1483c, hash=883090498) at
SSLNextProtocolSet.cc:126
126 SSLNextProtocolSet.cc: No such file or directory.
(gdb) down
#6 0x00728f90 in create_npn_advertisement (endpoints=...,
npn=0x46961518, len=0x46961528) at SSLNextProtocolSet.cc:73
73 in SSLNextProtocolSet.cc
(gdb) p *len
$2 = 68
(gdb) p *npn
$3 = (unsigned char *) 0x2b77d0006fc0 "\bspdy/3.1\006spdy/3\bhttp/1.1\bhttp/1.0"
(gdb) p endpoints
$4 = (const SSLNextProtocolSet::NextProtocolEndpoint::list_type &) @0x46961538:
{head = 0x46339820}
(gdb) p endpoints.head
$5 = (SSLNextProtocolSet::NextProtocolEndpoint *) 0x46339820
(gdb) p *endpoints.head
$6 = {protocol = 0x7d80d0 "spdy/3.1", endpoint = 0x46961550, link =
{> = {next = 0x466c8d10}, prev
= 0x0}}
(gdb) p *endpoints.head.link.next
$7 = {protocol = 0x7d80c0 "spdy/3", endpoint = 0x2490400, link =
{> = {next = 0x46282ff0}, prev
= 0x46339820}}
(gdb) p *endpoints.head.link.next.link.next
$8 = {protocol = 0x7d8088 "http/1.1", endpoint = 0x46961450, link =
{> = {next = 0x45fc2140}, prev
= 0x466c8d10}}
(gdb) p *endpoints.head.link.next.link.next.link.next
$9 = {protocol = 0x7d8070 "http/1.0", endpoint = 0x46961450, link =
{> = {next = 0x0}, prev =
0x46282ff0}}
(gdb) p *endpoints.head.link.next.link.next.link.next.link.next
Cannot access memory at address 0x0
{code}
Below's the traceback:
{code}
Program terminated with signal SIGABRT, Aborted.
#0 0x003b98832625 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x003b98832625 in raise () from /lib64/libc.so.6
#1 0x003b98833e05 in abort () from /lib64/libc.so.6
#2 0x2b762b915018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b762b9150e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2b762b923d78 "%s:%d: failed
assert `%s`", ap=0x2b7722a14630)
at ink_error.cc:65
#4 0x2b762b9151ae in ink_fatal (return_code=1,
message_format=0x2b762b923d78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2b762b913d20 in _ink_assert (expression=0x7d0fed "*len <= 34",
file=0x7d0fa0 "SSLNextProtocolSet.cc", line=73) at ink_assert.cc:37
#6 0x00728f90 in create_npn_advertisement (endpoints=...,
npn=0x46961518, len=0x46961528) at SSLNextProtocolSet.cc:73
#7 0x00729209 in SSLNextProtocolSet::advertiseProtocols
(this=0x46961518, out=0x2b7722a14830, len=0x2b7722a1483c, hash=883090498) at
SSLNextProtocolSet.cc:126
#8 0x007275c2 in SSLNetVConnection::advertise_next_protocol
(ssl=0x2b77d900, out=0x2b7722a14830, outlen=0x2b7722a1483c) at
SSLNetVConnection.cc:807
#9 0x0038cb833cf8 in ssl_add_serverhello_tlsext () from
/usr/lib64/libssl.so.10
#10 0x0038cb81f786 in ssl3_send_server_hello () from /usr/lib64/libssl.so.10
#11 0x0038cb821d78 in ssl3_accept () from /usr/lib64/libssl.so.10
#12 0x0038cb82f846 in ssl23_get_client_hello () from /usr/lib64/libssl.so.10
#13 0x0038cb830143 in ssl23_accept () from /usr/lib64/libssl.so.10
#14 0x00726a0b in SSLNetVConnection::sslServerHandShakeEvent
(this=0x2b77800182c0, err=@0x2b7722a14b6c: 11127) at SSLNetVConnection.cc:607
#15 0x00726937 in SSLNetVConnection::sslStartHandShake
(this=0x2b77800182c0, event=0, err=@0x2b7722a14b6c: 11127) at
SSLNetVConnection.cc:583
#16 0x00725577 in SSLNetVConnection::net_read_io (this=0x2b77800182c0,
nh=0x2b7721100cb0, lthread=0x2b77210fd010) at SSLNetVConnection.cc:256
#17 0x0073312e in NetHandler::mainNetEvent (this=0x2b7721100cb0,
event=5, e=0x1d609d0) at UnixNet.cc:515
#18 0x004f7098 in Continuation::handleEvent (this=0x2b7721100cb0,
event=5, data=0x1d609d0) at ../iocore/eventsystem/I_Continuation.h:146
#19 0x0075a1fe in EThread::
[jira] [Commented] (TS-3518) Multiple ssl_ca_name's in ssl_multicert breaks all intermediate CAs
[
https://issues.apache.org/jira/browse/TS-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493184#comment-14493184
]
Thomas Jackson commented on TS-3518:
The weird part is (from best I can tell) ATS logs no errors, it just doesn't
load *any* intermediate CAs-- which also seems bad ;)
> Multiple ssl_ca_name's in ssl_multicert breaks all intermediate CAs
> ---
>
> Key: TS-3518
> URL: https://issues.apache.org/jira/browse/TS-3518
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Brian Geffon
>
> In ssl_multicert you can specify multiple ssl_cert_name and ssl_key_name,
> such as:
> {code}
> dest_ip=127.0.0.2
> ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
> ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
> {code}
> Sometimes you need to specify an intermediate CA (a lot of the time TBH),
> which from the docs sounds like you should be able to do:
> {code}
> dest_ip=127.0.0.2
> ssl_cert_name=www.example.com.cert,www.example.com.ecdsa.cert
> ssl_key_name=www.example.com.key,www.example.com.ecdsa.key
> ssl_ca_name=RSA_intermediate,ECDSA_intermediate
> {code}
> Since you can specify ssl_ca_name for single certs, similar to cert_name and
> key_name, but this currently doesn't work. In addition to not working for
> ECDSA this seems to actually break *all* intermediate CAs from being served.
> I've created a test case (https://github.com/apache/trafficserver/pull/186)
> which shows the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2032) Set milestone for cache-lookup times
[ https://issues.apache.org/jira/browse/TS-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2032: -- Assignee: John > Set milestone for cache-lookup times > > > Key: TS-2032 > URL: https://issues.apache.org/jira/browse/TS-2032 > Project: Traffic Server > Issue Type: New Feature > Components: Metrics >Reporter: Leif Hedstrom >Assignee: John > Fix For: sometime > > > There was some plumbing for this in HttpSM.cc (grep for this bug #), but it > was never used. I left the code uncommented, and we can maybe add this back > later. It might also need a metric for the number of cache lookups done as > well (not sure we have one). > This is also related to TS-1820, where this was cleaned out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call closed TS-3513.
--
Resolution: Fixed
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Ryo Okubo
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3519) HTTP/2 seeing a lot of GOAWAY frames being sent
Bryan Call created TS-3519:
--
Summary: HTTP/2 seeing a lot of GOAWAY frames being sent
Key: TS-3519
URL: https://issues.apache.org/jira/browse/TS-3519
Project: Traffic Server
Issue Type: Bug
Components: HTTP/2
Reporter: Bryan Call
Logging GOAWAY frames in Http2ConnectionState::main_event_handler()
{code}
[Apr 13 22:40:29.258] Server {0x2b08e7b3a700} ERROR: Sending GOAWAY frame
[Apr 13 22:40:29.449] Server {0x2b08e8948700} ERROR: Sending GOAWAY frame
[Apr 13 22:40:29.591] Server {0x2b08e7e3d700} ERROR: Sending GOAWAY frame
[Apr 13 22:40:30.197] Server {0x2b08e8645700} ERROR: Sending GOAWAY frame
[Apr 13 22:40:30.362] Server {0x2b08e6b2a700} ERROR: Sending GOAWAY frame
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-3513:
--
Assignee: Bryan Call (was: Ryo Okubo)
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3438) npn list being created with garbage data
[
https://issues.apache.org/jira/browse/TS-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493257#comment-14493257
]
Sudheer Vinukonda commented on TS-3438:
---
Ha, it turns out that [~briang] already noticed this issue and fixed it on
master in TS-3031 (will cherry-pick that to our branch).
> npn list being created with garbage data
>
>
> Key: TS-3438
> URL: https://issues.apache.org/jira/browse/TS-3438
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 5.3.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.0.0
>
>
> We noticed that occasionally upon a restart, the npn list built by ATS has
> garbage data (additional null bytes), resulting in the client failing to
> decode the ServerHello correctly. The problem would always go away with a
> restart and is hard to reproduce.
> Here's a trace that shows the good vs bad npn lists in the ServerHello:
> bad npn list (with spdy and http enabled):
> {code}
> Extension: next_protocol_negotiation
> Type: next_protocol_negotiation (0x3374)
> Length: 36
> Next Protocol Negotiation
> Protocol string length: 8
> Next Protocol: spdy/3.1
> Protocol string length: 6
> Next Protocol: spdy/3
> Protocol string length: 8
> Next Protocol: http/1.1
> Protocol string length: 8
> Next Protocol: http/1.0
> Protocol string length: 0
> Protocol string length: 0
> {code}
> good npn list:
> {code}
> Extension: next_protocol_negotiation
> Type: next_protocol_negotiation (0x3374)
> Length: 34
> Next Protocol Negotiation
> Protocol string length: 8
> Next Protocol: spdy/3.1
> Protocol string length: 6
> Next Protocol: spdy/3
> Protocol string length: 8
> Next Protocol: http/1.1
> Protocol string length: 8
> Next Protocol: http/1.0
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3088) Have ATS look at /etc/hosts
[ https://issues.apache.org/jira/browse/TS-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493360#comment-14493360 ] Miles Libbey commented on TS-3088: -- Alan- Is there anything that needs to be configured for this? (eg, do we need to update Documentation?) Perhaps a proxy.config.hostdb.host_file.path line in doc/reference/configuration/records.config.en.rst ? > Have ATS look at /etc/hosts > --- > > Key: TS-3088 > URL: https://issues.apache.org/jira/browse/TS-3088 > Project: Traffic Server > Issue Type: New Feature > Components: DNS >Reporter: David Carlin >Assignee: Alan M. Carroll >Priority: Minor > Fix For: 5.3.0 > > Attachments: ts-3088-3-2-x-patch.diff > > > It would be nice if /etc/hosts was read when resolving hostnames - useful for > testing/troubleshooting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3513) http2 core dump
[
https://issues.apache.org/jira/browse/TS-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493450#comment-14493450
]
Ryo Okubo commented on TS-3513:
---
[~bcall] the HPACK_ERROR_COMPRESSION_ERROR means "maybe compression error" at
there. When the error occurs and more data doesn't exist in the buffer (this
judge is processed in [the outer HPACK
decoder|https://github.com/apache/trafficserver/blob/master/proxy/http2/Http2ConnectionState.cc#L221]),
its handled as real error.
Error handling around HPACK encoder/decoder may cause misunderstanding so I
want to refactoring it at sometime.
It looks like your commit is valid. thanks.
> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493503#comment-14493503 ] Kit Chan commented on TS-1611: -- [~portl4t] Hi, we missed putting license info on these two files. would you please take a look? ts_lua_io.c ts_lua_io.h Thanks. > async http request in lua remap plugin > -- > > Key: TS-1611 > URL: https://issues.apache.org/jira/browse/TS-1611 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Luca Rea >Assignee: Kit Chan > Fix For: sometime > > Attachments: > 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, > 0002-TS-1611-add-ts_lua_constant.c.patch, > 0003-TS-1611-refine-doc-for-ts_lua.patch > > > Hi, > can you add support for async http requests in lua remap plugin please? > Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493526#comment-14493526 ] portl4t commented on TS-1611: - Yeah, your're right. I'm fixing it. By the way, I have finished ts.cache_xxx on github, should we create another issue to handle it ? > async http request in lua remap plugin > -- > > Key: TS-1611 > URL: https://issues.apache.org/jira/browse/TS-1611 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Luca Rea >Assignee: Kit Chan > Fix For: sometime > > Attachments: > 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, > 0002-TS-1611-add-ts_lua_constant.c.patch, > 0003-TS-1611-refine-doc-for-ts_lua.patch > > > Hi, > can you add support for async http requests in lua remap plugin please? > Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493530#comment-14493530 ] Leif Hedstrom commented on TS-1611: --- I think it's fine to commit the fix against this Jira. > async http request in lua remap plugin > -- > > Key: TS-1611 > URL: https://issues.apache.org/jira/browse/TS-1611 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Luca Rea >Assignee: Kit Chan > Fix For: sometime > > Attachments: > 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, > 0002-TS-1611-add-ts_lua_constant.c.patch, > 0003-TS-1611-refine-doc-for-ts_lua.patch > > > Hi, > can you add support for async http requests in lua remap plugin please? > Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493561#comment-14493561 ] portl4t commented on TS-1611: - Agree with Leif. [~kichan], I think you can commit the fix directly as you have the rights. > async http request in lua remap plugin > -- > > Key: TS-1611 > URL: https://issues.apache.org/jira/browse/TS-1611 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Luca Rea >Assignee: Kit Chan > Fix For: sometime > > Attachments: > 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, > 0002-TS-1611-add-ts_lua_constant.c.patch, > 0003-TS-1611-refine-doc-for-ts_lua.patch > > > Hi, > can you add support for async http requests in lua remap plugin please? > Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3503) Add ua_first_read to milestones to track when the first byte was read from the client
[ https://issues.apache.org/jira/browse/TS-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3503: -- Assignee: Bryan Call (was: John) > Add ua_first_read to milestones to track when the first byte was read from > the client > - > > Key: TS-3503 > URL: https://issues.apache.org/jira/browse/TS-3503 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 6.0.0 > > > There can be a delay between the ua_begin and when we start to parse the > client request. Keep track of the time when we start to read the the client > request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3503) Add ua_first_read to milestones to track when the first byte was read from the client
[ https://issues.apache.org/jira/browse/TS-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-3503. --- Resolution: Fixed Sounds like this was fixed? Closing. > Add ua_first_read to milestones to track when the first byte was read from > the client > - > > Key: TS-3503 > URL: https://issues.apache.org/jira/browse/TS-3503 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 6.0.0 > > > There can be a delay between the ua_begin and when we start to parse the > client request. Keep track of the time when we start to read the the client > request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3503) Add ua_first_read to milestones to track when the first byte was read from the client
[ https://issues.apache.org/jira/browse/TS-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3503: -- Assignee: John > Add ua_first_read to milestones to track when the first byte was read from > the client > - > > Key: TS-3503 > URL: https://issues.apache.org/jira/browse/TS-3503 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Bryan Call >Assignee: John > Fix For: 6.0.0 > > > There can be a delay between the ua_begin and when we start to parse the > client request. Keep track of the time when we start to read the the client > request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493593#comment-14493593 ] ASF subversion and git services commented on TS-1611: - Commit c20098393fc91cc5c3557e2ab9aae7151053f411 in trafficserver's branch refs/heads/master from [~kichan] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c200983 ] TS-1611: Add missing license info > async http request in lua remap plugin > -- > > Key: TS-1611 > URL: https://issues.apache.org/jira/browse/TS-1611 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Luca Rea >Assignee: Kit Chan > Fix For: sometime > > Attachments: > 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, > 0002-TS-1611-add-ts_lua_constant.c.patch, > 0003-TS-1611-refine-doc-for-ts_lua.patch > > > Hi, > can you add support for async http requests in lua remap plugin please? > Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493594#comment-14493594 ] Kit Chan commented on TS-1611: -- just added. > async http request in lua remap plugin > -- > > Key: TS-1611 > URL: https://issues.apache.org/jira/browse/TS-1611 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Luca Rea >Assignee: Kit Chan > Fix For: sometime > > Attachments: > 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, > 0002-TS-1611-add-ts_lua_constant.c.patch, > 0003-TS-1611-refine-doc-for-ts_lua.patch > > > Hi, > can you add support for async http requests in lua remap plugin please? > Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
