[jira] [Commented] (TS-4402) Some HTTP configs were added as MgmtInt, but should be MgmtByte
[
https://issues.apache.org/jira/browse/TS-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356341#comment-15356341
]
Sudheer Vinukonda commented on TS-4402:
---
Either way will work :), though, it seems like it might be more useful
"practice" for a newbie bug.
> Some HTTP configs were added as MgmtInt, but should be MgmtByte
> ---
>
> Key: TS-4402
> URL: https://issues.apache.org/jira/browse/TS-4402
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration
>Reporter: Leif Hedstrom
> Labels: newbie
> Fix For: 7.0.0
>
>
> Specifically I think these should be Byte's, to be consistent with the rest
> of the internals:
> {code}
> MgmtInt attach_server_session_to_client;
> MgmtInt cache_open_write_fail_action
> {code}
> Now, changing this might break the same snapshot? [~jpe...@apache.org]
> Also, while going through these, a couple of overridable configs are marked
> as MgmtInt in InkAPI.cc, where in fact they are MgmtByte (so the inverse
> problem). I'll fix this as part of TS-4401.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4424) proxy.config.ssl.max_record_size=-1 (dynamic rec size) can cause out-of-bound memory access
[
https://issues.apache.org/jira/browse/TS-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15332741#comment-15332741
]
Sudheer Vinukonda commented on TS-4424:
---
Sounds good - Will try and get it resolved for 6.2.2
> proxy.config.ssl.max_record_size=-1 (dynamic rec size) can cause out-of-bound
> memory access
> ---
>
> Key: TS-4424
> URL: https://issues.apache.org/jira/browse/TS-4424
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: crash
> Fix For: 7.0.0
>
>
> From a few days ago:
> {code}
> [May 2 16:09:34.060] Manager {0x7f44c4e94800} WARNING: Be aware that access
> control checks for HTTP/2 connections are not active!
> [May 2 16:09:34.060] Manager {0x7f44c4e94800} WARNING: Be aware that access
> control checks for HTTP/2 connections are not active!
> =
> ==17268==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x62a0064b5000 at pc 0x2b8fd0a73615 bp 0x7ffd34d416e0 sp 0x7ffd34d40e90
> READ of size 16384 at 0x62a0064b5000 thread T0 ([ET_NET 0])
> #0 0x2b8fd0a73614 in __asan_memcpy
> ../../../../libsanitizer/asan/asan_interceptors.cc:367
> #1 0x2b8fd26f7b63 in ssl3_write_bytes
> (/opt/openssl/lib/libssl.so.1.0.0+0x29b63)
> #2 0xbfe2e0 in SSLWriteBuffer(ssl_st*, void const*, long, long&)
> /usr/local/src/trafficserver/iocore/net/SSLUtils.cc:2041
> #3 0xbd2a6a in SSLNetVConnection::load_buffer_and_write(long, long&,
> long&, MIOBufferAccessor&, int&)
> /usr/local/src/trafficserver/iocore/net/SSLNetVConnection.cc:735
> #4 0xc48dad in write_to_net_io(NetHandler*, UnixNetVConnection*,
> EThread*) /usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:511
> #5 0xc0a8ba in NetHandler::mainNetEvent(int, Event*)
> /usr/local/src/trafficserver/iocore/net/UnixNet.cc:529
> #6 0xcf6da3 in Continuation::handleEvent(int, void*)
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #7 0xcf6da3 in EThread::process_event(Event*, int)
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:129
> #8 0xcf9d4a in EThread::execute()
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:256
> #9 0x498ad5 in main /usr/local/src/trafficserver/proxy/Main.cc:1909
> #10 0x2b8fd475bb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> #11 0x4a8244 (/opt/ats/bin/traffic_server+0x4a8244)
> 0x62a0064b5000 is located 0 bytes to the right of 16384-byte region
> [0x62a0064b1000,0x62a0064b5000)
> allocated by thread T0 ([ET_NET 0]) here:
> #0 0x2b8fd0a7f9ae in __interceptor_posix_memalign
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:105
> #1 0x2b8fd19b2ca9 in ats_memalign
> /usr/local/src/trafficserver/lib/ts/ink_memory.cc:105
> #2 0x2b8fd19b3f3e in ink_freelist_new
> /usr/local/src/trafficserver/lib/ts/ink_queue.cc:183
> #3 0x7d5670 in Allocator::alloc_void() ../../lib/ts/Allocator.h:63
> #4 0x7d5670 in IOBufferData::alloc(long, AllocType)
> ../../iocore/eventsystem/P_IOBuffer.h:282
> #5 0x7d5670 in new_IOBufferData_internal(char const*, long, AllocType)
> ../../iocore/eventsystem/P_IOBuffer.h:253
> #6 0x7d5670 in IOBufferBlock::alloc(long)
> ../../iocore/eventsystem/P_IOBuffer.h:396
> #7 0x7d5670 in Http2Frame::alloc(int)
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.h:96
> #8 0x7d5670 in Http2ConnectionState::send_data_frame(Http2Stream*)
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:959
> #9 0x7ea209 in Http2Stream::update_write_request(IOBufferReader*, long,
> bool) /usr/local/src/trafficserver/proxy/http2/Http2Stream.cc:462
> #10 0x7efe96 in Http2Stream::reenable(VIO*)
> /usr/local/src/trafficserver/proxy/http2/Http2Stream.cc:482
> #11 0x777c49 in VIO::reenable() ../../iocore/eventsystem/P_VIO.h:111
> #12 0x777c49 in HttpTunnel::producer_handler(int, HttpTunnelProducer*)
> /usr/local/src/trafficserver/proxy/http/HttpTunnel.cc:1199
> #13 0x77a0ee in HttpTunnel::main_handler(int, void*)
> /usr/local/src/trafficserver/proxy/http/HttpTunnel.cc:1568
> #14 0x9a2467 in Continuation::handleEvent(int, void*)
> ../../iocore/eventsystem/I_Continuation.h:153
> #15 0x9a2467 in CacheVC::calluser(int)
> ../../iocore/cache/P_CacheInternal.h:623
> #16 0xb21d2c in CacheVC::openReadMain(int, Event*)
> /usr/local/src/trafficserver/iocore/cache/CacheRead.cc:717
> #17 0x9a284c in Continuation::handleEvent(int, void*)
> ../../iocore/eventsystem/I_Continuation.h:153
> #18 0x9a284c in CacheVC::callcont(int)
> ../../iocore/cache/P_CacheInternal.h:642
>
[jira] [Created] (TS-4452) Change open_write_fail_action to MgmtByte
Sudheer Vinukonda created TS-4452: - Summary: Change open_write_fail_action to MgmtByte Key: TS-4452 URL: https://issues.apache.org/jira/browse/TS-4452 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Sudheer Vinukonda -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4235) Deprecate fuzzy cache revalidation ?
[
https://issues.apache.org/jira/browse/TS-4235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267430#comment-15267430
]
Sudheer Vinukonda commented on TS-4235:
---
Looks like I'm a little late here, but, I'm +1 on this :)
> Deprecate fuzzy cache revalidation ?
>
>
> Key: TS-4235
> URL: https://issues.apache.org/jira/browse/TS-4235
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> I'm starting this as a discussion here. I think there are good reasons to
> deprecate (for now) and later remove the fuzz logic. These configs are
> currently in place:
> {code}
> {RECT_CONFIG, "proxy.config.http.cache.fuzz.time", RECD_INT, "240",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {RECT_CONFIG, "proxy.config.http.cache.fuzz.min_time", RECD_INT, "0",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {RECT_CONFIG, "proxy.config.http.cache.fuzz.probability", RECD_FLOAT,
> "0.005", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {code}
> The reason for eliminating these are:
> 1) They are difficult to setup correctly, particularly if you have a mix of
> various cache TTL on objects.
> 2) Currently, they have next to no value, since you lock out all other
> readers from the object anyways. So you are likely to benefit / use this only
> for objects which are infrequently accessed.
> 3) With the new proxy.config.http.cache.open_write_fail_action it's possible
> that #2 improves, but in that case, I'd argue that if you allow it to serve
> stale, you are better off letting it expire and not "prematurely" revalidate
> the object.
> 4) It seems to cause confusing behavior as it is today (with default
> settings), e.g. anything with less than 240s TTL is likely to trip up and
> prematurely expire long before intended (this is why we added the
> proxy.config.http.cache.fuzz.min_time option, but it's disabled by default,
> and makes configuration even more complicated).
> So what does everyone think? Is anyone actually using and relying on the fuzz
> logic? It feels better to spend some time on adding more features to the
> fail_action feature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4046) HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest
[
https://issues.apache.org/jira/browse/TS-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15247976#comment-15247976
]
Sudheer Vinukonda commented on TS-4046:
---
Given the sensitiveness of the code change, would it be possible to test this
patch (or any new changes) with traffic for a reasonable duration?
> HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest
>
>
> Key: TS-4046
> URL: https://issues.apache.org/jira/browse/TS-4046
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, MIME, Plugins
>Reporter: rienzi2012
>Assignee: Alan M. Carroll
> Labels: review
> Fix For: 7.0.0
>
>
> HTTPHdr::clear is called instead of HdrHeapSDKHandle::destroy in
> HttpTransact::EndRemapRequest. This will definitely cause memory leak when a
> plugin calls TSHttpTxnServerIntercept or TSHttpTxnIntercept. This bug
> influences a lot of users. Here is a patch below.
> {code:java}
> @@ -892,7 +892,7 @@
> HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
> TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
>} else {
> -s->hdr_info.client_response.clear(); // anything previously set is
> invalid from this point forward
> +s->hdr_info.client_response.destroy();
> DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
>
> if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3857) Suppress a logging related error message to Note to avoid flooding.
[
https://issues.apache.org/jira/browse/TS-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda resolved TS-3857.
---
Resolution: Fixed
> Suppress a logging related error message to Note to avoid flooding.
> ---
>
> Key: TS-3857
> URL: https://issues.apache.org/jira/browse/TS-3857
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Labels: yahoo
> Fix For: 6.2.0
>
>
> After upgrading to 5.3.x from 5.0, one of our prod systems ran into an issue
> with disk space filling up due to the flooding of the below error message
> into syslogs.
> {code}
> {0x2aeac59d2700} ERROR: Failed to convert LogBuffer to ascii, have dropped
> (552) bytes
> {code}
> This is an unfortunate sideaffect of the fix made in TS-2940, prior to which,
> the defaults to error setting were not working correctly and ignoring the
> logging to syslog output.
> Also, should we change error defaults to "L" to ensure syslogs are not
> flooded with the fix from TS-2940? Below are the current defaults, which did
> not work correctly prior to TS-2940.
> {code}
> CONFIG proxy.config.diags.output.error STRING SL
> CONFIG proxy.config.diags.output.fatal STRING SL
> CONFIG proxy.config.diags.output.emergency STRING SL
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4345) Change defaults for ERROR to not log to syslogs since it can potentially flood syslogs.
[ https://issues.apache.org/jira/browse/TS-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-4345: -- Fix Version/s: 7.0.0 Component/s: Logging > Change defaults for ERROR to not log to syslogs since it can potentially > flood syslogs. > --- > > Key: TS-4345 > URL: https://issues.apache.org/jira/browse/TS-4345 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Sudheer Vinukonda > Fix For: 7.0.0 > > > Follow up of TS-3857. > Should we change error defaults to "L" to ensure syslogs are not flooded with > the fix from TS-2940? The current defaults of "SL" did not work correctly > before TS-2940 and after the fix to TS-2940, any repeatedly occurring error > log can flood syslogs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4345) Change defaults for ERROR to not log to syslogs since it can potentially flood syslogs.
Sudheer Vinukonda created TS-4345: - Summary: Change defaults for ERROR to not log to syslogs since it can potentially flood syslogs. Key: TS-4345 URL: https://issues.apache.org/jira/browse/TS-4345 Project: Traffic Server Issue Type: Bug Reporter: Sudheer Vinukonda Follow up of TS-3857. Should we change error defaults to "L" to ensure syslogs are not flooded with the fix from TS-2940? The current defaults of "SL" did not work correctly before TS-2940 and after the fix to TS-2940, any repeatedly occurring error log can flood syslogs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3286) Improve MIOBuffer allocation mechanism with checks to prevent corrupting the freelist
[
https://issues.apache.org/jira/browse/TS-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3286:
--
Fix Version/s: (was: 6.2.0)
7.0.0
> Improve MIOBuffer allocation mechanism with checks to prevent corrupting the
> freelist
> -
>
> Key: TS-3286
> URL: https://issues.apache.org/jira/browse/TS-3286
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 7.0.0
>
>
> This jira is a follow up on TS-3285. While investigating TS-3285, I realized
> that there are not sufficient guards in-place in the MIOBuffer
> allocation/access mechanism to prevent corrupting the free list or accessing
> the objects off of the freelist.
> These issues are particularly problematic, when creating the MIOBuffer using
> new_empty_MIOBuffer(). This simply pulls out the MIOBuffer from the freelist,
> without resetting/initializing the data members. So, if the MIOBuffer on the
> freelist is bad, then the newly allocated buffer will run into trouble (e.g
> TS-3285). Note that, if the MIOBuffer is allocated using new_MIOBuffer(), it
> calls clear() which resets the members correctly.
> The problem also is partly due to the fact that MIOBuffer uses ProxyAllocator
> and when the object is allocated from the local thread freelist, it is not
> reset with a prototype object memcpy (like the ClassAllocator would do).
> Some checks/asserts I am thinking of adding are as below:
> {code}
> diff --git a/iocore/eventsystem/IOBuffer.cc b/iocore/eventsystem/IOBuffer.cc
> index 879e8ba..d54080f 100644
> --- a/iocore/eventsystem/IOBuffer.cc
> +++ b/iocore/eventsystem/IOBuffer.cc
> @@ -82,6 +82,7 @@ MIOBuffer::remove_append(IOBufferReader * r)
> int64_t
> MIOBuffer::write(const void *abuf, int64_t alen)
> {
> + ink_release_assert(size_index < BUFFER_SIZE_NOT_ALLOCATED);
>const char *buf = (const char*)abuf;
>int64_t len = alen;
>while (len) {
> @@ -135,6 +136,7 @@
> MIOBuffer::write_and_transfer_left_over_space(IOBufferReader * r, int64_t
> alen,
> int64_t
> MIOBuffer::write(IOBufferReader * r, int64_t alen, int64_t offset)
> {
> + ink_release_assert(size_index < BUFFER_SIZE_NOT_ALLOCATED);
>int64_t len = alen;
>IOBufferBlock *b = r->block;
>offset += r->start_offset;
> diff --git a/iocore/eventsystem/I_IOBuffer.h b/iocore/eventsystem/I_IOBuffer.h
> index 0e5fe0c..d9aba81 100644
> --- a/iocore/eventsystem/I_IOBuffer.h
> +++ b/iocore/eventsystem/I_IOBuffer.h
> @@ -1126,8 +1126,6 @@ public:
> _writer->realloc_xmalloc(buf_size);
>}
>
> - int64_t size_index;
> -
>/**
> Determines when to stop writing or reading. The watermark is the
> level to which the producer (filler) is required to fill the buffer
> @@ -1138,6 +1136,8 @@ public:
>*/
>int64_t water_mark;
>
> + int64_t size_index;
> +
>Ptr _writer;
>IOBufferReader readers[MAX_MIOBUFFER_READERS];
>
> diff --git a/iocore/eventsystem/P_IOBuffer.h b/iocore/eventsystem/P_IOBuffer.h
> index 365486f..74ea432 100644
> --- a/iocore/eventsystem/P_IOBuffer.h
> +++ b/iocore/eventsystem/P_IOBuffer.h
> @@ -775,8 +775,7 @@ TS_INLINE MIOBuffer * new_MIOBuffer_internal(
> TS_INLINE void
> free_MIOBuffer(MIOBuffer * mio)
> {
> - mio->_writer = NULL;
> - mio->dealloc_all_readers();
> + clear();
>THREAD_FREE(mio, ioAllocator, this_thread());
> }
>
> @@ -893,6 +892,7 @@ MIOBuffer::append_block_internal(IOBufferBlock * b)
>// It would be nice to remove an empty buffer at the beginning,
>// but this breaks HTTP.
>// if (!_writer || !_writer->read_avail())
> + ink_release_assert(size_index < BUFFER_SIZE_NOT_ALLOCATED);
>if (!_writer) {
> _writer = b;
> init_readers();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4291) Custom log field {{pqhl}} should not count internal headers.
[
https://issues.apache.org/jira/browse/TS-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-4291:
--
Description:
[~zwoop] suggested to add a simple API (not necessarily exposed to plugins at
the moment), to count the length of @-custom headers and deduct that when
reporting {{pqhl}}. Also, apply the same modification to lengths of other leg
request/response objects (e.g client_req, client_resp, server_req, server_resp).
IRC discussion below.
{code}
oag
7:55 If anyone is around who is familiar with the @-headers trick, I have a
question:
7:55 I have observed that @custom-header in an outgoing request changes the
value of the pqhl log field, even though the header is never actually sent.
7:55 This is true in 5.3.1. Does anyone know if this as been changed in 6.x.x ?
7:55 Would like it if pqhl was an accurate reflection of data to the origin
server.
7:55 (pqhl + pqbl that is.)
zwoop
7:55 oag I'm pretty sure that is intended, if you don't want it there, why not
add it to another header ?
7:55 the way it works is that it "filters" out the @ header before sending, and
returning, headers
7:55 (afaik)
7:55 entirely possible I'm wrong too, but that was my impression from before.
***
7:55 Playback Complete.
7:57 esproul [~ad...@static-108-48-124-82.washdc.fios.verizon.net] entered the
room.
sudheerv
8:07 zwoop: oag: umm..interesting, like zwoop said while it is intentional that
@-custom headers are meant never to be leaked outside, the pqhl adding the
@-headers seems like not something desirable
8:08 i'd be okay if we agree to not add it to pqhl
8:08 pqhl
The proxy request header length; the header length in Traffic Server’s request
to the origin server.
8:09 given that pqhl is defined as the header length in the outbound request
8:09 adding @-headers to it seems inconsistent/inaccurate
8:10 as a matter of fact, i use @headers pretty "heavily" in our products..but,
don't enable pqhl
8:10 (at the moment anyway)
zwoop
8:15 sudheerv but that sets a poor precedence. You want to exclude @ headers
from pqhl, but not the other 3 internal header log tags that we have ?
zwoop
8:16 One very important feature of the @-headers is to be able to log internal
(plugin generated) information in our custom logs
sudheerv
8:16 zwoop: but, pqhl is just the length of the outgoing headers?
zwoop
8:16 ah
sudheerv
8:16 i haven't looked at in detail, but, excluding @ headers ( and the other
intenral headers)
zwoop
8:16 in bytes ?
sudheerv
8:16 from pqhl
8:16 will it mess up the log fields?
8:16 yeah
zwoop
8:16 I thought it was the request header object.
8:16 Yeah, I don't know
sudheerv
8:17 yeah, worth double checking - when the wise man complains :)
zwoop
8:17 maybe you'd have to keep two lengths then, one with, and one without the @
headers ?
sudheerv
8:17 but, yeah, i'd not want to exclude the headers from log fields
8:17 just the length
8:17 sure, yeah unless it's already computing them in one place
zwoop
8:17 m_proxy_request->length_get()
sudheerv
8:17 where it'd be easier to exclude them - need ot check that part of the code
8:17 ah, ok
8:19 so, would you be okay to modify pqhl (lenght in bytes) to exclude the
internal headers?
zwoop
8:19 http://pastebin.com/svwPmaa0
8:19 looks like it counts the size of the "blocks" used, and not individual
header. It'd likely get much, much more expensive if you have to walk through
every header value.
8:21 actually, maybe it does count it individually, cause it calls
mime_field_length_get(MIMEField *field)
sudheerv
8:21 yeah
zwoop
8:22 But regardless, I'd be concerned that this might break other behavior
internally, so at a minimum, you'd want this exclusion only for a log tag. And
even so, since it's incompatible, etiher for v7.0.0, or as a separate log tag
sudheerv
8:22 and it does it each time lenght_get() is called?
zwoop
8:22 looks like it
sudheerv
8:22 umm..ok - yeah, may be, we just live with it then :)
8:22 we can update the docs though
8:23 oag: may be, you could help with that :)
zwoop
8:23 this is probably a huge can of worm :)
sudheerv
8:23 agree
zwoop
8:23 i'm not touching it :)
sudheerv
8:24 lol, although, i wasn't going to change the mime_hdr_lenght_get() for
general API usage
8:24 only the pqhl part
8:24 for e.g. add another version of mime_hdr_lenght_get()
8:24 and use that for loggin
8:24 but, i agree - may be it's not worth touching this can
zwoop
8:25 maybe another option would be to have a new tag showing the (various)
sizes of @-headers only?
8:25 Then you can do the subtraction
sudheerv
8:25 yeah that sounds reasonable
8:25 actually, even cleaner
8:25 someone can just get the lenght of @headers if he wants
zwoop
8:26 right
sudheerv
8:26 and the logging part can show the delta
zwoop
8:26 yeah, logs_xml.config supports "math" I think
8:26 psp [~Adium@207.38.47.126] entered the room.
sudheerv
8:26 yeah, or we can even fix the pqhl if it's acceptable
8:2
[jira] [Created] (TS-4291) Custom log field {{pqhl}} should not count internal headers.
Sudheer Vinukonda created TS-4291:
-
Summary: Custom log field {{pqhl}} should not count internal
headers.
Key: TS-4291
URL: https://issues.apache.org/jira/browse/TS-4291
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Sudheer Vinukonda
[~zwoop] suggested to add a simple API (not necessarily exposed to plugins at
the moment), to count the length of @-custom headers and deduct that when
reporting {{pqhl}}
IRC discussion below.
{code}
oag
7:55 If anyone is around who is familiar with the @-headers trick, I have a
question:
7:55 I have observed that @custom-header in an outgoing request changes the
value of the pqhl log field, even though the header is never actually sent.
7:55 This is true in 5.3.1. Does anyone know if this as been changed in 6.x.x ?
7:55 Would like it if pqhl was an accurate reflection of data to the origin
server.
7:55 (pqhl + pqbl that is.)
zwoop
7:55 oag I'm pretty sure that is intended, if you don't want it there, why not
add it to another header ?
7:55 the way it works is that it "filters" out the @ header before sending, and
returning, headers
7:55 (afaik)
7:55 entirely possible I'm wrong too, but that was my impression from before.
***
7:55 Playback Complete.
7:57 esproul [~ad...@static-108-48-124-82.washdc.fios.verizon.net] entered the
room.
sudheerv
8:07 zwoop: oag: umm..interesting, like zwoop said while it is intentional that
@-custom headers are meant never to be leaked outside, the pqhl adding the
@-headers seems like not something desirable
8:08 i'd be okay if we agree to not add it to pqhl
8:08 pqhl
The proxy request header length; the header length in Traffic Server’s request
to the origin server.
8:09 given that pqhl is defined as the header length in the outbound request
8:09 adding @-headers to it seems inconsistent/inaccurate
8:10 as a matter of fact, i use @headers pretty "heavily" in our products..but,
don't enable pqhl
8:10 (at the moment anyway)
zwoop
8:15 sudheerv but that sets a poor precedence. You want to exclude @ headers
from pqhl, but not the other 3 internal header log tags that we have ?
zwoop
8:16 One very important feature of the @-headers is to be able to log internal
(plugin generated) information in our custom logs
sudheerv
8:16 zwoop: but, pqhl is just the length of the outgoing headers?
zwoop
8:16 ah
sudheerv
8:16 i haven't looked at in detail, but, excluding @ headers ( and the other
intenral headers)
zwoop
8:16 in bytes ?
sudheerv
8:16 from pqhl
8:16 will it mess up the log fields?
8:16 yeah
zwoop
8:16 I thought it was the request header object.
8:16 Yeah, I don't know
sudheerv
8:17 yeah, worth double checking - when the wise man complains :)
zwoop
8:17 maybe you'd have to keep two lengths then, one with, and one without the @
headers ?
sudheerv
8:17 but, yeah, i'd not want to exclude the headers from log fields
8:17 just the length
8:17 sure, yeah unless it's already computing them in one place
zwoop
8:17 m_proxy_request->length_get()
sudheerv
8:17 where it'd be easier to exclude them - need ot check that part of the code
8:17 ah, ok
8:19 so, would you be okay to modify pqhl (lenght in bytes) to exclude the
internal headers?
zwoop
8:19 http://pastebin.com/svwPmaa0
8:19 looks like it counts the size of the "blocks" used, and not individual
header. It'd likely get much, much more expensive if you have to walk through
every header value.
8:21 actually, maybe it does count it individually, cause it calls
mime_field_length_get(MIMEField *field)
sudheerv
8:21 yeah
zwoop
8:22 But regardless, I'd be concerned that this might break other behavior
internally, so at a minimum, you'd want this exclusion only for a log tag. And
even so, since it's incompatible, etiher for v7.0.0, or as a separate log tag
sudheerv
8:22 and it does it each time lenght_get() is called?
zwoop
8:22 looks like it
sudheerv
8:22 umm..ok - yeah, may be, we just live with it then :)
8:22 we can update the docs though
8:23 oag: may be, you could help with that :)
zwoop
8:23 this is probably a huge can of worm :)
sudheerv
8:23 agree
zwoop
8:23 i'm not touching it :)
sudheerv
8:24 lol, although, i wasn't going to change the mime_hdr_lenght_get() for
general API usage
8:24 only the pqhl part
8:24 for e.g. add another version of mime_hdr_lenght_get()
8:24 and use that for loggin
8:24 but, i agree - may be it's not worth touching this can
zwoop
8:25 maybe another option would be to have a new tag showing the (various)
sizes of @-headers only?
8:25 Then you can do the subtraction
sudheerv
8:25 yeah that sounds reasonable
8:25 actually, even cleaner
8:25 someone can just get the lenght of @headers if he wants
zwoop
8:26 right
sudheerv
8:26 and the logging part can show the delta
zwoop
8:26 yeah, logs_xml.config supports "math" I think
8:26 psp [~Adium@207.38.47.126] entered the room.
sudheerv
8:26 yeah, or we can eve
[jira] [Commented] (TS-4243) Collapsed Forwarding Plugin
[ https://issues.apache.org/jira/browse/TS-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15176711#comment-15176711 ] Sudheer Vinukonda commented on TS-4243: --- Gah, I thought I nuked it..I can't see it on github, is it still hiding somewhere :) ? > Collapsed Forwarding Plugin > --- > > Key: TS-4243 > URL: https://issues.apache.org/jira/browse/TS-4243 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Affects Versions: 6.2.0 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.2.0 > > > Collapsed Forwarding Plugin based on Open Write Fail Action feature (refer > TS-3549) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4249) Deprecate Stale_While_Revalidate plugin.
Sudheer Vinukonda created TS-4249: - Summary: Deprecate Stale_While_Revalidate plugin. Key: TS-4249 URL: https://issues.apache.org/jira/browse/TS-4249 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Sudheer Vinukonda Once TS-4237 is implemented, SWR will be sort of supported in the core. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3587) Support stale-while-revalidate in the core
[ https://issues.apache.org/jira/browse/TS-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-3587. --- Resolution: Duplicate Fix Version/s: (was: sometime) > Support stale-while-revalidate in the core > -- > > Key: TS-3587 > URL: https://issues.apache.org/jira/browse/TS-3587 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Reporter: Sudheer Vinukonda > > Refer TS-3549 and > https://cwiki.apache.org/confluence/display/TS/Stale-While-Revalidate+in+the+core > for details. > https://cwiki.apache.org/confluence/display/TS/Presentations+-+2015?preview=/56066455/61328981/Stale%20While%20Revalidate%20(Open%20Write%20Fail)%20Copy.pptx.pdf#Presentations-2015-2015FallSummit -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4243) Collapsed Forwarding Plugin
[ https://issues.apache.org/jira/browse/TS-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-4243: -- Affects Version/s: 6.2.0 Fix Version/s: 6.2.0 > Collapsed Forwarding Plugin > --- > > Key: TS-4243 > URL: https://issues.apache.org/jira/browse/TS-4243 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Affects Versions: 6.2.0 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.2.0 > > > Collapsed Forwarding Plugin based on Open Write Fail Action feature (refer > TS-3549) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4243) Collapsed Forwarding Plugin
[ https://issues.apache.org/jira/browse/TS-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-4243. --- Resolution: Fixed > Collapsed Forwarding Plugin > --- > > Key: TS-4243 > URL: https://issues.apache.org/jira/browse/TS-4243 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Affects Versions: 6.2.0 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.2.0 > > > Collapsed Forwarding Plugin based on Open Write Fail Action feature (refer > TS-3549) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4243) Collapsed Forwarding Plugin
[ https://issues.apache.org/jira/browse/TS-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174641#comment-15174641 ] Sudheer Vinukonda commented on TS-4243: --- Thanks, Susan! I'll update the fix later to set the status to 502 in dns/snd_req hook and remove checking for 500 in snd_resp. That might be slightly cleaner and will save the trouble of having to validate each 500 (which is a more common cause that can happen for many reasons). > Collapsed Forwarding Plugin > --- > > Key: TS-4243 > URL: https://issues.apache.org/jira/browse/TS-4243 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > > Collapsed Forwarding Plugin based on Open Write Fail Action feature (refer > TS-3549) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4243) Collapsed Forwarding Plugin
[ https://issues.apache.org/jira/browse/TS-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-4243: - Assignee: Sudheer Vinukonda > Collapsed Forwarding Plugin > --- > > Key: TS-4243 > URL: https://issues.apache.org/jira/browse/TS-4243 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > > Collapsed Forwarding Plugin based on Open Write Fail Action feature (refer > TS-3549) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4243) Collapsed Forwarding Plugin
Sudheer Vinukonda created TS-4243: - Summary: Collapsed Forwarding Plugin Key: TS-4243 URL: https://issues.apache.org/jira/browse/TS-4243 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Sudheer Vinukonda Collapsed Forwarding Plugin based on Open Write Fail Action feature (refer TS-3549) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4238) Enhance Open Write Fail Action feature to allow serving stale copy to all requests during cache refresh.
[ https://issues.apache.org/jira/browse/TS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-4238: - Assignee: Sudheer Vinukonda > Enhance Open Write Fail Action feature to allow serving stale copy to all > requests during cache refresh. > > > Key: TS-4238 > URL: https://issues.apache.org/jira/browse/TS-4238 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > > This is a follow up enhancement for TS-3549 (and related jiras). Open Write > Fail Action feature developed with TS-3549 currently allows returning a stale > copy to every client (based on a cache open write failure), except the first > client that initiated a cache revalidation. This jira is opened to enhance > the feature to support returning the stale copy even to the first client, > essentially triggering the revalidation in the background (ala background > fill feature), so as to be able to use the feature as a substitute for SWR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4237) Enhance Open Write Fail Action feature to support an option to honor SWR RFC headers.
[
https://issues.apache.org/jira/browse/TS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda reassigned TS-4237:
-
Assignee: Sudheer Vinukonda
> Enhance Open Write Fail Action feature to support an option to honor SWR RFC
> headers.
> -
>
> Key: TS-4237
> URL: https://issues.apache.org/jira/browse/TS-4237
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>
> This is a follow up enhancement for TS-3549 (and related jiras). Open Write
> Fail Action feature developed with TS-3549 currently supports the following
> options:
> https://docs.trafficserver.apache.org/en/6.0.x/reference/configuration/records.config.en.html#proxy-config-http-cache-open-write-fail-action
> {code}
> 0 = default, disable cache and goto origin server
> 1 = return a 502 error on a cache miss
> 2 = serve stale if object’s age is under
> proxy.config.http.cache.max_stale_age, else, goto origin server
> {code}
> This jira is opened to enhance the feature to support a new option to serve
> stale honoring the SWR RFC headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4237) Enhance Open Write Fail Action feature to support an option to honor SWR RFC headers.
[
https://issues.apache.org/jira/browse/TS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-4237:
--
Summary: Enhance Open Write Fail Action feature to support an option to
honor SWR RFC headers. (was: Enhance Open Write Fail Action feature to support
an option to honor SWR RFC header.)
> Enhance Open Write Fail Action feature to support an option to honor SWR RFC
> headers.
> -
>
> Key: TS-4237
> URL: https://issues.apache.org/jira/browse/TS-4237
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Sudheer Vinukonda
>
> This is a follow up enhancement for TS-3549 (and related jiras). Open Write
> Fail Action feature developed with TS-3549 currently supports the following
> options:
> https://docs.trafficserver.apache.org/en/6.0.x/reference/configuration/records.config.en.html#proxy-config-http-cache-open-write-fail-action
> {code}
> 0 = default, disable cache and goto origin server
> 1 = return a 502 error on a cache miss
> 2 = serve stale if object’s age is under
> proxy.config.http.cache.max_stale_age, else, goto origin server
> {code}
> This jira is opened to enhance the feature to support a new option to serve
> stale honoring the SWR RFC headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4238) Enhance Open Write Fail Action feature to allow serving stale copy to all requests during cache refresh.
[ https://issues.apache.org/jira/browse/TS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-4238: -- Summary: Enhance Open Write Fail Action feature to allow serving stale copy to all requests during cache refresh. (was: Enhance Open Write Fail Action feature to allow serving stale copy to all requests while refreshing) > Enhance Open Write Fail Action feature to allow serving stale copy to all > requests during cache refresh. > > > Key: TS-4238 > URL: https://issues.apache.org/jira/browse/TS-4238 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Reporter: Sudheer Vinukonda > > This is a follow up enhancement for TS-3549 (and related jiras). Open Write > Fail Action feature developed with TS-3549 currently allows returning a stale > copy to every client (based on a cache open write failure), except the first > client that initiated a cache revalidation. This jira is opened to enhance > the feature to support returning the stale copy even to the first client, > essentially triggering the revalidation in the background (ala background > fill feature), so as to be able to use the feature as a substitute for SWR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4238) Enhance Open Write Fail Action feature to allow serving stale copy to all requests while refreshing
[ https://issues.apache.org/jira/browse/TS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-4238: -- Summary: Enhance Open Write Fail Action feature to allow serving stale copy to all requests while refreshing (was: Enhance Open Write Fail Action feature to allow serving stale copy to even the first client that initiated a refresh.) > Enhance Open Write Fail Action feature to allow serving stale copy to all > requests while refreshing > --- > > Key: TS-4238 > URL: https://issues.apache.org/jira/browse/TS-4238 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Reporter: Sudheer Vinukonda > > This is a follow up enhancement for TS-3549 (and related jiras). Open Write > Fail Action feature developed with TS-3549 currently allows returning a stale > copy to every client (based on a cache open write failure), except the first > client that initiated a cache revalidation. This jira is opened to enhance > the feature to support returning the stale copy even to the first client, > essentially triggering the revalidation in the background (ala background > fill feature), so as to be able to use the feature as a substitute for SWR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4238) Enhance Open Write Fail Action feature to allow serving stale copy to even the first client that initiated a refresh.
Sudheer Vinukonda created TS-4238: - Summary: Enhance Open Write Fail Action feature to allow serving stale copy to even the first client that initiated a refresh. Key: TS-4238 URL: https://issues.apache.org/jira/browse/TS-4238 Project: Traffic Server Issue Type: New Feature Components: HTTP Reporter: Sudheer Vinukonda This is a follow up enhancement for TS-3549 (and related jiras). Open Write Fail Action feature developed with TS-3549 currently allows returning a stale copy to every client (based on a cache open write failure), except the first client that initiated a cache revalidation. This jira is opened to enhance the feature to support returning the stale copy even to the first client, essentially triggering the revalidation in the background (ala background fill feature), so as to be able to use the feature as a substitute for SWR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4237) Enhance Open Write Fail Action feature to support an option to honor SWR RFC header.
Sudheer Vinukonda created TS-4237:
-
Summary: Enhance Open Write Fail Action feature to support an
option to honor SWR RFC header.
Key: TS-4237
URL: https://issues.apache.org/jira/browse/TS-4237
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Sudheer Vinukonda
This is a follow up enhancement for TS-3549 (and related jiras). Open Write
Fail Action feature developed with TS-3549 currently supports the following
options:
https://docs.trafficserver.apache.org/en/6.0.x/reference/configuration/records.config.en.html#proxy-config-http-cache-open-write-fail-action
{code}
0 = default, disable cache and goto origin server
1 = return a 502 error on a cache miss
2 = serve stale if object’s age is under proxy.config.http.cache.max_stale_age,
else, goto origin server
{code}
This jira is opened to enhance the feature to support a new option to serve
stale honoring the SWR RFC headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4229) proxy.config.http.cache.open_write_fail_action is not in the regression tests
[ https://issues.apache.org/jira/browse/TS-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167358#comment-15167358 ] Sudheer Vinukonda edited comment on TS-4229 at 2/25/16 4:11 PM: The tests for this setting are already in 6.2.0. Updated the docs. was (Author: sudheerv): The tests for this setting are already in 6.2.0. > proxy.config.http.cache.open_write_fail_action is not in the regression tests > - > > Key: TS-4229 > URL: https://issues.apache.org/jira/browse/TS-4229 > Project: Traffic Server > Issue Type: Bug > Components: Tests >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 6.2.0 > > > This is somewhat bad, because it likely succeeds the regression tests for > now, but as soon as someone else adds on to the overridable structs, it will > fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4229) proxy.config.http.cache.open_write_fail_action is not in the regression tests
[ https://issues.apache.org/jira/browse/TS-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-4229. --- Resolution: Invalid The tests for this setting are already in 6.2.0. > proxy.config.http.cache.open_write_fail_action is not in the regression tests > - > > Key: TS-4229 > URL: https://issues.apache.org/jira/browse/TS-4229 > Project: Traffic Server > Issue Type: Bug > Components: Tests >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 6.2.0 > > > This is somewhat bad, because it likely succeeds the regression tests for > now, but as soon as someone else adds on to the overridable structs, it will > fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4229) proxy.config.http.cache.open_write_fail_action is not in the regression tests
[ https://issues.apache.org/jira/browse/TS-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167346#comment-15167346 ] Sudheer Vinukonda commented on TS-4229: --- Hmm, I do see the config part of the tests here: https://github.com/apache/trafficserver/blob/master/proxy/InkAPITest.cc#L7219 Is there some other test I missed? > proxy.config.http.cache.open_write_fail_action is not in the regression tests > - > > Key: TS-4229 > URL: https://issues.apache.org/jira/browse/TS-4229 > Project: Traffic Server > Issue Type: Bug > Components: Tests >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 6.2.0 > > > This is somewhat bad, because it likely succeeds the regression tests for > now, but as soon as someone else adds on to the overridable structs, it will > fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4229) proxy.config.http.cache.open_write_fail_action is not in the regression tests
[ https://issues.apache.org/jira/browse/TS-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167337#comment-15167337 ] Sudheer Vinukonda commented on TS-4229: --- Gah, Sorry for missing the tests and doc updates. Will do it right away. > proxy.config.http.cache.open_write_fail_action is not in the regression tests > - > > Key: TS-4229 > URL: https://issues.apache.org/jira/browse/TS-4229 > Project: Traffic Server > Issue Type: Bug > Components: Tests >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 6.2.0 > > > This is somewhat bad, because it likely succeeds the regression tests for > now, but as soon as someone else adds on to the overridable structs, it will > fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4222) ATS 6.2.0 seg faults while processing ssl_multicert.config
[
https://issues.apache.org/jira/browse/TS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-4222:
--
Backport to Version: 6.1.2
Fix Version/s: 6.2.0
> ATS 6.2.0 seg faults while processing ssl_multicert.config
> --
>
> Key: TS-4222
> URL: https://issues.apache.org/jira/browse/TS-4222
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 6.2.0
>Reporter: Prakhar Rudra
>Assignee: Sudheer Vinukonda
> Fix For: 6.2.0
>
>
> ATS version 6.2.0 segment fault error while checking config using
> traffic_server -Cverify_config
> It occurs after "INFO: Successfully loaded plugin.config"
> only entry in ssl_multicert.config is as below,
> dest_ip=* ssl_cert_name=fullchain1.pem ssl_key_name=privkey1.pem
> gdb --args traffic_server -Cverify_config
> (gdb) run
> yields
> INFO: Successfully loaded plugin.config
> Thread 1 "traffic_server" received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) print SSLConfigParams::load_ssl_file_cb
> $1 = (load_ssl_file_func) 0x0
> Thanks jpeach
> Details:
> http://pastebin.com/K0876r2T
> http://pastebin.com/iP5MAYLu
> Thanks
> Pulling the info from the above pastebin's to jira for posterity.
> {code}
> git clone https://github.com/tatsuhiro-t/spdylay.git
> cd spdylay/
> autoreconf -if
> automake
> autoconf
> ./configure --prefix=/usr
> make
> make install
> cd ../trafficserver/
> autoreconf -if
> export PKG_CONFIG_PATH=/usr/lib/pkgconfig
> ./configure --enable-spdy --enable-experimental-plugins
> --enable-linux-native-aio --with-zlib=/root/c/ats/zlib-1.2.8
> --with-pcre=/root/c/ats/pcre-8.38
> --with-openssl=/root/c/ats/openssl-1.0.1f[WITH CLOUDFLARE PATCH]
> **
> gdb --args traffic_server -Cverify_config
> ...standard info..
> (gdb) run
> Starting program: /usr/local/bin/traffic_server -Cverify_config
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> traffic_server: using root directory '/usr/local'
> [New Thread 0x71f55700 (LWP 19595)]
> NOTE: VERIFY
> [New Thread 0x70c16700 (LWP 19596)]
> [New Thread 0x70a14700 (LWP 19597)]
> INFO:Successfully loaded remap.config
> INFO: Successfully loaded records.config
> INFO: Successfully loaded plugin.config
> Thread 1 "traffic_server" received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) bt full
> #0 0x in ?? ()
> No symbol table info available.
> #1 0x00789374 in SSLInitServerContext
> (params=params@entry=0x117a140, sslMultCertSettings=..., certList=...)
> at SSLUtils.cc:1384
> bio = {_r = 0x1181f50}
> cert = 0x1182100
> ca =
> certname =
> cert_tok = {_data = , _delimiter = 44 ',', _mode = 0,
> _escape = 92 '\\', _start = ,
> _length = }
> key_tok = {_data = , _delimiter = 44 ',', _mode = 0,
> _escape = 92 '\\', _start = 0,
> _length = }
> ca_tok = {_data = , _delimiter = 44 ',', _mode = 0,
> _escape = 92 '\\', _start = 0,
> _length = }
> server_verify_client =
> completeServerCertPath =
> ctx =
> digest = {digest = 0x0, engine = 0x77ffe4e0, flags =
> 140737488346576, md_data = 0x1f7ff7600, pctx = 0x77ffe188,
> update = 0x7fffddc0}
> ca_list = 0x0
> hash_buf =
> "\277\037D\000\000\000\000\000~KgY\000\000\000\000\377\377\377\377\000\000\000\000@\241\027\001\000\000\000\000\b\206\271\367\377\177\000\000\000v\377\367\377\177\000\000)\371\203\000\000\000\000\000\000l\231\365\377\177\000"
> hash_len = 0
> __FUNCTION__ = "SSLInitServerContext"
> additional_cache_flags =
> ud = {_configParams = 0x117a140, _serverDialog = 0x0, _serverCert =
> 0x117cef0 "fullchain1.pem",
> _serverKey = 0x117ceb0 "privkey1.pem"}
> #2 0x0078a370 in ssl_store_ssl_context
> (params=params@entry=0x117a140, lookup=lookup@entry=0x117c550,
> sslMultCertSettings=...) at SSLUtils.cc:1666
> cert_list = {n = 1, i = 0, v = 0x7fffded8, e = {0x1182100, 0x0,
> 0x0, 0x0}}
> ctx =
> keyblock =
> inserted =
> #3 0x0078b5e5 in SSLParseCertificateConfiguration
> (params=params@entry=0x117a140, lookup=lookup@entry=0x117c550)
> at SSLUtils.cc:1902
> sslMultiCertSettings = {session_ticket_enabled = 1, addr =
> { >> = {
> _r = 0x0}, }, cert =
> { >> = {
> _r = 0x117ce90 "fullchain1.pem"}, },
> first_cert =
> { >> = {
> _r = 0x117cef0 "fullchain1.pem"}, },
> ca = { >> =
> {_r = 0x0}, },
> key = { >> =
> {_r = 0x117ceb0 "privkey1.pem"}, },
> ticket_key
[jira] [Resolved] (TS-4222) ATS 6.2.0 seg faults while processing ssl_multicert.config
[
https://issues.apache.org/jira/browse/TS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda resolved TS-4222.
---
Resolution: Fixed
> ATS 6.2.0 seg faults while processing ssl_multicert.config
> --
>
> Key: TS-4222
> URL: https://issues.apache.org/jira/browse/TS-4222
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 6.2.0
>Reporter: Prakhar Rudra
>Assignee: Sudheer Vinukonda
> Fix For: 6.2.0
>
>
> ATS version 6.2.0 segment fault error while checking config using
> traffic_server -Cverify_config
> It occurs after "INFO: Successfully loaded plugin.config"
> only entry in ssl_multicert.config is as below,
> dest_ip=* ssl_cert_name=fullchain1.pem ssl_key_name=privkey1.pem
> gdb --args traffic_server -Cverify_config
> (gdb) run
> yields
> INFO: Successfully loaded plugin.config
> Thread 1 "traffic_server" received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) print SSLConfigParams::load_ssl_file_cb
> $1 = (load_ssl_file_func) 0x0
> Thanks jpeach
> Details:
> http://pastebin.com/K0876r2T
> http://pastebin.com/iP5MAYLu
> Thanks
> Pulling the info from the above pastebin's to jira for posterity.
> {code}
> git clone https://github.com/tatsuhiro-t/spdylay.git
> cd spdylay/
> autoreconf -if
> automake
> autoconf
> ./configure --prefix=/usr
> make
> make install
> cd ../trafficserver/
> autoreconf -if
> export PKG_CONFIG_PATH=/usr/lib/pkgconfig
> ./configure --enable-spdy --enable-experimental-plugins
> --enable-linux-native-aio --with-zlib=/root/c/ats/zlib-1.2.8
> --with-pcre=/root/c/ats/pcre-8.38
> --with-openssl=/root/c/ats/openssl-1.0.1f[WITH CLOUDFLARE PATCH]
> **
> gdb --args traffic_server -Cverify_config
> ...standard info..
> (gdb) run
> Starting program: /usr/local/bin/traffic_server -Cverify_config
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> traffic_server: using root directory '/usr/local'
> [New Thread 0x71f55700 (LWP 19595)]
> NOTE: VERIFY
> [New Thread 0x70c16700 (LWP 19596)]
> [New Thread 0x70a14700 (LWP 19597)]
> INFO:Successfully loaded remap.config
> INFO: Successfully loaded records.config
> INFO: Successfully loaded plugin.config
> Thread 1 "traffic_server" received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) bt full
> #0 0x in ?? ()
> No symbol table info available.
> #1 0x00789374 in SSLInitServerContext
> (params=params@entry=0x117a140, sslMultCertSettings=..., certList=...)
> at SSLUtils.cc:1384
> bio = {_r = 0x1181f50}
> cert = 0x1182100
> ca =
> certname =
> cert_tok = {_data = , _delimiter = 44 ',', _mode = 0,
> _escape = 92 '\\', _start = ,
> _length = }
> key_tok = {_data = , _delimiter = 44 ',', _mode = 0,
> _escape = 92 '\\', _start = 0,
> _length = }
> ca_tok = {_data = , _delimiter = 44 ',', _mode = 0,
> _escape = 92 '\\', _start = 0,
> _length = }
> server_verify_client =
> completeServerCertPath =
> ctx =
> digest = {digest = 0x0, engine = 0x77ffe4e0, flags =
> 140737488346576, md_data = 0x1f7ff7600, pctx = 0x77ffe188,
> update = 0x7fffddc0}
> ca_list = 0x0
> hash_buf =
> "\277\037D\000\000\000\000\000~KgY\000\000\000\000\377\377\377\377\000\000\000\000@\241\027\001\000\000\000\000\b\206\271\367\377\177\000\000\000v\377\367\377\177\000\000)\371\203\000\000\000\000\000\000l\231\365\377\177\000"
> hash_len = 0
> __FUNCTION__ = "SSLInitServerContext"
> additional_cache_flags =
> ud = {_configParams = 0x117a140, _serverDialog = 0x0, _serverCert =
> 0x117cef0 "fullchain1.pem",
> _serverKey = 0x117ceb0 "privkey1.pem"}
> #2 0x0078a370 in ssl_store_ssl_context
> (params=params@entry=0x117a140, lookup=lookup@entry=0x117c550,
> sslMultCertSettings=...) at SSLUtils.cc:1666
> cert_list = {n = 1, i = 0, v = 0x7fffded8, e = {0x1182100, 0x0,
> 0x0, 0x0}}
> ctx =
> keyblock =
> inserted =
> #3 0x0078b5e5 in SSLParseCertificateConfiguration
> (params=params@entry=0x117a140, lookup=lookup@entry=0x117c550)
> at SSLUtils.cc:1902
> sslMultiCertSettings = {session_ticket_enabled = 1, addr =
> { >> = {
> _r = 0x0}, }, cert =
> { >> = {
> _r = 0x117ce90 "fullchain1.pem"}, },
> first_cert =
> { >> = {
> _r = 0x117cef0 "fullchain1.pem"}, },
> ca = { >> =
> {_r = 0x0}, },
> key = { >> =
> {_r = 0x117ceb0 "privkey1.pem"}, },
> ticket_key_filename =
> { >> = {_r = 0x0}, dat
[jira] [Updated] (TS-4222) ATS 6.2.0 seg faults while processing ssl_multicert.config
[
https://issues.apache.org/jira/browse/TS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-4222:
--
Description:
ATS version 6.2.0 segment fault error while checking config using
traffic_server -Cverify_config
It occurs after "INFO: Successfully loaded plugin.config"
only entry in ssl_multicert.config is as below,
dest_ip=* ssl_cert_name=fullchain1.pem ssl_key_name=privkey1.pem
gdb --args traffic_server -Cverify_config
(gdb) run
yields
INFO: Successfully loaded plugin.config
Thread 1 "traffic_server" received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) print SSLConfigParams::load_ssl_file_cb
$1 = (load_ssl_file_func) 0x0
Thanks jpeach
Details:
http://pastebin.com/K0876r2T
http://pastebin.com/iP5MAYLu
Thanks
Pulling the info from the above pastebin's to jira for posterity.
{code}
git clone https://github.com/tatsuhiro-t/spdylay.git
cd spdylay/
autoreconf -if
automake
autoconf
./configure --prefix=/usr
make
make install
cd ../trafficserver/
autoreconf -if
export PKG_CONFIG_PATH=/usr/lib/pkgconfig
./configure --enable-spdy --enable-experimental-plugins
--enable-linux-native-aio --with-zlib=/root/c/ats/zlib-1.2.8
--with-pcre=/root/c/ats/pcre-8.38
--with-openssl=/root/c/ats/openssl-1.0.1f[WITH CLOUDFLARE PATCH]
**
gdb --args traffic_server -Cverify_config
...standard info..
(gdb) run
Starting program: /usr/local/bin/traffic_server -Cverify_config
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
traffic_server: using root directory '/usr/local'
[New Thread 0x71f55700 (LWP 19595)]
NOTE: VERIFY
[New Thread 0x70c16700 (LWP 19596)]
[New Thread 0x70a14700 (LWP 19597)]
INFO:Successfully loaded remap.config
INFO: Successfully loaded records.config
INFO: Successfully loaded plugin.config
Thread 1 "traffic_server" received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt full
#0 0x in ?? ()
No symbol table info available.
#1 0x00789374 in SSLInitServerContext (params=params@entry=0x117a140,
sslMultCertSettings=..., certList=...)
at SSLUtils.cc:1384
bio = {_r = 0x1181f50}
cert = 0x1182100
ca =
certname =
cert_tok = {_data = , _delimiter = 44 ',', _mode = 0,
_escape = 92 '\\', _start = ,
_length = }
key_tok = {_data = , _delimiter = 44 ',', _mode = 0,
_escape = 92 '\\', _start = 0,
_length = }
ca_tok = {_data = , _delimiter = 44 ',', _mode = 0,
_escape = 92 '\\', _start = 0,
_length = }
server_verify_client =
completeServerCertPath =
ctx =
digest = {digest = 0x0, engine = 0x77ffe4e0, flags =
140737488346576, md_data = 0x1f7ff7600, pctx = 0x77ffe188,
update = 0x7fffddc0}
ca_list = 0x0
hash_buf =
"\277\037D\000\000\000\000\000~KgY\000\000\000\000\377\377\377\377\000\000\000\000@\241\027\001\000\000\000\000\b\206\271\367\377\177\000\000\000v\377\367\377\177\000\000)\371\203\000\000\000\000\000\000l\231\365\377\177\000"
hash_len = 0
__FUNCTION__ = "SSLInitServerContext"
additional_cache_flags =
ud = {_configParams = 0x117a140, _serverDialog = 0x0, _serverCert =
0x117cef0 "fullchain1.pem",
_serverKey = 0x117ceb0 "privkey1.pem"}
#2 0x0078a370 in ssl_store_ssl_context (params=params@entry=0x117a140,
lookup=lookup@entry=0x117c550,
sslMultCertSettings=...) at SSLUtils.cc:1666
cert_list = {n = 1, i = 0, v = 0x7fffded8, e = {0x1182100, 0x0,
0x0, 0x0}}
ctx =
keyblock =
inserted =
#3 0x0078b5e5 in SSLParseCertificateConfiguration
(params=params@entry=0x117a140, lookup=lookup@entry=0x117c550)
at SSLUtils.cc:1902
sslMultiCertSettings = {session_ticket_enabled = 1, addr =
{ >> = {
_r = 0x0}, }, cert =
{ >> = {
_r = 0x117ce90 "fullchain1.pem"}, },
first_cert = {
>> = {
_r = 0x117cef0 "fullchain1.pem"}, },
ca = { >> =
{_r = 0x0}, },
key = { >> =
{_r = 0x117ceb0 "privkey1.pem"}, },
ticket_key_filename =
{ >> = {_r = 0x0}, },
---Type to continue, or q to quit---
dialog = { >>
= {_r = 0x0}, },
opt = SSLCertContext::OPT_NONE}
errPtr =
tok_state = 0x1180cfe ""
line =
file_buf =
line_num = 73
line_info = {type = MATCH_NONE, dest_entry = 0, num_el = 2, line =
{{0x1180cc8 "ssl_cert_name", 0x1180ce5 "ssl_key_name",
0x0 }, {0x1180cd6 "fullchain1.pem", 0x1180cf2
"privkey1.pem", 0x0 }},
line_num = 0, next = 0x0}
sslCertTags = {match_host = 0x0, match_domain = 0x0, match_ip = 0x0,
match_regex = 0x0, match_url = 0x0,
match_host_regex = 0x0, dest_error_msg = false}
__FUNCT
[jira] [Assigned] (TS-4222) ATS 6.2.0 seg faults while processing ssl_multicert.config
[ https://issues.apache.org/jira/browse/TS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-4222: - Assignee: Sudheer Vinukonda > ATS 6.2.0 seg faults while processing ssl_multicert.config > -- > > Key: TS-4222 > URL: https://issues.apache.org/jira/browse/TS-4222 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Affects Versions: 6.2.0 >Reporter: Prakhar Rudra >Assignee: Sudheer Vinukonda > > ATS version 6.2.0 segment fault error while checking config using > traffic_server -Cverify_config > It occurs after "INFO: Successfully loaded plugin.config" > only entry in ssl_multicert.config is as below, > dest_ip=* ssl_cert_name=fullchain1.pem ssl_key_name=privkey1.pem > gdb --args traffic_server -Cverify_config > (gdb) run > yields > INFO: Successfully loaded plugin.config > Thread 1 "traffic_server" received signal SIGSEGV, Segmentation fault. > 0x in ?? () > (gdb) print SSLConfigParams::load_ssl_file_cb > $1 = (load_ssl_file_func) 0x0 > Thanks jpeach > Details: > http://pastebin.com/K0876r2T > http://pastebin.com/iP5MAYLu > Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4160) MLocRelease for txn buffers called too late in CPP API resulting buffer corruption
[
https://issues.apache.org/jira/browse/TS-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149089#comment-15149089
]
Sudheer Vinukonda commented on TS-4160:
---
Yeah, this is resolved. [~boazr] will open a new jira to track cleaning up of
caching these handles from the Transaction object altogether
> MLocRelease for txn buffers called too late in CPP API resulting buffer
> corruption
> --
>
> Key: TS-4160
> URL: https://issues.apache.org/jira/browse/TS-4160
> Project: Traffic Server
> Issue Type: Bug
> Components: CPP API
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Labels: yahoo
> Fix For: 6.2.0
>
>
> CPP API currently acquires the buffer and heap handles for various kinds of
> request/response objects (e.g cached_request_hdr_buf, cached_request_hdr_loc,
> client_response_hdr_buf, client_response_hdr_loc etc) at the corresponding
> hooks of a transaction, along with the url handles in the CPP API's
> request/response objects, but keeps them until txn_close, before calling
> MLocRelease on them finally.
> However, this is buggy, since the core doesn't seem to guarantee the life of
> these handles until the end of the transaction. In particular, the
> cached_request_hdr_buf/loc are released at the end of
> tunnel_handler_cache_read(), which causes it to be reassigned to a different
> txn and results in a crash when the original txn finally tries to release
> them triggering the asserts from the MLocRelease C API. Another case is
> internal redirect follow in the core, which destroys and recreates some of
> these buffers.
> Note that the C API plugins typically call MLocRelease immediately after
> acquiring/using them.
> Additionally, the order in which CPP API releases the handles is incorrect.
> Transaction object contains the Request objects and Transaction object's
> destructor first calls MLocRelease on the request heap handles, before which
> the Request object's d'tor is triggered which calls the url handle in that
> released request handle. This may not be a problem right now, since
> MLocRelease for HTTP_OBJ and URL_OBJ are basically no-ops, but, the order of
> release still breaks the implicit contract of the API, which requires the
> child to be released before releasing the parent (which means, if the API's
> internal implementation changes tomorrow, that can cause a problem).
> Here are the back traces for the issues mentioned above:
> {code}
> (gdb) bt
> #0 0x003c1b232625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x003c1b233e05 in abort () at abort.c:92
> #2 0x2b149d517018 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2b149d5170e5 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1, message_format=0x2b149d525d78
> "%s:%d: failed assert `%s`", ap=0x2b14a4806570) at ink_error.cc:65
> #4 0x2b149d5171ae in ink_fatal (return_code=1,
> message_format=0x2b149d525d78 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2b149d515d20 in _ink_assert (expression=0x771185 "!\"invalid
> mloc\"", file=0x770f1d "InkAPI.cc", line=1886) at ink_assert.cc:37
> #6 0x0050f809 in TSHandleMLocRelease (bufp=0x2b15e82357f0,
> parent=0x2b15e40fca98, mloc=0x2b15e40fcd18) at InkAPI.cc:1886
> #7 0x2b15759066fc in atscppapi::Request::~Request (this=0x2b15e0003318,
> __in_chrg=) at Request.cc:179
> #8 0x2b1575902131 in ~TransactionState (this=0x2b15e0001320,
> __in_chrg=) at Transaction.cc:40
> #9 atscppapi::Transaction::~Transaction (this=0x2b15e0001320,
> __in_chrg=) at Transaction.cc:111
> #10 0x2b1575901031 in (anonymous namespace)::handleTransactionEvents
> (cont=, event=,
> edata=0x2b15e8235460) at utils_internal.cc:87
> #11 0x0050d7f0 in INKContInternal::handle_event (this=0x20399b0,
> event=60012, edata=0x2b15e8235460) at InkAPI.cc:1000
> #12 0x004f8dee in Continuation::handleEvent (this=0x20399b0,
> event=60012, data=0x2b15e8235460) at
> ../iocore/eventsystem/I_Continuation.h:146
> #13 0x0050e037 in APIHook::invoke (this=0x202b170, event=60012,
> edata=0x2b15e8235460) at InkAPI.cc:1219
> #14 0x005cfb5d in HttpSM::state_api_callout (this=0x2b15e8235460,
> event=0, data=0x0) at HttpSM.cc:1384
> #15 0x005dba75 in HttpSM::do_api_callout_internal
> (this=0x2b15e8235460) at HttpSM.cc:4896
> #16 0x005e8b2a in HttpSM::do_api_callout (this=0x2b15e8235460) at
> HttpSM.cc:437
> #17 0x005e0ed0 in HttpSM::kill_this (this=0x2b15e8235460) at
> HttpSM.cc:6615
> #18 0x005d358f in HttpSM::main_handler (this=0x2b15e8235460,
> event=2301, data=0x2b15e82360a0) at HttpSM.cc:2556
>
[jira] [Resolved] (TS-4160) MLocRelease for txn buffers called too late in CPP API resulting buffer corruption
[
https://issues.apache.org/jira/browse/TS-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda resolved TS-4160.
---
Resolution: Fixed
> MLocRelease for txn buffers called too late in CPP API resulting buffer
> corruption
> --
>
> Key: TS-4160
> URL: https://issues.apache.org/jira/browse/TS-4160
> Project: Traffic Server
> Issue Type: Bug
> Components: CPP API
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Labels: yahoo
> Fix For: 6.2.0
>
>
> CPP API currently acquires the buffer and heap handles for various kinds of
> request/response objects (e.g cached_request_hdr_buf, cached_request_hdr_loc,
> client_response_hdr_buf, client_response_hdr_loc etc) at the corresponding
> hooks of a transaction, along with the url handles in the CPP API's
> request/response objects, but keeps them until txn_close, before calling
> MLocRelease on them finally.
> However, this is buggy, since the core doesn't seem to guarantee the life of
> these handles until the end of the transaction. In particular, the
> cached_request_hdr_buf/loc are released at the end of
> tunnel_handler_cache_read(), which causes it to be reassigned to a different
> txn and results in a crash when the original txn finally tries to release
> them triggering the asserts from the MLocRelease C API. Another case is
> internal redirect follow in the core, which destroys and recreates some of
> these buffers.
> Note that the C API plugins typically call MLocRelease immediately after
> acquiring/using them.
> Additionally, the order in which CPP API releases the handles is incorrect.
> Transaction object contains the Request objects and Transaction object's
> destructor first calls MLocRelease on the request heap handles, before which
> the Request object's d'tor is triggered which calls the url handle in that
> released request handle. This may not be a problem right now, since
> MLocRelease for HTTP_OBJ and URL_OBJ are basically no-ops, but, the order of
> release still breaks the implicit contract of the API, which requires the
> child to be released before releasing the parent (which means, if the API's
> internal implementation changes tomorrow, that can cause a problem).
> Here are the back traces for the issues mentioned above:
> {code}
> (gdb) bt
> #0 0x003c1b232625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x003c1b233e05 in abort () at abort.c:92
> #2 0x2b149d517018 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2b149d5170e5 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1, message_format=0x2b149d525d78
> "%s:%d: failed assert `%s`", ap=0x2b14a4806570) at ink_error.cc:65
> #4 0x2b149d5171ae in ink_fatal (return_code=1,
> message_format=0x2b149d525d78 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2b149d515d20 in _ink_assert (expression=0x771185 "!\"invalid
> mloc\"", file=0x770f1d "InkAPI.cc", line=1886) at ink_assert.cc:37
> #6 0x0050f809 in TSHandleMLocRelease (bufp=0x2b15e82357f0,
> parent=0x2b15e40fca98, mloc=0x2b15e40fcd18) at InkAPI.cc:1886
> #7 0x2b15759066fc in atscppapi::Request::~Request (this=0x2b15e0003318,
> __in_chrg=) at Request.cc:179
> #8 0x2b1575902131 in ~TransactionState (this=0x2b15e0001320,
> __in_chrg=) at Transaction.cc:40
> #9 atscppapi::Transaction::~Transaction (this=0x2b15e0001320,
> __in_chrg=) at Transaction.cc:111
> #10 0x2b1575901031 in (anonymous namespace)::handleTransactionEvents
> (cont=, event=,
> edata=0x2b15e8235460) at utils_internal.cc:87
> #11 0x0050d7f0 in INKContInternal::handle_event (this=0x20399b0,
> event=60012, edata=0x2b15e8235460) at InkAPI.cc:1000
> #12 0x004f8dee in Continuation::handleEvent (this=0x20399b0,
> event=60012, data=0x2b15e8235460) at
> ../iocore/eventsystem/I_Continuation.h:146
> #13 0x0050e037 in APIHook::invoke (this=0x202b170, event=60012,
> edata=0x2b15e8235460) at InkAPI.cc:1219
> #14 0x005cfb5d in HttpSM::state_api_callout (this=0x2b15e8235460,
> event=0, data=0x0) at HttpSM.cc:1384
> #15 0x005dba75 in HttpSM::do_api_callout_internal
> (this=0x2b15e8235460) at HttpSM.cc:4896
> #16 0x005e8b2a in HttpSM::do_api_callout (this=0x2b15e8235460) at
> HttpSM.cc:437
> #17 0x005e0ed0 in HttpSM::kill_this (this=0x2b15e8235460) at
> HttpSM.cc:6615
> #18 0x005d358f in HttpSM::main_handler (this=0x2b15e8235460,
> event=2301, data=0x2b15e82360a0) at HttpSM.cc:2556
> #19 0x004f8dee in Continuation::handleEvent (this=0x2b15e8235460,
> event=2301, data=0x2b15e82360a0) at ../iocore/eventsystem/I_Continuation.h:146
> #20 0x00
[jira] [Commented] (TS-4156) remove the traffic_sac, stand alone log collation server
[ https://issues.apache.org/jira/browse/TS-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15124973#comment-15124973 ] Sudheer Vinukonda commented on TS-4156: --- It might be better to do this in 7.0 to avoid any potential backward compatibility issues? > remove the traffic_sac, stand alone log collation server > > > Key: TS-4156 > URL: https://issues.apache.org/jira/browse/TS-4156 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: sometime > > > the stand alone collation server act as a dedicated log server from ATS, this > is a dedicated log product back in the Inktomi age, and we don't need it as > this functions are build into the traffic_server binary for free distribution. > it is time to nuke it down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4160) MLocRelease for txn buffers called too late in CPP API resulting buffer corruption
[
https://issues.apache.org/jira/browse/TS-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-4160:
--
Affects Version/s: 6.1.0
Fix Version/s: 6.1.0
> MLocRelease for txn buffers called too late in CPP API resulting buffer
> corruption
> --
>
> Key: TS-4160
> URL: https://issues.apache.org/jira/browse/TS-4160
> Project: Traffic Server
> Issue Type: Bug
> Components: CPP API
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Labels: yahoo
> Fix For: 6.1.0
>
>
> CPP API currently acquires the buffer and heap handles for various kinds of
> request/response objects (e.g cached_request_hdr_buf, cached_request_hdr_loc,
> client_response_hdr_buf, client_response_hdr_loc etc) at the corresponding
> hooks of a transaction, along with the url handles in the CPP API's
> request/response objects, but keeps them until txn_close, before calling
> MLocRelease on them finally.
> However, this is buggy, since the core doesn't seem to guarantee the life of
> these handles until the end of the transaction. In particular, the
> cached_request_hdr_buf/loc are released at the end of
> tunnel_handler_cache_read(), which causes it to be reassigned to a different
> txn and results in a crash when the original txn finally tries to release
> them triggering the asserts from the MLocRelease C API. Another case is
> internal redirect follow in the core, which destroys and recreates some of
> these buffers.
> Note that the C API plugins typically call MLocRelease immediately after
> acquiring/using them.
> Additionally, the order in which CPP API releases the handles is incorrect.
> Transaction object contains the Request objects and Transaction object's
> destructor first calls MLocRelease on the request heap handles, before which
> the Request object's d'tor is triggered which calls the url handle in that
> released request handle. This may not be a problem right now, since
> MLocRelease for HTTP_OBJ and URL_OBJ are basically no-ops, but, the order of
> release still breaks the implicit contract of the API, which requires the
> child to be released before releasing the parent (which means, if the API's
> internal implementation changes tomorrow, that can cause a problem).
> Here are the back traces for the issues mentioned above:
> {code}
> (gdb) bt
> #0 0x003c1b232625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x003c1b233e05 in abort () at abort.c:92
> #2 0x2b149d517018 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2b149d5170e5 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1, message_format=0x2b149d525d78
> "%s:%d: failed assert `%s`", ap=0x2b14a4806570) at ink_error.cc:65
> #4 0x2b149d5171ae in ink_fatal (return_code=1,
> message_format=0x2b149d525d78 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2b149d515d20 in _ink_assert (expression=0x771185 "!\"invalid
> mloc\"", file=0x770f1d "InkAPI.cc", line=1886) at ink_assert.cc:37
> #6 0x0050f809 in TSHandleMLocRelease (bufp=0x2b15e82357f0,
> parent=0x2b15e40fca98, mloc=0x2b15e40fcd18) at InkAPI.cc:1886
> #7 0x2b15759066fc in atscppapi::Request::~Request (this=0x2b15e0003318,
> __in_chrg=) at Request.cc:179
> #8 0x2b1575902131 in ~TransactionState (this=0x2b15e0001320,
> __in_chrg=) at Transaction.cc:40
> #9 atscppapi::Transaction::~Transaction (this=0x2b15e0001320,
> __in_chrg=) at Transaction.cc:111
> #10 0x2b1575901031 in (anonymous namespace)::handleTransactionEvents
> (cont=, event=,
> edata=0x2b15e8235460) at utils_internal.cc:87
> #11 0x0050d7f0 in INKContInternal::handle_event (this=0x20399b0,
> event=60012, edata=0x2b15e8235460) at InkAPI.cc:1000
> #12 0x004f8dee in Continuation::handleEvent (this=0x20399b0,
> event=60012, data=0x2b15e8235460) at
> ../iocore/eventsystem/I_Continuation.h:146
> #13 0x0050e037 in APIHook::invoke (this=0x202b170, event=60012,
> edata=0x2b15e8235460) at InkAPI.cc:1219
> #14 0x005cfb5d in HttpSM::state_api_callout (this=0x2b15e8235460,
> event=0, data=0x0) at HttpSM.cc:1384
> #15 0x005dba75 in HttpSM::do_api_callout_internal
> (this=0x2b15e8235460) at HttpSM.cc:4896
> #16 0x005e8b2a in HttpSM::do_api_callout (this=0x2b15e8235460) at
> HttpSM.cc:437
> #17 0x005e0ed0 in HttpSM::kill_this (this=0x2b15e8235460) at
> HttpSM.cc:6615
> #18 0x005d358f in HttpSM::main_handler (this=0x2b15e8235460,
> event=2301, data=0x2b15e82360a0) at HttpSM.cc:2556
> #19 0x004f8dee in Continuation::handleEvent (this=0x2b15e8235460,
> event=2301, data=0x2b15e82360a0) at ../iocore/eventsystem/I_Con
[jira] [Updated] (TS-4160) MLocRelease for txn buffers called too late in CPP API resulting buffer corruption
[
https://issues.apache.org/jira/browse/TS-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-4160:
--
Labels: yahoo (was: )
> MLocRelease for txn buffers called too late in CPP API resulting buffer
> corruption
> --
>
> Key: TS-4160
> URL: https://issues.apache.org/jira/browse/TS-4160
> Project: Traffic Server
> Issue Type: Bug
> Components: CPP API
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Labels: yahoo
> Fix For: 6.1.0
>
>
> CPP API currently acquires the buffer and heap handles for various kinds of
> request/response objects (e.g cached_request_hdr_buf, cached_request_hdr_loc,
> client_response_hdr_buf, client_response_hdr_loc etc) at the corresponding
> hooks of a transaction, along with the url handles in the CPP API's
> request/response objects, but keeps them until txn_close, before calling
> MLocRelease on them finally.
> However, this is buggy, since the core doesn't seem to guarantee the life of
> these handles until the end of the transaction. In particular, the
> cached_request_hdr_buf/loc are released at the end of
> tunnel_handler_cache_read(), which causes it to be reassigned to a different
> txn and results in a crash when the original txn finally tries to release
> them triggering the asserts from the MLocRelease C API. Another case is
> internal redirect follow in the core, which destroys and recreates some of
> these buffers.
> Note that the C API plugins typically call MLocRelease immediately after
> acquiring/using them.
> Additionally, the order in which CPP API releases the handles is incorrect.
> Transaction object contains the Request objects and Transaction object's
> destructor first calls MLocRelease on the request heap handles, before which
> the Request object's d'tor is triggered which calls the url handle in that
> released request handle. This may not be a problem right now, since
> MLocRelease for HTTP_OBJ and URL_OBJ are basically no-ops, but, the order of
> release still breaks the implicit contract of the API, which requires the
> child to be released before releasing the parent (which means, if the API's
> internal implementation changes tomorrow, that can cause a problem).
> Here are the back traces for the issues mentioned above:
> {code}
> (gdb) bt
> #0 0x003c1b232625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x003c1b233e05 in abort () at abort.c:92
> #2 0x2b149d517018 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2b149d5170e5 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1, message_format=0x2b149d525d78
> "%s:%d: failed assert `%s`", ap=0x2b14a4806570) at ink_error.cc:65
> #4 0x2b149d5171ae in ink_fatal (return_code=1,
> message_format=0x2b149d525d78 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2b149d515d20 in _ink_assert (expression=0x771185 "!\"invalid
> mloc\"", file=0x770f1d "InkAPI.cc", line=1886) at ink_assert.cc:37
> #6 0x0050f809 in TSHandleMLocRelease (bufp=0x2b15e82357f0,
> parent=0x2b15e40fca98, mloc=0x2b15e40fcd18) at InkAPI.cc:1886
> #7 0x2b15759066fc in atscppapi::Request::~Request (this=0x2b15e0003318,
> __in_chrg=) at Request.cc:179
> #8 0x2b1575902131 in ~TransactionState (this=0x2b15e0001320,
> __in_chrg=) at Transaction.cc:40
> #9 atscppapi::Transaction::~Transaction (this=0x2b15e0001320,
> __in_chrg=) at Transaction.cc:111
> #10 0x2b1575901031 in (anonymous namespace)::handleTransactionEvents
> (cont=, event=,
> edata=0x2b15e8235460) at utils_internal.cc:87
> #11 0x0050d7f0 in INKContInternal::handle_event (this=0x20399b0,
> event=60012, edata=0x2b15e8235460) at InkAPI.cc:1000
> #12 0x004f8dee in Continuation::handleEvent (this=0x20399b0,
> event=60012, data=0x2b15e8235460) at
> ../iocore/eventsystem/I_Continuation.h:146
> #13 0x0050e037 in APIHook::invoke (this=0x202b170, event=60012,
> edata=0x2b15e8235460) at InkAPI.cc:1219
> #14 0x005cfb5d in HttpSM::state_api_callout (this=0x2b15e8235460,
> event=0, data=0x0) at HttpSM.cc:1384
> #15 0x005dba75 in HttpSM::do_api_callout_internal
> (this=0x2b15e8235460) at HttpSM.cc:4896
> #16 0x005e8b2a in HttpSM::do_api_callout (this=0x2b15e8235460) at
> HttpSM.cc:437
> #17 0x005e0ed0 in HttpSM::kill_this (this=0x2b15e8235460) at
> HttpSM.cc:6615
> #18 0x005d358f in HttpSM::main_handler (this=0x2b15e8235460,
> event=2301, data=0x2b15e82360a0) at HttpSM.cc:2556
> #19 0x004f8dee in Continuation::handleEvent (this=0x2b15e8235460,
> event=2301, data=0x2b15e82360a0) at ../iocore/eventsystem/I_Continuation.h:146
> #20 0x000
[jira] [Updated] (TS-4160) MLocRelease for txn buffers called too late in CPP API resulting buffer corruption
[
https://issues.apache.org/jira/browse/TS-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-4160:
--
Description:
CPP API currently acquires the buffer and heap handles for various kinds of
request/response objects (e.g cached_request_hdr_buf, cached_request_hdr_loc,
client_response_hdr_buf, client_response_hdr_loc etc) at the corresponding
hooks of a transaction, along with the url handles in the CPP API's
request/response objects, but keeps them until txn_close, before calling
MLocRelease on them finally.
However, this is buggy, since the core doesn't seem to guarantee the life of
these handles until the end of the transaction. In particular, the
cached_request_hdr_buf/loc are released at the end of
tunnel_handler_cache_read(), which causes it to be reassigned to a different
txn and results in a crash when the original txn finally tries to release them
triggering the asserts from the MLocRelease C API. Another case is internal
redirect follow in the core, which destroys and recreates some of these buffers.
Note that the C API plugins typically call MLocRelease immediately after
acquiring/using them.
Additionally, the order in which CPP API releases the handles is incorrect.
Transaction object contains the Request objects and Transaction object's
destructor first calls MLocRelease on the request heap handles, before which
the Request object's d'tor is triggered which calls the url handle in that
released request handle. This may not be a problem right now, since MLocRelease
for HTTP_OBJ and URL_OBJ are basically no-ops, but, the order of release still
breaks the implicit contract of the API, which requires the child to be
released before releasing the parent (which means, if the API's internal
implementation changes tomorrow, that can cause a problem).
Here are the back traces for the issues mentioned above:
{code}
(gdb) bt
#0 0x003c1b232625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x003c1b233e05 in abort () at abort.c:92
#2 0x2b149d517018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b149d5170e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2b149d525d78 "%s:%d: failed
assert `%s`", ap=0x2b14a4806570) at ink_error.cc:65
#4 0x2b149d5171ae in ink_fatal (return_code=1,
message_format=0x2b149d525d78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2b149d515d20 in _ink_assert (expression=0x771185 "!\"invalid mloc\"",
file=0x770f1d "InkAPI.cc", line=1886) at ink_assert.cc:37
#6 0x0050f809 in TSHandleMLocRelease (bufp=0x2b15e82357f0,
parent=0x2b15e40fca98, mloc=0x2b15e40fcd18) at InkAPI.cc:1886
#7 0x2b15759066fc in atscppapi::Request::~Request (this=0x2b15e0003318,
__in_chrg=) at Request.cc:179
#8 0x2b1575902131 in ~TransactionState (this=0x2b15e0001320,
__in_chrg=) at Transaction.cc:40
#9 atscppapi::Transaction::~Transaction (this=0x2b15e0001320, __in_chrg=) at Transaction.cc:111
#10 0x2b1575901031 in (anonymous namespace)::handleTransactionEvents
(cont=, event=, edata=0x2b15e8235460)
at utils_internal.cc:87
#11 0x0050d7f0 in INKContInternal::handle_event (this=0x20399b0,
event=60012, edata=0x2b15e8235460) at InkAPI.cc:1000
#12 0x004f8dee in Continuation::handleEvent (this=0x20399b0,
event=60012, data=0x2b15e8235460) at ../iocore/eventsystem/I_Continuation.h:146
#13 0x0050e037 in APIHook::invoke (this=0x202b170, event=60012,
edata=0x2b15e8235460) at InkAPI.cc:1219
#14 0x005cfb5d in HttpSM::state_api_callout (this=0x2b15e8235460,
event=0, data=0x0) at HttpSM.cc:1384
#15 0x005dba75 in HttpSM::do_api_callout_internal (this=0x2b15e8235460)
at HttpSM.cc:4896
#16 0x005e8b2a in HttpSM::do_api_callout (this=0x2b15e8235460) at
HttpSM.cc:437
#17 0x005e0ed0 in HttpSM::kill_this (this=0x2b15e8235460) at
HttpSM.cc:6615
#18 0x005d358f in HttpSM::main_handler (this=0x2b15e8235460,
event=2301, data=0x2b15e82360a0) at HttpSM.cc:2556
#19 0x004f8dee in Continuation::handleEvent (this=0x2b15e8235460,
event=2301, data=0x2b15e82360a0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0061cebf in HttpTunnel::main_handler (this=0x2b15e82360a0,
event=103, data=0x2b15fc01e2e8) at HttpTunnel.cc:1537
#21 0x004f8dee in Continuation::handleEvent (this=0x2b15e82360a0,
event=103, data=0x2b15fc01e2e8) at ../iocore/eventsystem/I_Continuation.h:146
#22 0x0070eafa in CacheVC::calluser (this=0x2b15fc01e0a0, event=103) at
P_CacheInternal.h:642
#23 0x007174fb in CacheVC::openWriteMain (this=0x2b15fc01e0a0) at
CacheWrite.cc:1367
#24 0x004f8dee in Continuation::handleEvent (this=0x2b15fc01e0a0,
event=1, data=0x2b15e4041090) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x00760bee in EThread::process_event (this=0x2b149ef4a010,
e=0x
[jira] [Updated] (TS-4160) MLocRelease for txn buffers called too late in CPP API resulting buffer corruption
[
https://issues.apache.org/jira/browse/TS-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-4160:
--
Description:
CPP API currently acquires the buffer and heap handles for various kinds of
request/response objects (e.g cached_request_hdr_buf, cached_request_hdr_loc,
client_response_hdr_buf, client_response_hdr_loc etc) at the corresponding
hooks of a transaction, along with the url handles in the CPP API's
request/response objects, but keeps them until txn_close, before calling
MLocRelease on them finally.
However, this is buggy, since the core doesn't seem to guarantee the life of
these handles until the end of the transaction. In particular, the
cached_request_hdr_buf/loc are released at the end of
tunnel_handler_cache_read(), which causes it to be reassigned to a different
txn and results in a crash when the original txn finally tries to release them
triggering the asserts from the MLocRelease C API. Note that the C API plugins
typically call MLocRelease immediately after acquiring/using them.
Additionally, the order in which CPP API releases the handles is incorrect.
Transaction object contains the Request objects and Transaction object's
destructor first calls MLocRelease on the request heap handles, before which
the Request object's d'tor is triggered which calls the url handle in that
released request handle. This may not be a problem right now, since MLocRelease
for HTTP_OBJ and URL_OBJ are basically no-ops, but, the order of release still
breaks the implicit contract of the API, which requires the child to be
released before releasing the parent (which means, if the API's internal
implementation changes tomorrow, that can cause a problem).
Here are the back traces for the issues mentioned above:
{code}
(gdb) bt
#0 0x003c1b232625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x003c1b233e05 in abort () at abort.c:92
#2 0x2b149d517018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b149d5170e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2b149d525d78 "%s:%d: failed
assert `%s`", ap=0x2b14a4806570) at ink_error.cc:65
#4 0x2b149d5171ae in ink_fatal (return_code=1,
message_format=0x2b149d525d78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2b149d515d20 in _ink_assert (expression=0x771185 "!\"invalid mloc\"",
file=0x770f1d "InkAPI.cc", line=1886) at ink_assert.cc:37
#6 0x0050f809 in TSHandleMLocRelease (bufp=0x2b15e82357f0,
parent=0x2b15e40fca98, mloc=0x2b15e40fcd18) at InkAPI.cc:1886
#7 0x2b15759066fc in atscppapi::Request::~Request (this=0x2b15e0003318,
__in_chrg=) at Request.cc:179
#8 0x2b1575902131 in ~TransactionState (this=0x2b15e0001320,
__in_chrg=) at Transaction.cc:40
#9 atscppapi::Transaction::~Transaction (this=0x2b15e0001320, __in_chrg=) at Transaction.cc:111
#10 0x2b1575901031 in (anonymous namespace)::handleTransactionEvents
(cont=, event=, edata=0x2b15e8235460)
at utils_internal.cc:87
#11 0x0050d7f0 in INKContInternal::handle_event (this=0x20399b0,
event=60012, edata=0x2b15e8235460) at InkAPI.cc:1000
#12 0x004f8dee in Continuation::handleEvent (this=0x20399b0,
event=60012, data=0x2b15e8235460) at ../iocore/eventsystem/I_Continuation.h:146
#13 0x0050e037 in APIHook::invoke (this=0x202b170, event=60012,
edata=0x2b15e8235460) at InkAPI.cc:1219
#14 0x005cfb5d in HttpSM::state_api_callout (this=0x2b15e8235460,
event=0, data=0x0) at HttpSM.cc:1384
#15 0x005dba75 in HttpSM::do_api_callout_internal (this=0x2b15e8235460)
at HttpSM.cc:4896
#16 0x005e8b2a in HttpSM::do_api_callout (this=0x2b15e8235460) at
HttpSM.cc:437
#17 0x005e0ed0 in HttpSM::kill_this (this=0x2b15e8235460) at
HttpSM.cc:6615
#18 0x005d358f in HttpSM::main_handler (this=0x2b15e8235460,
event=2301, data=0x2b15e82360a0) at HttpSM.cc:2556
#19 0x004f8dee in Continuation::handleEvent (this=0x2b15e8235460,
event=2301, data=0x2b15e82360a0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0061cebf in HttpTunnel::main_handler (this=0x2b15e82360a0,
event=103, data=0x2b15fc01e2e8) at HttpTunnel.cc:1537
#21 0x004f8dee in Continuation::handleEvent (this=0x2b15e82360a0,
event=103, data=0x2b15fc01e2e8) at ../iocore/eventsystem/I_Continuation.h:146
#22 0x0070eafa in CacheVC::calluser (this=0x2b15fc01e0a0, event=103) at
P_CacheInternal.h:642
#23 0x007174fb in CacheVC::openWriteMain (this=0x2b15fc01e0a0) at
CacheWrite.cc:1367
#24 0x004f8dee in Continuation::handleEvent (this=0x2b15fc01e0a0,
event=1, data=0x2b15e4041090) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x00760bee in EThread::process_event (this=0x2b149ef4a010,
e=0x2b15e4041090, calling_code=1) at UnixEThread.cc:145
#26 0x00760dbc in EThread::execute (this=0x2b149
[jira] [Created] (TS-4160) MLocRelease for txn buffers called too late in CPP API resulting buffer corruption
Sudheer Vinukonda created TS-4160:
-
Summary: MLocRelease for txn buffers called too late in CPP API
resulting buffer corruption
Key: TS-4160
URL: https://issues.apache.org/jira/browse/TS-4160
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Sudheer Vinukonda
Assignee: Brian Geffon
CPP API currently acquires the buffer and heap handles for various kinds of
request/response objects (e.g cached_request_hdr_buf, cached_request_hdr_loc,
client_response_hdr_buf, client_response_hdr_loc etc) at the corresponding
hooks of a transaction, along with the url handles in the CPP API's
request/response objects, but keeps them until txn_close, before calling
MLocRelease on them finally.
However, this is buggy, since the core doesn't seem to guarantee the life of
these handles until the end of the transaction. In particular, the
cached_request_hdr_buf/loc are released at the end of
tunnel_handler_cache_read(), which causes it to be reassigned to a different
txn and results in a crash when the original txn finally tries to release them
triggering the asserts from the MLocRelease C API. Note that the C API plugins
typically call MLocRelease immediately after acquiring/using them.
Additionally, the order in which CPP API releases the handles is incorrect.
Transaction object contains the Request objects and Transaction object's
destructor first calls MLocRelease on the request heap handles, before which
the Request object's d'tor is triggered which calls the url handle in that
released request handle. This may not be a problem right now, since MLocRelease
for HTTP_OBJ and URL_OBJ are basically no-ops, but, the order of release still
breaks the implicit contract of the API, which requires the child to be
released before releasing the parent (which means, if the API's internal
implementation changes tomorrow, that can cause a problem).
Here are the back traces for the issues mentioned above:
{code}
(gdb) bt
#0 0x003c1b232625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x003c1b233e05 in abort () at abort.c:92
#2 0x2b149d517018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b149d5170e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2b149d525d78 "%s:%d: failed
assert `%s`", ap=0x2b14a4806570) at ink_error.cc:65
#4 0x2b149d5171ae in ink_fatal (return_code=1,
message_format=0x2b149d525d78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2b149d515d20 in _ink_assert (expression=0x771185 "!\"invalid mloc\"",
file=0x770f1d "InkAPI.cc", line=1886) at ink_assert.cc:37
#6 0x0050f809 in TSHandleMLocRelease (bufp=0x2b15e82357f0,
parent=0x2b15e40fca98, mloc=0x2b15e40fcd18) at InkAPI.cc:1886
#7 0x2b15759066fc in atscppapi::Request::~Request (this=0x2b15e0003318,
__in_chrg=) at Request.cc:179
#8 0x2b1575902131 in ~TransactionState (this=0x2b15e0001320,
__in_chrg=) at Transaction.cc:40
#9 atscppapi::Transaction::~Transaction (this=0x2b15e0001320, __in_chrg=) at Transaction.cc:111
#10 0x2b1575901031 in (anonymous namespace)::handleTransactionEvents
(cont=, event=, edata=0x2b15e8235460)
at utils_internal.cc:87
#11 0x0050d7f0 in INKContInternal::handle_event (this=0x20399b0,
event=60012, edata=0x2b15e8235460) at InkAPI.cc:1000
#12 0x004f8dee in Continuation::handleEvent (this=0x20399b0,
event=60012, data=0x2b15e8235460) at ../iocore/eventsystem/I_Continuation.h:146
#13 0x0050e037 in APIHook::invoke (this=0x202b170, event=60012,
edata=0x2b15e8235460) at InkAPI.cc:1219
#14 0x005cfb5d in HttpSM::state_api_callout (this=0x2b15e8235460,
event=0, data=0x0) at HttpSM.cc:1384
#15 0x005dba75 in HttpSM::do_api_callout_internal (this=0x2b15e8235460)
at HttpSM.cc:4896
#16 0x005e8b2a in HttpSM::do_api_callout (this=0x2b15e8235460) at
HttpSM.cc:437
#17 0x005e0ed0 in HttpSM::kill_this (this=0x2b15e8235460) at
HttpSM.cc:6615
#18 0x005d358f in HttpSM::main_handler (this=0x2b15e8235460,
event=2301, data=0x2b15e82360a0) at HttpSM.cc:2556
#19 0x004f8dee in Continuation::handleEvent (this=0x2b15e8235460,
event=2301, data=0x2b15e82360a0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0061cebf in HttpTunnel::main_handler (this=0x2b15e82360a0,
event=103, data=0x2b15fc01e2e8) at HttpTunnel.cc:1537
#21 0x004f8dee in Continuation::handleEvent (this=0x2b15e82360a0,
event=103, data=0x2b15fc01e2e8) at ../iocore/eventsystem/I_Continuation.h:146
#22 0x0070eafa in CacheVC::calluser (this=0x2b15fc01e0a0, event=103) at
P_CacheInternal.h:642
#23 0x007174fb in CacheVC::openWriteMain (this=0x2b15fc01e0a0) at
CacheWrite.cc:1367
#24 0x004f8dee in Continuation::handleEvent (this=0x2b15fc01e0a0,
event=1, data=0x2b15e4041
[jira] [Assigned] (TS-4160) MLocRelease for txn buffers called too late in CPP API resulting buffer corruption
[
https://issues.apache.org/jira/browse/TS-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda reassigned TS-4160:
-
Assignee: Sudheer Vinukonda (was: Brian Geffon)
> MLocRelease for txn buffers called too late in CPP API resulting buffer
> corruption
> --
>
> Key: TS-4160
> URL: https://issues.apache.org/jira/browse/TS-4160
> Project: Traffic Server
> Issue Type: Bug
> Components: CPP API
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>
> CPP API currently acquires the buffer and heap handles for various kinds of
> request/response objects (e.g cached_request_hdr_buf, cached_request_hdr_loc,
> client_response_hdr_buf, client_response_hdr_loc etc) at the corresponding
> hooks of a transaction, along with the url handles in the CPP API's
> request/response objects, but keeps them until txn_close, before calling
> MLocRelease on them finally.
> However, this is buggy, since the core doesn't seem to guarantee the life of
> these handles until the end of the transaction. In particular, the
> cached_request_hdr_buf/loc are released at the end of
> tunnel_handler_cache_read(), which causes it to be reassigned to a different
> txn and results in a crash when the original txn finally tries to release
> them triggering the asserts from the MLocRelease C API. Note that the C API
> plugins typically call MLocRelease immediately after acquiring/using them.
> Additionally, the order in which CPP API releases the handles is incorrect.
> Transaction object contains the Request objects and Transaction object's
> destructor first calls MLocRelease on the request heap handles, before which
> the Request object's d'tor is triggered which calls the url handle in that
> released request handle. This may not be a problem right now, since
> MLocRelease for HTTP_OBJ and URL_OBJ are basically no-ops, but, the order of
> release still breaks the implicit contract of the API, which requires the
> child to be released before releasing the parent (which means, if the API's
> internal implementation changes tomorrow, that can cause a problem).
> Here are the back traces for the issues mentioned above:
> {code}
> (gdb) bt
> #0 0x003c1b232625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x003c1b233e05 in abort () at abort.c:92
> #2 0x2b149d517018 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2b149d5170e5 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1, message_format=0x2b149d525d78
> "%s:%d: failed assert `%s`", ap=0x2b14a4806570) at ink_error.cc:65
> #4 0x2b149d5171ae in ink_fatal (return_code=1,
> message_format=0x2b149d525d78 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2b149d515d20 in _ink_assert (expression=0x771185 "!\"invalid
> mloc\"", file=0x770f1d "InkAPI.cc", line=1886) at ink_assert.cc:37
> #6 0x0050f809 in TSHandleMLocRelease (bufp=0x2b15e82357f0,
> parent=0x2b15e40fca98, mloc=0x2b15e40fcd18) at InkAPI.cc:1886
> #7 0x2b15759066fc in atscppapi::Request::~Request (this=0x2b15e0003318,
> __in_chrg=) at Request.cc:179
> #8 0x2b1575902131 in ~TransactionState (this=0x2b15e0001320,
> __in_chrg=) at Transaction.cc:40
> #9 atscppapi::Transaction::~Transaction (this=0x2b15e0001320,
> __in_chrg=) at Transaction.cc:111
> #10 0x2b1575901031 in (anonymous namespace)::handleTransactionEvents
> (cont=, event=,
> edata=0x2b15e8235460) at utils_internal.cc:87
> #11 0x0050d7f0 in INKContInternal::handle_event (this=0x20399b0,
> event=60012, edata=0x2b15e8235460) at InkAPI.cc:1000
> #12 0x004f8dee in Continuation::handleEvent (this=0x20399b0,
> event=60012, data=0x2b15e8235460) at
> ../iocore/eventsystem/I_Continuation.h:146
> #13 0x0050e037 in APIHook::invoke (this=0x202b170, event=60012,
> edata=0x2b15e8235460) at InkAPI.cc:1219
> #14 0x005cfb5d in HttpSM::state_api_callout (this=0x2b15e8235460,
> event=0, data=0x0) at HttpSM.cc:1384
> #15 0x005dba75 in HttpSM::do_api_callout_internal
> (this=0x2b15e8235460) at HttpSM.cc:4896
> #16 0x005e8b2a in HttpSM::do_api_callout (this=0x2b15e8235460) at
> HttpSM.cc:437
> #17 0x005e0ed0 in HttpSM::kill_this (this=0x2b15e8235460) at
> HttpSM.cc:6615
> #18 0x005d358f in HttpSM::main_handler (this=0x2b15e8235460,
> event=2301, data=0x2b15e82360a0) at HttpSM.cc:2556
> #19 0x004f8dee in Continuation::handleEvent (this=0x2b15e8235460,
> event=2301, data=0x2b15e82360a0) at ../iocore/eventsystem/I_Continuation.h:146
> #20 0x0061cebf in HttpTunnel::main_handler (this=0x2b15e82360a0,
> event=103, data=0x2b15fc01e2e8) at HttpTunnel.cc:1537
> #21 0x004f8dee in Continuation::handleEvent
[jira] [Updated] (TS-3286) Improve MIOBuffer allocation mechanism with checks to prevent corrupting the freelist
[
https://issues.apache.org/jira/browse/TS-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3286:
--
Fix Version/s: 6.2.0
> Improve MIOBuffer allocation mechanism with checks to prevent corrupting the
> freelist
> -
>
> Key: TS-3286
> URL: https://issues.apache.org/jira/browse/TS-3286
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.2.0
>
>
> This jira is a follow up on TS-3285. While investigating TS-3285, I realized
> that there are not sufficient guards in-place in the MIOBuffer
> allocation/access mechanism to prevent corrupting the free list or accessing
> the objects off of the freelist.
> These issues are particularly problematic, when creating the MIOBuffer using
> new_empty_MIOBuffer(). This simply pulls out the MIOBuffer from the freelist,
> without resetting/initializing the data members. So, if the MIOBuffer on the
> freelist is bad, then the newly allocated buffer will run into trouble (e.g
> TS-3285). Note that, if the MIOBuffer is allocated using new_MIOBuffer(), it
> calls clear() which resets the members correctly.
> The problem also is partly due to the fact that MIOBuffer uses ProxyAllocator
> and when the object is allocated from the local thread freelist, it is not
> reset with a prototype object memcpy (like the ClassAllocator would do).
> Some checks/asserts I am thinking of adding are as below:
> {code}
> diff --git a/iocore/eventsystem/IOBuffer.cc b/iocore/eventsystem/IOBuffer.cc
> index 879e8ba..d54080f 100644
> --- a/iocore/eventsystem/IOBuffer.cc
> +++ b/iocore/eventsystem/IOBuffer.cc
> @@ -82,6 +82,7 @@ MIOBuffer::remove_append(IOBufferReader * r)
> int64_t
> MIOBuffer::write(const void *abuf, int64_t alen)
> {
> + ink_release_assert(size_index < BUFFER_SIZE_NOT_ALLOCATED);
>const char *buf = (const char*)abuf;
>int64_t len = alen;
>while (len) {
> @@ -135,6 +136,7 @@
> MIOBuffer::write_and_transfer_left_over_space(IOBufferReader * r, int64_t
> alen,
> int64_t
> MIOBuffer::write(IOBufferReader * r, int64_t alen, int64_t offset)
> {
> + ink_release_assert(size_index < BUFFER_SIZE_NOT_ALLOCATED);
>int64_t len = alen;
>IOBufferBlock *b = r->block;
>offset += r->start_offset;
> diff --git a/iocore/eventsystem/I_IOBuffer.h b/iocore/eventsystem/I_IOBuffer.h
> index 0e5fe0c..d9aba81 100644
> --- a/iocore/eventsystem/I_IOBuffer.h
> +++ b/iocore/eventsystem/I_IOBuffer.h
> @@ -1126,8 +1126,6 @@ public:
> _writer->realloc_xmalloc(buf_size);
>}
>
> - int64_t size_index;
> -
>/**
> Determines when to stop writing or reading. The watermark is the
> level to which the producer (filler) is required to fill the buffer
> @@ -1138,6 +1136,8 @@ public:
>*/
>int64_t water_mark;
>
> + int64_t size_index;
> +
>Ptr _writer;
>IOBufferReader readers[MAX_MIOBUFFER_READERS];
>
> diff --git a/iocore/eventsystem/P_IOBuffer.h b/iocore/eventsystem/P_IOBuffer.h
> index 365486f..74ea432 100644
> --- a/iocore/eventsystem/P_IOBuffer.h
> +++ b/iocore/eventsystem/P_IOBuffer.h
> @@ -775,8 +775,7 @@ TS_INLINE MIOBuffer * new_MIOBuffer_internal(
> TS_INLINE void
> free_MIOBuffer(MIOBuffer * mio)
> {
> - mio->_writer = NULL;
> - mio->dealloc_all_readers();
> + clear();
>THREAD_FREE(mio, ioAllocator, this_thread());
> }
>
> @@ -893,6 +892,7 @@ MIOBuffer::append_block_internal(IOBufferBlock * b)
>// It would be nice to remove an empty buffer at the beginning,
>// but this breaks HTTP.
>// if (!_writer || !_writer->read_avail())
> + ink_release_assert(size_index < BUFFER_SIZE_NOT_ALLOCATED);
>if (!_writer) {
> _writer = b;
> init_readers();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2540) header_rewrite: Does not detect a Statement without a predicate as an error
[
https://issues.apache.org/jira/browse/TS-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2540:
--
Fix Version/s: (was: 6.1.0)
sometime
> header_rewrite: Does not detect a Statement without a predicate as an error
> ---
>
> Key: TS-2540
> URL: https://issues.apache.org/jira/browse/TS-2540
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Sudheer Vinukonda
> Fix For: sometime
>
>
> For example, this config silently fails with no errors, and worse, leaves the
> parser in a potentially erroneous state (causing subsequent rules to be
> wrong):
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> X-Some-Header "zwoop"
> {code}
> Yes, it's obviously a config error (it should have a "set-config" predicate),
> but we should detect this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3137) Enhance header_rewrite to support set-redirect operator when used in global mode
[ https://issues.apache.org/jira/browse/TS-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3137: -- Fix Version/s: (was: 6.1.0) sometime > Enhance header_rewrite to support set-redirect operator when used in global > mode > > > Key: TS-3137 > URL: https://issues.apache.org/jira/browse/TS-3137 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Affects Versions: 5.0.1 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: sometime > > Attachments: TS-3137.diff > > > We have a use case to redirect all incoming users of certain type (e.g. old > version of certain browsers) to some pre-determined site. > header_rewrite supports the set-redirect operator to achieve this, but, > currently, this only works on a remap mode. We have a very large number of > remap rules (in the order of 20K+), so, supporting set-redirect in global > mode would make it easier for operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3681) Promote TSHrtime APIs to ts.h /apidefs.h
[ https://issues.apache.org/jira/browse/TS-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3681: -- Fix Version/s: (was: 6.1.0) 7.0.0 > Promote TSHrtime APIs to ts.h /apidefs.h > > > Key: TS-3681 > URL: https://issues.apache.org/jira/browse/TS-3681 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 7.0.0 > > > Time to move these from experimental to ts/ts.h / apidefs.h -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3949) Ignore timeout event on PluginVC after it's already closed.
[
https://issues.apache.org/jira/browse/TS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3949:
--
Fix Version/s: (was: 6.1.0)
6.2.0
> Ignore timeout event on PluginVC after it's already closed.
> ---
>
> Key: TS-3949
> URL: https://issues.apache.org/jira/browse/TS-3949
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Plugins
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.2.0
>
>
> When a plugin sets TS_EVENT_VCONN_ACTIVE_TIMEOUT on Plugin VC, it looks like,
> in some race conditions, the active timer event could still get fired after
> the Plugin VC is already closed, leading *INKContInternal::handle_event* to
> assert a use-after-free.
> Note: The plugin VC's process_close does cancel the active timeout event, so,
> this doesn't happen every time. It might happen in some race conditions or
> when the timeout and close are on different threads (?)..
> Below's the fatal log and gdb info of the assert for the timeout event after
> a close.
> {code}
> Sep 26 21:54:54 my_dev_host traffic_server[20653]: FATAL: InkAPI.cc:990:
> failed assert `!"Plugin tries to use a continuation which is deleted"`
> gdb stack trace:
> Core was generated by `/home/y/bin/traffic_server -M --httpport
> 80:fd=8,443:fd=9:ssl'.
> Program terminated with signal 6, Aborted.
> #0 0x0038fb432625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) bt
> #0 0x0038fb432625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x0038fb433e05 in abort () at abort.c:92
> #2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78
> "%s:%d: failed assert `%s`", ap=0x2ad27f7159f0)
> at ink_error.cc:65
> #4 0x2ad27ce811ae in ink_fatal (return_code=1,
> message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries
> to use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc",
> line=990) at ink_assert.cc:37
> #6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
> event=106, edata=0x2ad3dad0) at InkAPI.cc:990
> #7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
> event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
> #8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
> e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at
> PluginVC.cc:762
> #9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0,
> event=2, data=0x2ad360081ef0) at PluginVC.cc:193
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
> event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
> #11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
> e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
> #12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
> UnixEThread.cc:224
> #13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
> #14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
> pthread_create.c:301
> #15 0x0038fb4e88fd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> (gdb) bt
> #0 0x0038fb432625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x0038fb433e05 in abort () at abort.c:92
> #2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78
> "%s:%d: failed assert `%s`", ap=0x2ad27f7159f0)
> at ink_error.cc:65
> #4 0x2ad27ce811ae in ink_fatal (return_code=1,
> message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries
> to use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc",
> line=990) at ink_assert.cc:37
> #6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
> event=106, edata=0x2ad3dad0) at InkAPI.cc:990
> #7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
> event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
> #8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
> e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at
> PluginVC.cc:762
> #9 0x005327b1 in PluginVC::main_han
[jira] [Updated] (TS-3685) traffic_manager can't bind to port 80 sometimes.
[
https://issues.apache.org/jira/browse/TS-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3685:
--
Fix Version/s: (was: 6.1.0)
6.2.0
> traffic_manager can't bind to port 80 sometimes.
>
>
> Key: TS-3685
> URL: https://issues.apache.org/jira/browse/TS-3685
> Project: Traffic Server
> Issue Type: Bug
> Components: Manager
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.2.0
>
>
> During new install/updates sometimes, when ATS is restarted too quickly
> multiple times, we occasionally end up with the below error, causing ATS not
> to come up:
> {code}
> [Jun 11 14:46:24.852] Manager {0x7fa0e2b217e0} NOTE:
> [LocalManager::listenForProxy] Listening on port: 80
> [Jun 11 14:46:24.852] Manager {0x7fa0e2b217e0} NOTE:
> [LocalManager::listenForProxy] Listening on port: 443
> [Jun 11 14:46:24.852] Manager {0x7fa0e2b217e0} ERROR: [bindProxyPort] Unable
> to bind socket: 80 : Address already in use
> {code}
> This is quite annoying and inconvenient since it blocks ATS from coming up
> (sometimes for very long) until a reboot or some other deep clean up is
> performed.
> Would like to add the socket option *SO_REUSEPORT* to the socket doing the
> proxy port binding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3804) ASAN heap-use-after-free in HttpClientSession::destroy
[
https://issues.apache.org/jira/browse/TS-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3804:
--
Fix Version/s: (was: 6.1.0)
6.2.0
> ASAN heap-use-after-free in HttpClientSession::destroy
> --
>
> Key: TS-3804
> URL: https://issues.apache.org/jira/browse/TS-3804
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Sudheer Vinukonda
>Priority: Blocker
> Labels: crash
> Fix For: 6.2.0
>
>
> Seeing this with current master on docs.trafficserver:
> {code}
> traffic_server: using root directory '/opt/ats'
> =
> ==20070==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x6250038c6328 at pc 0x60d722 bp 0x2af782a92940 sp 0x2af782a92938
> WRITE of size 8 at 0x6250038c6328 thread T4 ([ET_NET 3])
> #0 0x60d721 in HttpClientSession::destroy()
> /usr/local/src/trafficserver/proxy/http/HttpClientSession.cc:98
> #1 0x60c867 in HttpClientSession::state_wait_for_close(int, void*)
> /usr/local/src/trafficserver/proxy/http/HttpClientSession.cc:356
> #2 0x592027 in Continuation::handleEvent(int, void*)
> ../iocore/eventsystem/I_Continuation.h:146
> #3 0x592027 in PluginVC::process_read_side(bool)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:629
> #4 0x59eb99 in PluginVC::main_handler(int, void*)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:204
> #5 0xc3357e in Continuation::handleEvent(int, void*)
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #6 0xc3357e in EThread::process_event(Event*, int)
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #7 0xc35259 in EThread::execute()
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:179
> #8 0xc32188 in spawn_thread_internal
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2af77b75cdf4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> #10 0x2af77cfc51ac in __clone (/lib64/libc.so.6+0xf61ac)
> 0x6250038c6328 is located 6696 bytes inside of 8032-byte region
> [0x6250038c4900,0x6250038c6860)
> freed by thread T4 ([ET_NET 3]) here:
> #0 0x2af77935b1c7 in __interceptor_free
> ../../.././libsanitizer/asan/asan_malloc_linux.cc:62
> #1 0x67cab5 in ClassAllocator::free(HttpSM*)
> ../../lib/ts/Allocator.h:134
> #2 0x67cab5 in HttpSM::destroy()
> /usr/local/src/trafficserver/proxy/http/HttpSM.cc:316
> #3 0x67cab5 in HttpSM::kill_this()
> /usr/local/src/trafficserver/proxy/http/HttpSM.cc:6647
> #4 0x67f7d7 in HttpSM::main_handler(int, void*)
> /usr/local/src/trafficserver/proxy/http/HttpSM.cc:2558
> #5 0x74711d in Continuation::handleEvent(int, void*)
> ../../iocore/eventsystem/I_Continuation.h:146
> #6 0x74711d in HttpTunnel::main_handler(int, void*)
> /usr/local/src/trafficserver/proxy/http/HttpTunnel.cc:1585
> #7 0x594051 in Continuation::handleEvent(int, void*)
> ../iocore/eventsystem/I_Continuation.h:146
> #8 0x594051 in PluginVC::process_write_side(bool)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:545
> #9 0x59e324 in PluginVC::main_handler(int, void*)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:208
> #10 0xc3357e in Continuation::handleEvent(int, void*)
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #11 0xc3357e in EThread::process_event(Event*, int)
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #12 0xc35259 in EThread::execute()
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:179
> #13 0xc32188 in spawn_thread_internal
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #14 0x2af77b75cdf4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> previously allocated by thread T4 ([ET_NET 3]) here:
> #0 0x2af77935b93b in __interceptor_posix_memalign
> ../../.././libsanitizer/asan/asan_malloc_linux.cc:130
> #1 0x2af77a244849 in ats_memalign
> /usr/local/src/trafficserver/lib/ts/ink_memory.cc:100
> #2 0x2af77a2451b0 in ink_freelist_new
> /usr/local/src/trafficserver/lib/ts/ink_queue.cc:239
> #3 0x6129a5 in ClassAllocator::alloc()
> ../../lib/ts/Allocator.h:120
> #4 0x6129a5 in HttpSM::allocate()
> /usr/local/src/trafficserver/proxy/http/HttpSM.h:566
> #5 0x6129a5 in HttpClientSession::new_transaction()
> /usr/local/src/trafficserver/proxy/http/HttpClientSession.cc:141
> #6 0x6129a5 in HttpClientSession::start()
> /usr/local/src/trafficserver/proxy/http/HttpClientSession.h:63
> #7 0x60dff0 in HttpClientSession::new_connection(NetVConnection*,
> MIOBuffer*, IOBufferReader*, bool)
> /usr/local/src/trafficserver/proxy/http/HttpClientSession.cc:2
[jira] [Updated] (TS-3663) Enhance redirect follow to allow storing intermediate redirect responses
[
https://issues.apache.org/jira/browse/TS-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3663:
--
Fix Version/s: (was: 6.1.0)
sometime
> Enhance redirect follow to allow storing intermediate redirect responses
>
>
> Key: TS-3663
> URL: https://issues.apache.org/jira/browse/TS-3663
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: sometime
>
> Attachments: TS-3663.diff
>
>
> This is a follow up jira to TS-3661 and TS-3652.
> Basically, TS stores the final (2xx or any other status that is cacheable)
> response after all the redirect follow attempts against the original cache
> key (i.e remapped url from the client url or a modified cache key via API).
> All the intermediate 3xx responses are never stored in the cache. There's a
> lot of confusing/misleading code that tries to build a new cache key with the
> Location header and tries to read/write the 3xx responses. All these
> read/writes fail, since, the cache_sm for the original key (remapped client
> request url or modified API key) still is open.
> Below are some snippets of code that are related:
> https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L4450
> https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L4350
> {code}
> if (t_state.redirect_info.redirect_in_process) {
> o_url = &(t_state.redirect_info.original_url);
> ink_assert(o_url->valid());
> restore_client_request = true;
> s_url = o_url;
> } else {
> //..
> {code}
> {code}
>if (t_state.redirect_info.redirect_in_process)
> c_url = t_state.hdr_info.client_request.url_get();
> else
> //
> {code}
> After discussing further with [~bcall] and [~zwoop], we think that this could
> be made as an improvement to the current redirect follow behavior. Basically,
> extend the setting *proxy.config.http.redirection_enabled* to support a new
> option that stores intermediate redirect responses against a cache key that
> is set as the *Location* followed.
> Further to simply configuration (and to avoid confusion via multiple ways of
> doing the same thing), the setting *proxy.config.http.redirection_enabled*
> will be made overridable while deprecating the existing TS API
> *TSHttpTxnFollowRedirect*, since the config setting is sufficient to achieve
> the same behavior. This should be done regardless of this new feature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3133) Logging NOTE filling up diags.log
[
https://issues.apache.org/jira/browse/TS-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3133:
--
Fix Version/s: (was: 6.1.0)
6.2.0
> Logging NOTE filling up diags.log
> -
>
> Key: TS-3133
> URL: https://issues.apache.org/jira/browse/TS-3133
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.2.0
>
>
> In our production systems, we have proxy.config.log.log_buffer_size set to
> the default value of 9216. However, we do see some very large URLs resulting
> in larger log entries (about 26k bytes long). This basically results in the
> warnings like the below from ATS (going into diags.log). This is good, but,
> the problem is that, these WARNING messages alone fill up/flood the diags.log
> pretty fast (which itself is not rotated right now - refer TS-306). The
> correct solution to this is to increase the log buffers, which we are
> implementing, but, it might be nice to not flood the diags.log with the below
> WARNINGs as that might result in losing/missing out on other
> critical/important WARNINGs. We are thinking of implementing some sort of
> throttling on these kind of WARNINGs (for e.g. 1 in every 1000 entries along
> with a count of how many times the log was not displayed).
> Please provide comments/suggestions.
> {code}
> [Oct 10 18:04:13.300] Server {0x2ad39283f700} NOTE: Skipping the current log
> entry for squid.blog because its size (11000) exceeds the maximum payload
> space
> in a log buffer
> [Oct 10 19:13:53.190] Server {0x2b1ccec45700} NOTE: Traffic Server is skipping
> the current log entry because its size exceeds the maximum line (entry) size
> for an ascii log buffer
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3286) Improve MIOBuffer allocation mechanism with checks to prevent corrupting the freelist
[
https://issues.apache.org/jira/browse/TS-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3286:
--
Fix Version/s: (was: 6.1.0)
6.2.0
> Improve MIOBuffer allocation mechanism with checks to prevent corrupting the
> freelist
> -
>
> Key: TS-3286
> URL: https://issues.apache.org/jira/browse/TS-3286
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.2.0
>
>
> This jira is a follow up on TS-3285. While investigating TS-3285, I realized
> that there are not sufficient guards in-place in the MIOBuffer
> allocation/access mechanism to prevent corrupting the free list or accessing
> the objects off of the freelist.
> These issues are particularly problematic, when creating the MIOBuffer using
> new_empty_MIOBuffer(). This simply pulls out the MIOBuffer from the freelist,
> without resetting/initializing the data members. So, if the MIOBuffer on the
> freelist is bad, then the newly allocated buffer will run into trouble (e.g
> TS-3285). Note that, if the MIOBuffer is allocated using new_MIOBuffer(), it
> calls clear() which resets the members correctly.
> The problem also is partly due to the fact that MIOBuffer uses ProxyAllocator
> and when the object is allocated from the local thread freelist, it is not
> reset with a prototype object memcpy (like the ClassAllocator would do).
> Some checks/asserts I am thinking of adding are as below:
> {code}
> diff --git a/iocore/eventsystem/IOBuffer.cc b/iocore/eventsystem/IOBuffer.cc
> index 879e8ba..d54080f 100644
> --- a/iocore/eventsystem/IOBuffer.cc
> +++ b/iocore/eventsystem/IOBuffer.cc
> @@ -82,6 +82,7 @@ MIOBuffer::remove_append(IOBufferReader * r)
> int64_t
> MIOBuffer::write(const void *abuf, int64_t alen)
> {
> + ink_release_assert(size_index < BUFFER_SIZE_NOT_ALLOCATED);
>const char *buf = (const char*)abuf;
>int64_t len = alen;
>while (len) {
> @@ -135,6 +136,7 @@
> MIOBuffer::write_and_transfer_left_over_space(IOBufferReader * r, int64_t
> alen,
> int64_t
> MIOBuffer::write(IOBufferReader * r, int64_t alen, int64_t offset)
> {
> + ink_release_assert(size_index < BUFFER_SIZE_NOT_ALLOCATED);
>int64_t len = alen;
>IOBufferBlock *b = r->block;
>offset += r->start_offset;
> diff --git a/iocore/eventsystem/I_IOBuffer.h b/iocore/eventsystem/I_IOBuffer.h
> index 0e5fe0c..d9aba81 100644
> --- a/iocore/eventsystem/I_IOBuffer.h
> +++ b/iocore/eventsystem/I_IOBuffer.h
> @@ -1126,8 +1126,6 @@ public:
> _writer->realloc_xmalloc(buf_size);
>}
>
> - int64_t size_index;
> -
>/**
> Determines when to stop writing or reading. The watermark is the
> level to which the producer (filler) is required to fill the buffer
> @@ -1138,6 +1136,8 @@ public:
>*/
>int64_t water_mark;
>
> + int64_t size_index;
> +
>Ptr _writer;
>IOBufferReader readers[MAX_MIOBUFFER_READERS];
>
> diff --git a/iocore/eventsystem/P_IOBuffer.h b/iocore/eventsystem/P_IOBuffer.h
> index 365486f..74ea432 100644
> --- a/iocore/eventsystem/P_IOBuffer.h
> +++ b/iocore/eventsystem/P_IOBuffer.h
> @@ -775,8 +775,7 @@ TS_INLINE MIOBuffer * new_MIOBuffer_internal(
> TS_INLINE void
> free_MIOBuffer(MIOBuffer * mio)
> {
> - mio->_writer = NULL;
> - mio->dealloc_all_readers();
> + clear();
>THREAD_FREE(mio, ioAllocator, this_thread());
> }
>
> @@ -893,6 +892,7 @@ MIOBuffer::append_block_internal(IOBufferBlock * b)
>// It would be nice to remove an empty buffer at the beginning,
>// but this breaks HTTP.
>// if (!_writer || !_writer->read_avail())
> + ink_release_assert(size_index < BUFFER_SIZE_NOT_ALLOCATED);
>if (!_writer) {
> _writer = b;
> init_readers();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3927) Open Write retries not working and make the setting overridable.
[ https://issues.apache.org/jira/browse/TS-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-3927. --- Resolution: Fixed > Open Write retries not working and make the setting overridable. > > > Key: TS-3927 > URL: https://issues.apache.org/jira/browse/TS-3927 > Project: Traffic Server > Issue Type: Bug > Components: Cache, HTTP >Affects Versions: 6.1.0 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > The setting *proxy.config.http.cache.max_open_write_retries* is expected to > retry a cache open write upon the configured number of times, upon a open > write failure. However, the setting doesn't work currently. Opening this jira > to fix the setting and to make the setting overridable as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3881) new TS API TSHttpTxnInfoIntGet.
[
https://issues.apache.org/jira/browse/TS-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda resolved TS-3881.
---
Resolution: Fixed
> new TS API TSHttpTxnInfoIntGet.
> ---
>
> Key: TS-3881
> URL: https://issues.apache.org/jira/browse/TS-3881
> Project: Traffic Server
> Issue Type: New Feature
> Components: TS API
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.1.0
>
>
> I started off trying to write a TSHttpTxnCacheStateGet API to return cache
> lookup specific details, but, based on feed back on the IRC and dev@,
> changing the API to a more generic interface TSHttpTxnInfoIntGet to return
> any arbitrary info. The idea is to be able to use this API in the long term
> to support any arbitrary information related to a Txn (which can be used as
> the underlying piece for a framework to return txn info using custom log
> tags).
> Below's the proposal with the info I'd like the new API return along with the
> API signature.
> Please provide comments/suggestions.
> {code}
> +typedef enum {
> + TS_TXN_INFO_CACHE_HIT_RAM,
> + TS_TXN_INFO_COMPRESSED_IN_RAM,
> + TS_TXN_INFO_CACHE_HIT_RWW, // READ_WHILE_WRITE
> + TS_TXN_INFO_CACHE_OPEN_READ_TRIES,
> + TS_TXN_INFO_CACHE_OPEN_WRITE_TRIES,
> + TS_TXN_INFO_CACHE_VOLUME,
> + TS_TXN_INFO_LAST_ENTRY
> +} TSHttpTxnInfoKey;
> +
> +/* Get Arbitrary Txn info such as cache lookup details etc as defined in
> TSHttpTxnInfoKey */
> +/**
> + Return the particular txn info requested.
> +
> + @param txnp the transaction pointer
> + @param key the requested txn info.
> + @param TSMgmtInt a pointer to a integer where the return value is stored
> +
> + @return @c TS_SUCCESS if the requested info is supported, TS_ERROR
> otherwise
> +
> +*/
> +tsapi TSReturnCode TSHttpTxnInfoIntGet(TSHttpTxn txnp, TSHttpTxnInfoKey key,
> TSMgmtInt *value);
> +
> {code}
> +
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3587) Support stale-while-revalidate in the core
[ https://issues.apache.org/jira/browse/TS-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3587: -- Description: Refer TS-3549 and https://cwiki.apache.org/confluence/display/TS/Stale-While-Revalidate+in+the+core for details. https://cwiki.apache.org/confluence/display/TS/Presentations+-+2015?preview=/56066455/61328981/Stale%20While%20Revalidate%20(Open%20Write%20Fail)%20Copy.pptx.pdf#Presentations-2015-2015FallSummit was:Refer TS-3549 and https://cwiki.apache.org/confluence/display/TS/Stale-While-Revalidate+in+the+core for details. > Support stale-while-revalidate in the core > -- > > Key: TS-3587 > URL: https://issues.apache.org/jira/browse/TS-3587 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Reporter: Sudheer Vinukonda > Fix For: sometime > > > Refer TS-3549 and > https://cwiki.apache.org/confluence/display/TS/Stale-While-Revalidate+in+the+core > for details. > https://cwiki.apache.org/confluence/display/TS/Presentations+-+2015?preview=/56066455/61328981/Stale%20While%20Revalidate%20(Open%20Write%20Fail)%20Copy.pptx.pdf#Presentations-2015-2015FallSummit -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3994) Internal Redirect follow should allow to use API set cache key.
[ https://issues.apache.org/jira/browse/TS-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000743#comment-15000743 ] Sudheer Vinukonda commented on TS-3994: --- Yes :) > Internal Redirect follow should allow to use API set cache key. > --- > > Key: TS-3994 > URL: https://issues.apache.org/jira/browse/TS-3994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > Currently, during redirect follow, uses the Location header in the 3xx > response as the cache key (and does not use the cache key set by using an > API, for example). > This can break the ability to serve cached response in some cases, where the > redirect follow is performed (via a plugin to implement a simple fail-over > mechanism between origin hosts, for example). > Opening this jira to add a new configuration option to allow using original > request cache key to lookup during redirect follow. > This was briefly discussed in TS-3652, but, TS-3652 was actually tracking a > different problem (turned out to be a regression) that prevents a redirect > response being cached altogether. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3994) Internal Redirect follow should allow to use API set cache key.
[ https://issues.apache.org/jira/browse/TS-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-3994. --- Resolution: Fixed > Internal Redirect follow should allow to use API set cache key. > --- > > Key: TS-3994 > URL: https://issues.apache.org/jira/browse/TS-3994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > Currently, during redirect follow, uses the Location header in the 3xx > response as the cache key (and does not use the cache key set by using an > API, for example). > This can break the ability to serve cached response in some cases, where the > redirect follow is performed (via a plugin to implement a simple fail-over > mechanism between origin hosts, for example). > Opening this jira to add a new configuration option to allow using original > request cache key to lookup during redirect follow. > This was briefly discussed in TS-3652, but, TS-3652 was actually tracking a > different problem (turned out to be a regression) that prevents a redirect > response being cached altogether. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4016) Add the ability to skip the remap phase of the SM
[ https://issues.apache.org/jira/browse/TS-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000551#comment-15000551 ] Sudheer Vinukonda commented on TS-4016: --- lgtm (will merge if [~briang] okay's it). > Add the ability to skip the remap phase of the SM > - > > Key: TS-4016 > URL: https://issues.apache.org/jira/browse/TS-4016 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Sudheer Vinukonda > Attachments: ts-4016.diff > > > Adding a method to the Transaction class to skip the remap phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4016) Add the ability to skip the remap phase of the SM
[ https://issues.apache.org/jira/browse/TS-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-4016: - Assignee: Sudheer Vinukonda (was: Brian Geffon) > Add the ability to skip the remap phase of the SM > - > > Key: TS-4016 > URL: https://issues.apache.org/jira/browse/TS-4016 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Sudheer Vinukonda > Attachments: ts-4016.diff > > > Adding a method to the Transaction class to skip the remap phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4015) Add a transaction method to set the HTTP return status
[ https://issues.apache.org/jira/browse/TS-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-4015: - Assignee: Sudheer Vinukonda (was: Brian Geffon) > Add a transaction method to set the HTTP return status > -- > > Key: TS-4015 > URL: https://issues.apache.org/jira/browse/TS-4015 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Sudheer Vinukonda > Attachments: patch-4015.diff > > > The Transaction class should have a method that allows setting the HTTP > return status without requiring a Response object. Primarily needed for > setting error responses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4015) Add a transaction method to set the HTTP return status
[ https://issues.apache.org/jira/browse/TS-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000504#comment-15000504 ] Sudheer Vinukonda commented on TS-4015: --- lgtm - if [~briang] also +1's, I can merge it. > Add a transaction method to set the HTTP return status > -- > > Key: TS-4015 > URL: https://issues.apache.org/jira/browse/TS-4015 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Attachments: patch-4015.diff > > > The Transaction class should have a method that allows setting the HTTP > return status without requiring a Response object. Primarily needed for > setting error responses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4010) Add cached request/response to the CPP API transaction object
[ https://issues.apache.org/jira/browse/TS-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000492#comment-15000492 ] Sudheer Vinukonda commented on TS-4010: --- Thanks, [~briang] - Yes, this is all [~boazr]'s work :) > Add cached request/response to the CPP API transaction object > - > > Key: TS-4010 > URL: https://issues.apache.org/jira/browse/TS-4010 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Fix For: 6.1.0 > > Attachments: ts-4010.diff > > > The transaction object should contain handles to the cached request and > response. > The cached request/response objects should be initialized after > TS_EVENT_HTTP_READ_CACHE_HDR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4010) Add cached request/response to the CPP API transaction object
[ https://issues.apache.org/jira/browse/TS-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14999162#comment-14999162 ] Sudheer Vinukonda commented on TS-4010: --- [~briang]: Can you please review and merge this patch? > Add cached request/response to the CPP API transaction object > - > > Key: TS-4010 > URL: https://issues.apache.org/jira/browse/TS-4010 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Fix For: 6.1.0 > > Attachments: ts-4010.diff > > > The transaction object should contain handles to the cached request and > response. > The cached request/response objects should be initialized after > TS_EVENT_HTTP_READ_CACHE_HDR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3994) Internal Redirect follow should allow to use API set cache key.
[ https://issues.apache.org/jira/browse/TS-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14995737#comment-14995737 ] Sudheer Vinukonda commented on TS-3994: --- Note that as explained in https://issues.apache.org/jira/browse/TS-3652?focusedCommentId=14571649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14571649, the cache open write actions during a redirect follow are no-ops, since the cache_sm is still open on the original request's cache key. The change, however, is needed in a lookup, since this will allow concurrent requests for the same file to benefit/trigger RWW etc. > Internal Redirect follow should allow to use API set cache key. > --- > > Key: TS-3994 > URL: https://issues.apache.org/jira/browse/TS-3994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > > Currently, during redirect follow, uses the Location header in the 3xx > response as the cache key (and does not use the cache key set by using an > API, for example). > This can break the ability to serve cached response in some cases, where the > redirect follow is performed (via a plugin to implement a simple fail-over > mechanism between origin hosts, for example). > Opening this jira to add a new configuration option to allow using original > request cache key to lookup during redirect follow. > This was briefly discussed in TS-3652, but, TS-3652 was actually tracking a > different problem (turned out to be a regression) that prevents a redirect > response being cached altogether. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3994) Internal Redirect follow should allow to use API set cache key.
[ https://issues.apache.org/jira/browse/TS-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3994: -- Description: Currently, during redirect follow, uses the Location header in the 3xx response as the cache key (and does not use the cache key set by using an API, for example). This can break the ability to serve cached response in some cases, where the redirect follow is performed (via a plugin to implement a simple fail-over mechanism between origin hosts, for example). Opening this jira to add a new configuration option to allow using original request cache key to lookup during redirect follow. This was briefly discussed in TS-3652, but, TS-3652 was actually tracking a different problem (turned out to be a regression) that prevents a redirect response being cached altogether. was: Currently, during redirect follow, the cache key set by using an API for example. This breaks the ability to serve cached response in some cases, where the redirect follow is performed via a plugin. Opening this jira to add a new configuration option to allow using original request cache key to lookup during redirect follow. > Internal Redirect follow should allow to use API set cache key. > --- > > Key: TS-3994 > URL: https://issues.apache.org/jira/browse/TS-3994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > > Currently, during redirect follow, uses the Location header in the 3xx > response as the cache key (and does not use the cache key set by using an > API, for example). > This can break the ability to serve cached response in some cases, where the > redirect follow is performed (via a plugin to implement a simple fail-over > mechanism between origin hosts, for example). > Opening this jira to add a new configuration option to allow using original > request cache key to lookup during redirect follow. > This was briefly discussed in TS-3652, but, TS-3652 was actually tracking a > different problem (turned out to be a regression) that prevents a redirect > response being cached altogether. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3994) Internal Redirect follow should allow to use API set cache key.
[ https://issues.apache.org/jira/browse/TS-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-3994: - Assignee: Sudheer Vinukonda > Internal Redirect follow should allow to use API set cache key. > --- > > Key: TS-3994 > URL: https://issues.apache.org/jira/browse/TS-3994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > > Currently, during redirect follow, the cache key set by using an API for > example. This breaks the ability to serve cached response in some cases, > where the redirect follow is performed via a plugin. > Opening this jira to add a new configuration option to allow using original > request cache key to lookup during redirect follow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3994) Internal Redirect follow should allow to use API set cache key.
Sudheer Vinukonda created TS-3994: - Summary: Internal Redirect follow should allow to use API set cache key. Key: TS-3994 URL: https://issues.apache.org/jira/browse/TS-3994 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Sudheer Vinukonda Currently, during redirect follow, the cache key set by using an API for example. This breaks the ability to serve cached response in some cases, where the redirect follow is performed via a plugin. Opening this jira to add a new configuration option to allow using original request cache key to lookup during redirect follow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3979) Deprecate allow empty doc cache setting.
[
https://issues.apache.org/jira/browse/TS-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3979:
--
Fix Version/s: (was: 7.0.0)
6.1.0
> Deprecate allow empty doc cache setting.
>
>
> Key: TS-3979
> URL: https://issues.apache.org/jira/browse/TS-3979
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 6.0.0
>Reporter: Sudheer Vinukonda
> Fix For: 6.1.0
>
>
> Refer TS-3978, TS-621
> Following a discussion on the IRC, opening this jira to deprecate the Allow
> empty doc cache setting. The consensus is to cache anything that's cacheable
> and valid (regardless, of if it's empty or non-empty) - Just to clarify, it
> is not clear there's a way to ensure that it's safe to cache anything right
> now. TS-621 tried to cache empty docs in the past but ran into many
> difficulties, so, opening TS-3980 to investigate how Http layer (or other
> higher layers) may safely indicate the CacheVC that it's safe to cache.
> {code}
> Amaryllis
> 7:50
> sudheerv: do any other reverse proxies refuse to cache empty documents
> without content-length? it's not something i've noticed before (in varnish,
> for example)
> Amaryllis
> 7:50
> the connection could still be broken at any point in the response and result
> in broken content being cached
> 7:51
> but as a compromise, what if there was another option to only cache empty
> responses for 3xx, which is probably 80% of use cases?
> 7:52
> (maybe, in addition, it should accept transfer-encoding: chunked, since that
> can indicate end-of-body)
> zwoop_
> 7:54
> Amaryllis we should talk to amc (he knows everything, we don't need Google
> here) about this
> 7:54
> zwoop_ is now known as woop
> 7:54
> woop is now known as zwoop
> 7:54
> zwoop left the room (quit: Changing host).
> 7:54
> zwoop [~zwoop@apache/committer/zwoop] entered the room.
> 7:54
> mode (+o zwoop) by ChanServ
> zwoop
> 7:55
> Amaryllis amc Maybe we could have a plugin API, that basically forces to set
> f.allow_empty_doc ?
> amc
> 7:55
> I think you can change the CacheVC structure without problem.
> Amaryllis
> 7:55
> i think some sort of fix for this should be in core, at the moment TS won't
> cache any of our redirects
> amc
> 7:56
> There's not a global config to allow that?
> zwoop
> 7:56
> Amaryllis does it send a Cache-Control header with the redirects ?
> Amaryllis
> 7:56
> amc, zwoop: the origin sends transfer-encoding: chunked instead of
> content-length.
> 7:56
> so even with cache-control it won't be cached, that's what this PR is to
> change
> 7:56
> TS-3978
> ASFBot
> 7:56
> TS-3978: Allow empty document caching to follow normal logic -
> https://issues.apache.org/jira/browse/TS-3978
> zwoop
> 7:56
> ah
> 7:57
> yeah, that's expected
> 7:57
> and is why we added that option to allow empty docs to be cached
> Amaryllis
> 7:57
> this is with that option enabled
> zwoop
> 7:57
> huh
> Amaryllis
> 7:57
> it still won't cache any document without content-length
> zwoop
> 7:57
> yeah, need CL: too
> 7:57
> that's a requirement
> Amaryllis
> 7:57
> so i'll update the PR to also recognise chunked responses as being cacheable
> even if empty
> zwoop
> 7:57
> otherwise, it can't distinguish the cases you were worried about (a broken
> connection) vs a truly empty doc
> Amaryllis
> 7:58
> zwoop: right, but the PR makes it optional, only if allow_empty_doc=2
> zwoop
> 7:58
> heh, your redirect is Chunked ??
> Amaryllis
> 7:58
> yes, an empty chunked response
> zwoop
> 7:58
> is that even correct?
> Amaryllis
> 7:58
> it's perfectly valid, if somewhat unusual
> zwoop
> 7:58
> doesn't the chunking require the final "0" ?
> 7:58
> which means, the doc isn't empty
> Amaryllis
> 7:58
> i think ATS is looking at 'empty' after de-chucking, isn't it?
> 7:59
> because it's definitely not cacheing these responses
> zwoop
> 7:59
> not sure
> 7:59
> gancho_ left the room (quit: Ping timeout: 272 seconds).
> amc
> 7:59
> I think Amaryllis is correct.
> zwoop
> 7:59
> Amaryllis but, I definitely remember that the CL: header was a requirement
> that can not be ignored (safely), so not sure I think having an
> allow_empty_doc=2 is ok
> 8:00
> unless allow_empty_doc=2 also means allow Chunked content to be empty
> amc
> 8:00
> I need to check to see what ATS actually caches - the chunked data or the
> payload.
> zwoop
> 8:00
> but, you have to have some indicator telling us that the doc really is empty
> before we can cache it
> 8:00
> amc is caches the unchunked data
> 8:00
> it dechunks it, and caches that
> 8:01
> is dechunk even a proper verb?
> amc
> 8:01
> Ah, but it caches the encoding header.
> Amaryllis
> 8:01
> zwoop: https://dpaste.de/6kUT
> zwoop
> 8:01
> amc Hmmm, really ? That doesn't sound right
> amc
> 8:0
[jira] [Updated] (TS-3980) Investigate and remove the empty doc cache setting.
[ https://issues.apache.org/jira/browse/TS-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3980: -- Summary: Investigate and remove the empty doc cache setting. (was: Improve empty doc caching.) > Investigate and remove the empty doc cache setting. > --- > > Key: TS-3980 > URL: https://issues.apache.org/jira/browse/TS-3980 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Sudheer Vinukonda > Fix For: sometime > > > Refer TS-3978, TS-3979 > Caching of empty docs is slightly trickier on ATS, since, it is not clear > whether the empty body is a real empty response from the Origin server or a > consequence of broken response (connection). Currently, this is controlled > via a config setting allow_empty_doc with additional logic such as > Content-Length=0 to make sure it's a valid empty response from Origin server. > The current logic however misses handling valid empty response with no > Content-Length=0 header (e.g Chunked TE, SPDY/H2 outbound etc). > Opening jira to investigate how to *safely* (i.e ensuring the response is not > a result of broken connection) remove the allow_empty_doc setting and to be > able to generically cache empty docs similar to any other response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3979) Deprecate allow empty doc cache setting.
[
https://issues.apache.org/jira/browse/TS-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3979:
--
Summary: Deprecate allow empty doc cache setting. (was: Remove allow empty
doc cache setting.)
> Deprecate allow empty doc cache setting.
>
>
> Key: TS-3979
> URL: https://issues.apache.org/jira/browse/TS-3979
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 6.0.0
>Reporter: Sudheer Vinukonda
> Fix For: 7.0.0
>
>
> Refer TS-3978, TS-621
> Following a discussion on the IRC, opening this jira to deprecate the Allow
> empty doc cache setting. The consensus is to cache anything that's cacheable
> and valid (regardless, of if it's empty or non-empty) - Just to clarify, it
> is not clear there's a way to ensure that it's safe to cache anything right
> now. TS-621 tried to cache empty docs in the past but ran into many
> difficulties, so, opening TS-3980 to investigate how Http layer (or other
> higher layers) may safely indicate the CacheVC that it's safe to cache.
> {code}
> Amaryllis
> 7:50
> sudheerv: do any other reverse proxies refuse to cache empty documents
> without content-length? it's not something i've noticed before (in varnish,
> for example)
> Amaryllis
> 7:50
> the connection could still be broken at any point in the response and result
> in broken content being cached
> 7:51
> but as a compromise, what if there was another option to only cache empty
> responses for 3xx, which is probably 80% of use cases?
> 7:52
> (maybe, in addition, it should accept transfer-encoding: chunked, since that
> can indicate end-of-body)
> zwoop_
> 7:54
> Amaryllis we should talk to amc (he knows everything, we don't need Google
> here) about this
> 7:54
> zwoop_ is now known as woop
> 7:54
> woop is now known as zwoop
> 7:54
> zwoop left the room (quit: Changing host).
> 7:54
> zwoop [~zwoop@apache/committer/zwoop] entered the room.
> 7:54
> mode (+o zwoop) by ChanServ
> zwoop
> 7:55
> Amaryllis amc Maybe we could have a plugin API, that basically forces to set
> f.allow_empty_doc ?
> amc
> 7:55
> I think you can change the CacheVC structure without problem.
> Amaryllis
> 7:55
> i think some sort of fix for this should be in core, at the moment TS won't
> cache any of our redirects
> amc
> 7:56
> There's not a global config to allow that?
> zwoop
> 7:56
> Amaryllis does it send a Cache-Control header with the redirects ?
> Amaryllis
> 7:56
> amc, zwoop: the origin sends transfer-encoding: chunked instead of
> content-length.
> 7:56
> so even with cache-control it won't be cached, that's what this PR is to
> change
> 7:56
> TS-3978
> ASFBot
> 7:56
> TS-3978: Allow empty document caching to follow normal logic -
> https://issues.apache.org/jira/browse/TS-3978
> zwoop
> 7:56
> ah
> 7:57
> yeah, that's expected
> 7:57
> and is why we added that option to allow empty docs to be cached
> Amaryllis
> 7:57
> this is with that option enabled
> zwoop
> 7:57
> huh
> Amaryllis
> 7:57
> it still won't cache any document without content-length
> zwoop
> 7:57
> yeah, need CL: too
> 7:57
> that's a requirement
> Amaryllis
> 7:57
> so i'll update the PR to also recognise chunked responses as being cacheable
> even if empty
> zwoop
> 7:57
> otherwise, it can't distinguish the cases you were worried about (a broken
> connection) vs a truly empty doc
> Amaryllis
> 7:58
> zwoop: right, but the PR makes it optional, only if allow_empty_doc=2
> zwoop
> 7:58
> heh, your redirect is Chunked ??
> Amaryllis
> 7:58
> yes, an empty chunked response
> zwoop
> 7:58
> is that even correct?
> Amaryllis
> 7:58
> it's perfectly valid, if somewhat unusual
> zwoop
> 7:58
> doesn't the chunking require the final "0" ?
> 7:58
> which means, the doc isn't empty
> Amaryllis
> 7:58
> i think ATS is looking at 'empty' after de-chucking, isn't it?
> 7:59
> because it's definitely not cacheing these responses
> zwoop
> 7:59
> not sure
> 7:59
> gancho_ left the room (quit: Ping timeout: 272 seconds).
> amc
> 7:59
> I think Amaryllis is correct.
> zwoop
> 7:59
> Amaryllis but, I definitely remember that the CL: header was a requirement
> that can not be ignored (safely), so not sure I think having an
> allow_empty_doc=2 is ok
> 8:00
> unless allow_empty_doc=2 also means allow Chunked content to be empty
> amc
> 8:00
> I need to check to see what ATS actually caches - the chunked data or the
> payload.
> zwoop
> 8:00
> but, you have to have some indicator telling us that the doc really is empty
> before we can cache it
> 8:00
> amc is caches the unchunked data
> 8:00
> it dechunks it, and caches that
> 8:01
> is dechunk even a proper verb?
> amc
> 8:01
> Ah, but it caches the encoding header.
> Amaryllis
> 8:01
> zwoop: https://dpaste.de/6kUT
> zwoop
> 8:01
> amc Hmmm, reall
[jira] [Updated] (TS-3980) Improve empty doc caching.
[ https://issues.apache.org/jira/browse/TS-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3980: -- Description: Refer TS-3978, TS-3979 Caching of empty docs is slightly trickier on ATS, since, it is not clear whether the empty body is a real empty response from the Origin server or a consequence of broken response (connection). Currently, this is controlled via a config setting allow_empty_doc with additional logic such as Content-Length=0 to make sure it's a valid empty response from Origin server. The current logic however misses handling valid empty response with no Content-Length=0 header (e.g Chunked TE, SPDY/H2 outbound etc). Opening jira to investigate how to *safely* (i.e ensuring the response is not a result of broken connection) remove the allow_empty_doc setting and to be able to generically cache empty docs similar to any other response. was: Refer TS-3978, TS-3979 Instead of using special config settings (e.g allow_empty_doc) to control caching of empty docs, the consensus is to always cache any doc that is cacheable and safe to cache (meaning, unbroken response, including Content-Length(0), Chunked Encoding (0), SPDY/H2(0) etc). > Improve empty doc caching. > -- > > Key: TS-3980 > URL: https://issues.apache.org/jira/browse/TS-3980 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Sudheer Vinukonda > Fix For: sometime > > > Refer TS-3978, TS-3979 > Caching of empty docs is slightly trickier on ATS, since, it is not clear > whether the empty body is a real empty response from the Origin server or a > consequence of broken response (connection). Currently, this is controlled > via a config setting allow_empty_doc with additional logic such as > Content-Length=0 to make sure it's a valid empty response from Origin server. > The current logic however misses handling valid empty response with no > Content-Length=0 header (e.g Chunked TE, SPDY/H2 outbound etc). > Opening jira to investigate how to *safely* (i.e ensuring the response is not > a result of broken connection) remove the allow_empty_doc setting and to be > able to generically cache empty docs similar to any other response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3979) Remove allow empty doc cache setting.
[
https://issues.apache.org/jira/browse/TS-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3979:
--
Description:
Refer TS-3978, TS-621
Following a discussion on the IRC, opening this jira to deprecate the Allow
empty doc cache setting. The consensus is to cache anything that's cacheable
and valid (regardless, of if it's empty or non-empty) - Just to clarify, it is
not clear there's a way to ensure that it's safe to cache anything right now.
TS-621 tried to cache empty docs in the past but ran into many difficulties,
so, opening TS-3980 to investigate how Http layer (or other higher layers) may
safely indicate the CacheVC that it's safe to cache.
{code}
Amaryllis
7:50
sudheerv: do any other reverse proxies refuse to cache empty documents without
content-length? it's not something i've noticed before (in varnish, for
example)
Amaryllis
7:50
the connection could still be broken at any point in the response and result in
broken content being cached
7:51
but as a compromise, what if there was another option to only cache empty
responses for 3xx, which is probably 80% of use cases?
7:52
(maybe, in addition, it should accept transfer-encoding: chunked, since that
can indicate end-of-body)
zwoop_
7:54
Amaryllis we should talk to amc (he knows everything, we don't need Google
here) about this
7:54
zwoop_ is now known as woop
7:54
woop is now known as zwoop
7:54
zwoop left the room (quit: Changing host).
7:54
zwoop [~zwoop@apache/committer/zwoop] entered the room.
7:54
mode (+o zwoop) by ChanServ
zwoop
7:55
Amaryllis amc Maybe we could have a plugin API, that basically forces to set
f.allow_empty_doc ?
amc
7:55
I think you can change the CacheVC structure without problem.
Amaryllis
7:55
i think some sort of fix for this should be in core, at the moment TS won't
cache any of our redirects
amc
7:56
There's not a global config to allow that?
zwoop
7:56
Amaryllis does it send a Cache-Control header with the redirects ?
Amaryllis
7:56
amc, zwoop: the origin sends transfer-encoding: chunked instead of
content-length.
7:56
so even with cache-control it won't be cached, that's what this PR is to change
7:56
TS-3978
ASFBot
7:56
TS-3978: Allow empty document caching to follow normal logic -
https://issues.apache.org/jira/browse/TS-3978
zwoop
7:56
ah
7:57
yeah, that's expected
7:57
and is why we added that option to allow empty docs to be cached
Amaryllis
7:57
this is with that option enabled
zwoop
7:57
huh
Amaryllis
7:57
it still won't cache any document without content-length
zwoop
7:57
yeah, need CL: too
7:57
that's a requirement
Amaryllis
7:57
so i'll update the PR to also recognise chunked responses as being cacheable
even if empty
zwoop
7:57
otherwise, it can't distinguish the cases you were worried about (a broken
connection) vs a truly empty doc
Amaryllis
7:58
zwoop: right, but the PR makes it optional, only if allow_empty_doc=2
zwoop
7:58
heh, your redirect is Chunked ??
Amaryllis
7:58
yes, an empty chunked response
zwoop
7:58
is that even correct?
Amaryllis
7:58
it's perfectly valid, if somewhat unusual
zwoop
7:58
doesn't the chunking require the final "0" ?
7:58
which means, the doc isn't empty
Amaryllis
7:58
i think ATS is looking at 'empty' after de-chucking, isn't it?
7:59
because it's definitely not cacheing these responses
zwoop
7:59
not sure
7:59
gancho_ left the room (quit: Ping timeout: 272 seconds).
amc
7:59
I think Amaryllis is correct.
zwoop
7:59
Amaryllis but, I definitely remember that the CL: header was a requirement
that can not be ignored (safely), so not sure I think having an
allow_empty_doc=2 is ok
8:00
unless allow_empty_doc=2 also means allow Chunked content to be empty
amc
8:00
I need to check to see what ATS actually caches - the chunked data or the
payload.
zwoop
8:00
but, you have to have some indicator telling us that the doc really is empty
before we can cache it
8:00
amc is caches the unchunked data
8:00
it dechunks it, and caches that
8:01
is dechunk even a proper verb?
amc
8:01
Ah, but it caches the encoding header.
Amaryllis
8:01
zwoop: https://dpaste.de/6kUT
zwoop
8:01
amc Hmmm, really ? That doesn't sound right
amc
8:01
"zwoop drank too much at the summit and dechunked himself in the hallway". Yep,
a proper verb.
Amaryllis
8:01
that's the actual origin response causing problems for us
zwoop
8:01
amc I'd expect it to change it from chunked to a Content-Length:
amc
8:02
I was wondering about that.
zwoop
8:02
amc lets dechunk big time at the Bar camp
amc
8:02
What happens when the content is served? Is the encoding preserved and obeyed?
zwoop
8:03
for the first client (the cache miss) I think it seems the chunked response
Amaryllis
8:03
yes, TS returns a correct thunked response
8:03
and never caches it, so it's always the same
zwoop
8:03
but subsequent requests (when served out of cache) should ha
[jira] [Updated] (TS-3979) Remove allow empty doc cache setting.
[
https://issues.apache.org/jira/browse/TS-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3979:
--
Description:
Refer TS-3978, TS-621
Following a discussion on the IRC, opening this jira to deprecate the Allow
empty doc cache setting. The consensus is to cache anything that's cacheable
and valid (regardless, of if it's empty or non-empty).
{code}
Amaryllis
7:50
sudheerv: do any other reverse proxies refuse to cache empty documents without
content-length? it's not something i've noticed before (in varnish, for
example)
Amaryllis
7:50
the connection could still be broken at any point in the response and result in
broken content being cached
7:51
but as a compromise, what if there was another option to only cache empty
responses for 3xx, which is probably 80% of use cases?
7:52
(maybe, in addition, it should accept transfer-encoding: chunked, since that
can indicate end-of-body)
zwoop_
7:54
Amaryllis we should talk to amc (he knows everything, we don't need Google
here) about this
7:54
zwoop_ is now known as woop
7:54
woop is now known as zwoop
7:54
zwoop left the room (quit: Changing host).
7:54
zwoop [~zwoop@apache/committer/zwoop] entered the room.
7:54
mode (+o zwoop) by ChanServ
zwoop
7:55
Amaryllis amc Maybe we could have a plugin API, that basically forces to set
f.allow_empty_doc ?
amc
7:55
I think you can change the CacheVC structure without problem.
Amaryllis
7:55
i think some sort of fix for this should be in core, at the moment TS won't
cache any of our redirects
amc
7:56
There's not a global config to allow that?
zwoop
7:56
Amaryllis does it send a Cache-Control header with the redirects ?
Amaryllis
7:56
amc, zwoop: the origin sends transfer-encoding: chunked instead of
content-length.
7:56
so even with cache-control it won't be cached, that's what this PR is to change
7:56
TS-3978
ASFBot
7:56
TS-3978: Allow empty document caching to follow normal logic -
https://issues.apache.org/jira/browse/TS-3978
zwoop
7:56
ah
7:57
yeah, that's expected
7:57
and is why we added that option to allow empty docs to be cached
Amaryllis
7:57
this is with that option enabled
zwoop
7:57
huh
Amaryllis
7:57
it still won't cache any document without content-length
zwoop
7:57
yeah, need CL: too
7:57
that's a requirement
Amaryllis
7:57
so i'll update the PR to also recognise chunked responses as being cacheable
even if empty
zwoop
7:57
otherwise, it can't distinguish the cases you were worried about (a broken
connection) vs a truly empty doc
Amaryllis
7:58
zwoop: right, but the PR makes it optional, only if allow_empty_doc=2
zwoop
7:58
heh, your redirect is Chunked ??
Amaryllis
7:58
yes, an empty chunked response
zwoop
7:58
is that even correct?
Amaryllis
7:58
it's perfectly valid, if somewhat unusual
zwoop
7:58
doesn't the chunking require the final "0" ?
7:58
which means, the doc isn't empty
Amaryllis
7:58
i think ATS is looking at 'empty' after de-chucking, isn't it?
7:59
because it's definitely not cacheing these responses
zwoop
7:59
not sure
7:59
gancho_ left the room (quit: Ping timeout: 272 seconds).
amc
7:59
I think Amaryllis is correct.
zwoop
7:59
Amaryllis but, I definitely remember that the CL: header was a requirement
that can not be ignored (safely), so not sure I think having an
allow_empty_doc=2 is ok
8:00
unless allow_empty_doc=2 also means allow Chunked content to be empty
amc
8:00
I need to check to see what ATS actually caches - the chunked data or the
payload.
zwoop
8:00
but, you have to have some indicator telling us that the doc really is empty
before we can cache it
8:00
amc is caches the unchunked data
8:00
it dechunks it, and caches that
8:01
is dechunk even a proper verb?
amc
8:01
Ah, but it caches the encoding header.
Amaryllis
8:01
zwoop: https://dpaste.de/6kUT
zwoop
8:01
amc Hmmm, really ? That doesn't sound right
amc
8:01
"zwoop drank too much at the summit and dechunked himself in the hallway". Yep,
a proper verb.
Amaryllis
8:01
that's the actual origin response causing problems for us
zwoop
8:01
amc I'd expect it to change it from chunked to a Content-Length:
amc
8:02
I was wondering about that.
zwoop
8:02
amc lets dechunk big time at the Bar camp
amc
8:02
What happens when the content is served? Is the encoding preserved and obeyed?
zwoop
8:03
for the first client (the cache miss) I think it seems the chunked response
Amaryllis
8:03
yes, TS returns a correct thunked response
8:03
and never caches it, so it's always the same
zwoop
8:03
but subsequent requests (when served out of cache) should have a CL:
amc
8:03
I was thinking of what happens for chunked responses from origin that are
non-zero lenght.
zwoop
8:03
Amaryllis can you not convince your origin that they are crazy, and change it
to not send a Chunked empty response, and instead send CL: 0 ?
sudheerv
8:04
catching up on the messages…but, m
[jira] [Updated] (TS-3979) Remove allow empty doc cache setting.
[
https://issues.apache.org/jira/browse/TS-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3979:
--
Summary: Remove allow empty doc cache setting. (was: Deprecate allow empty
doc cache setting.)
> Remove allow empty doc cache setting.
> -
>
> Key: TS-3979
> URL: https://issues.apache.org/jira/browse/TS-3979
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 6.0.0
>Reporter: Sudheer Vinukonda
> Fix For: 7.0.0
>
>
> Refer TS-3978
> Following a discussion on the IRC, opening this jira to deprecate the Allow
> empty doc cache setting. The consensus is to cache anything that's cacheable
> and valid (regardless, of if it's empty or non-empty).
> {code}
> Amaryllis
> 7:50
> sudheerv: do any other reverse proxies refuse to cache empty documents
> without content-length? it's not something i've noticed before (in varnish,
> for example)
> Amaryllis
> 7:50
> the connection could still be broken at any point in the response and result
> in broken content being cached
> 7:51
> but as a compromise, what if there was another option to only cache empty
> responses for 3xx, which is probably 80% of use cases?
> 7:52
> (maybe, in addition, it should accept transfer-encoding: chunked, since that
> can indicate end-of-body)
> zwoop_
> 7:54
> Amaryllis we should talk to amc (he knows everything, we don't need Google
> here) about this
> 7:54
> zwoop_ is now known as woop
> 7:54
> woop is now known as zwoop
> 7:54
> zwoop left the room (quit: Changing host).
> 7:54
> zwoop [~zwoop@apache/committer/zwoop] entered the room.
> 7:54
> mode (+o zwoop) by ChanServ
> zwoop
> 7:55
> Amaryllis amc Maybe we could have a plugin API, that basically forces to set
> f.allow_empty_doc ?
> amc
> 7:55
> I think you can change the CacheVC structure without problem.
> Amaryllis
> 7:55
> i think some sort of fix for this should be in core, at the moment TS won't
> cache any of our redirects
> amc
> 7:56
> There's not a global config to allow that?
> zwoop
> 7:56
> Amaryllis does it send a Cache-Control header with the redirects ?
> Amaryllis
> 7:56
> amc, zwoop: the origin sends transfer-encoding: chunked instead of
> content-length.
> 7:56
> so even with cache-control it won't be cached, that's what this PR is to
> change
> 7:56
> TS-3978
> ASFBot
> 7:56
> TS-3978: Allow empty document caching to follow normal logic -
> https://issues.apache.org/jira/browse/TS-3978
> zwoop
> 7:56
> ah
> 7:57
> yeah, that's expected
> 7:57
> and is why we added that option to allow empty docs to be cached
> Amaryllis
> 7:57
> this is with that option enabled
> zwoop
> 7:57
> huh
> Amaryllis
> 7:57
> it still won't cache any document without content-length
> zwoop
> 7:57
> yeah, need CL: too
> 7:57
> that's a requirement
> Amaryllis
> 7:57
> so i'll update the PR to also recognise chunked responses as being cacheable
> even if empty
> zwoop
> 7:57
> otherwise, it can't distinguish the cases you were worried about (a broken
> connection) vs a truly empty doc
> Amaryllis
> 7:58
> zwoop: right, but the PR makes it optional, only if allow_empty_doc=2
> zwoop
> 7:58
> heh, your redirect is Chunked ??
> Amaryllis
> 7:58
> yes, an empty chunked response
> zwoop
> 7:58
> is that even correct?
> Amaryllis
> 7:58
> it's perfectly valid, if somewhat unusual
> zwoop
> 7:58
> doesn't the chunking require the final "0" ?
> 7:58
> which means, the doc isn't empty
> Amaryllis
> 7:58
> i think ATS is looking at 'empty' after de-chucking, isn't it?
> 7:59
> because it's definitely not cacheing these responses
> zwoop
> 7:59
> not sure
> 7:59
> gancho_ left the room (quit: Ping timeout: 272 seconds).
> amc
> 7:59
> I think Amaryllis is correct.
> zwoop
> 7:59
> Amaryllis but, I definitely remember that the CL: header was a requirement
> that can not be ignored (safely), so not sure I think having an
> allow_empty_doc=2 is ok
> 8:00
> unless allow_empty_doc=2 also means allow Chunked content to be empty
> amc
> 8:00
> I need to check to see what ATS actually caches - the chunked data or the
> payload.
> zwoop
> 8:00
> but, you have to have some indicator telling us that the doc really is empty
> before we can cache it
> 8:00
> amc is caches the unchunked data
> 8:00
> it dechunks it, and caches that
> 8:01
> is dechunk even a proper verb?
> amc
> 8:01
> Ah, but it caches the encoding header.
> Amaryllis
> 8:01
> zwoop: https://dpaste.de/6kUT
> zwoop
> 8:01
> amc Hmmm, really ? That doesn't sound right
> amc
> 8:01
> "zwoop drank too much at the summit and dechunked himself in the hallway".
> Yep, a proper verb.
> Amaryllis
> 8:01
> that's the actual origin response causing problems for us
> zwoop
> 8:01
> amc I'd expect it to change it from chunked to a Content-Length:
> amc
> 8:02
> I was wondering abo
[jira] [Updated] (TS-3979) Remove allow empty doc cache setting.
[
https://issues.apache.org/jira/browse/TS-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3979:
--
Affects Version/s: 6.0.0
Fix Version/s: 7.0.0
> Remove allow empty doc cache setting.
> -
>
> Key: TS-3979
> URL: https://issues.apache.org/jira/browse/TS-3979
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 6.0.0
>Reporter: Sudheer Vinukonda
> Fix For: 7.0.0
>
>
> Refer TS-3978
> Following a discussion on the IRC, opening this jira to deprecate the Allow
> empty doc cache setting. The consensus is to cache anything that's cacheable
> and valid (regardless, of if it's empty or non-empty).
> {code}
> Amaryllis
> 7:50
> sudheerv: do any other reverse proxies refuse to cache empty documents
> without content-length? it's not something i've noticed before (in varnish,
> for example)
> Amaryllis
> 7:50
> the connection could still be broken at any point in the response and result
> in broken content being cached
> 7:51
> but as a compromise, what if there was another option to only cache empty
> responses for 3xx, which is probably 80% of use cases?
> 7:52
> (maybe, in addition, it should accept transfer-encoding: chunked, since that
> can indicate end-of-body)
> zwoop_
> 7:54
> Amaryllis we should talk to amc (he knows everything, we don't need Google
> here) about this
> 7:54
> zwoop_ is now known as woop
> 7:54
> woop is now known as zwoop
> 7:54
> zwoop left the room (quit: Changing host).
> 7:54
> zwoop [~zwoop@apache/committer/zwoop] entered the room.
> 7:54
> mode (+o zwoop) by ChanServ
> zwoop
> 7:55
> Amaryllis amc Maybe we could have a plugin API, that basically forces to set
> f.allow_empty_doc ?
> amc
> 7:55
> I think you can change the CacheVC structure without problem.
> Amaryllis
> 7:55
> i think some sort of fix for this should be in core, at the moment TS won't
> cache any of our redirects
> amc
> 7:56
> There's not a global config to allow that?
> zwoop
> 7:56
> Amaryllis does it send a Cache-Control header with the redirects ?
> Amaryllis
> 7:56
> amc, zwoop: the origin sends transfer-encoding: chunked instead of
> content-length.
> 7:56
> so even with cache-control it won't be cached, that's what this PR is to
> change
> 7:56
> TS-3978
> ASFBot
> 7:56
> TS-3978: Allow empty document caching to follow normal logic -
> https://issues.apache.org/jira/browse/TS-3978
> zwoop
> 7:56
> ah
> 7:57
> yeah, that's expected
> 7:57
> and is why we added that option to allow empty docs to be cached
> Amaryllis
> 7:57
> this is with that option enabled
> zwoop
> 7:57
> huh
> Amaryllis
> 7:57
> it still won't cache any document without content-length
> zwoop
> 7:57
> yeah, need CL: too
> 7:57
> that's a requirement
> Amaryllis
> 7:57
> so i'll update the PR to also recognise chunked responses as being cacheable
> even if empty
> zwoop
> 7:57
> otherwise, it can't distinguish the cases you were worried about (a broken
> connection) vs a truly empty doc
> Amaryllis
> 7:58
> zwoop: right, but the PR makes it optional, only if allow_empty_doc=2
> zwoop
> 7:58
> heh, your redirect is Chunked ??
> Amaryllis
> 7:58
> yes, an empty chunked response
> zwoop
> 7:58
> is that even correct?
> Amaryllis
> 7:58
> it's perfectly valid, if somewhat unusual
> zwoop
> 7:58
> doesn't the chunking require the final "0" ?
> 7:58
> which means, the doc isn't empty
> Amaryllis
> 7:58
> i think ATS is looking at 'empty' after de-chucking, isn't it?
> 7:59
> because it's definitely not cacheing these responses
> zwoop
> 7:59
> not sure
> 7:59
> gancho_ left the room (quit: Ping timeout: 272 seconds).
> amc
> 7:59
> I think Amaryllis is correct.
> zwoop
> 7:59
> Amaryllis but, I definitely remember that the CL: header was a requirement
> that can not be ignored (safely), so not sure I think having an
> allow_empty_doc=2 is ok
> 8:00
> unless allow_empty_doc=2 also means allow Chunked content to be empty
> amc
> 8:00
> I need to check to see what ATS actually caches - the chunked data or the
> payload.
> zwoop
> 8:00
> but, you have to have some indicator telling us that the doc really is empty
> before we can cache it
> 8:00
> amc is caches the unchunked data
> 8:00
> it dechunks it, and caches that
> 8:01
> is dechunk even a proper verb?
> amc
> 8:01
> Ah, but it caches the encoding header.
> Amaryllis
> 8:01
> zwoop: https://dpaste.de/6kUT
> zwoop
> 8:01
> amc Hmmm, really ? That doesn't sound right
> amc
> 8:01
> "zwoop drank too much at the summit and dechunked himself in the hallway".
> Yep, a proper verb.
> Amaryllis
> 8:01
> that's the actual origin response causing problems for us
> zwoop
> 8:01
> amc I'd expect it to change it from chunked to a Content-Length:
> amc
> 8:02
> I was wondering about that.
> zwoop
> 8:02
> amc lets dechunk
[jira] [Created] (TS-3980) Improve empty doc caching.
Sudheer Vinukonda created TS-3980: - Summary: Improve empty doc caching. Key: TS-3980 URL: https://issues.apache.org/jira/browse/TS-3980 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Sudheer Vinukonda Refer TS-3978, TS-3979 Instead of using special config settings (e.g allow_empty_doc) to control caching of empty docs, the consensus is to always cache any doc that is cacheable and safe to cache (meaning, unbroken response, including Content-Length(0), Chunked Encoding (0), SPDY/H2(0) etc). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3979) Deprecate allow empty doc cache setting.
[
https://issues.apache.org/jira/browse/TS-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3979:
--
Summary: Deprecate allow empty doc cache setting. (was: Deprecate allow
empty doc cache setting)
> Deprecate allow empty doc cache setting.
>
>
> Key: TS-3979
> URL: https://issues.apache.org/jira/browse/TS-3979
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: Sudheer Vinukonda
>
> Refer TS-3978
> Following a discussion on the IRC, opening this jira to deprecate the Allow
> empty doc cache setting. The consensus is to cache anything that's cacheable
> and valid (regardless, of if it's empty or non-empty).
> {code}
> Amaryllis
> 7:50
> sudheerv: do any other reverse proxies refuse to cache empty documents
> without content-length? it's not something i've noticed before (in varnish,
> for example)
> Amaryllis
> 7:50
> the connection could still be broken at any point in the response and result
> in broken content being cached
> 7:51
> but as a compromise, what if there was another option to only cache empty
> responses for 3xx, which is probably 80% of use cases?
> 7:52
> (maybe, in addition, it should accept transfer-encoding: chunked, since that
> can indicate end-of-body)
> zwoop_
> 7:54
> Amaryllis we should talk to amc (he knows everything, we don't need Google
> here) about this
> 7:54
> zwoop_ is now known as woop
> 7:54
> woop is now known as zwoop
> 7:54
> zwoop left the room (quit: Changing host).
> 7:54
> zwoop [~zwoop@apache/committer/zwoop] entered the room.
> 7:54
> mode (+o zwoop) by ChanServ
> zwoop
> 7:55
> Amaryllis amc Maybe we could have a plugin API, that basically forces to set
> f.allow_empty_doc ?
> amc
> 7:55
> I think you can change the CacheVC structure without problem.
> Amaryllis
> 7:55
> i think some sort of fix for this should be in core, at the moment TS won't
> cache any of our redirects
> amc
> 7:56
> There's not a global config to allow that?
> zwoop
> 7:56
> Amaryllis does it send a Cache-Control header with the redirects ?
> Amaryllis
> 7:56
> amc, zwoop: the origin sends transfer-encoding: chunked instead of
> content-length.
> 7:56
> so even with cache-control it won't be cached, that's what this PR is to
> change
> 7:56
> TS-3978
> ASFBot
> 7:56
> TS-3978: Allow empty document caching to follow normal logic -
> https://issues.apache.org/jira/browse/TS-3978
> zwoop
> 7:56
> ah
> 7:57
> yeah, that's expected
> 7:57
> and is why we added that option to allow empty docs to be cached
> Amaryllis
> 7:57
> this is with that option enabled
> zwoop
> 7:57
> huh
> Amaryllis
> 7:57
> it still won't cache any document without content-length
> zwoop
> 7:57
> yeah, need CL: too
> 7:57
> that's a requirement
> Amaryllis
> 7:57
> so i'll update the PR to also recognise chunked responses as being cacheable
> even if empty
> zwoop
> 7:57
> otherwise, it can't distinguish the cases you were worried about (a broken
> connection) vs a truly empty doc
> Amaryllis
> 7:58
> zwoop: right, but the PR makes it optional, only if allow_empty_doc=2
> zwoop
> 7:58
> heh, your redirect is Chunked ??
> Amaryllis
> 7:58
> yes, an empty chunked response
> zwoop
> 7:58
> is that even correct?
> Amaryllis
> 7:58
> it's perfectly valid, if somewhat unusual
> zwoop
> 7:58
> doesn't the chunking require the final "0" ?
> 7:58
> which means, the doc isn't empty
> Amaryllis
> 7:58
> i think ATS is looking at 'empty' after de-chucking, isn't it?
> 7:59
> because it's definitely not cacheing these responses
> zwoop
> 7:59
> not sure
> 7:59
> gancho_ left the room (quit: Ping timeout: 272 seconds).
> amc
> 7:59
> I think Amaryllis is correct.
> zwoop
> 7:59
> Amaryllis but, I definitely remember that the CL: header was a requirement
> that can not be ignored (safely), so not sure I think having an
> allow_empty_doc=2 is ok
> 8:00
> unless allow_empty_doc=2 also means allow Chunked content to be empty
> amc
> 8:00
> I need to check to see what ATS actually caches - the chunked data or the
> payload.
> zwoop
> 8:00
> but, you have to have some indicator telling us that the doc really is empty
> before we can cache it
> 8:00
> amc is caches the unchunked data
> 8:00
> it dechunks it, and caches that
> 8:01
> is dechunk even a proper verb?
> amc
> 8:01
> Ah, but it caches the encoding header.
> Amaryllis
> 8:01
> zwoop: https://dpaste.de/6kUT
> zwoop
> 8:01
> amc Hmmm, really ? That doesn't sound right
> amc
> 8:01
> "zwoop drank too much at the summit and dechunked himself in the hallway".
> Yep, a proper verb.
> Amaryllis
> 8:01
> that's the actual origin response causing problems for us
> zwoop
> 8:01
> amc I'd expect it to change it from chunked to a Content-Length:
> amc
> 8:02
> I was wondering about that.
> zwoop
> 8:02
> amc lets dechunk big time
[jira] [Created] (TS-3979) Deprecate allow empty doc cache setting
Sudheer Vinukonda created TS-3979:
-
Summary: Deprecate allow empty doc cache setting
Key: TS-3979
URL: https://issues.apache.org/jira/browse/TS-3979
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Sudheer Vinukonda
Refer TS-3978
Following a discussion on the IRC, opening this jira to deprecate the Allow
empty doc cache setting. The consensus is to cache anything that's cacheable
and valid (regardless, of if it's empty or non-empty).
{code}
Amaryllis
7:50
sudheerv: do any other reverse proxies refuse to cache empty documents without
content-length? it's not something i've noticed before (in varnish, for
example)
Amaryllis
7:50
the connection could still be broken at any point in the response and result in
broken content being cached
7:51
but as a compromise, what if there was another option to only cache empty
responses for 3xx, which is probably 80% of use cases?
7:52
(maybe, in addition, it should accept transfer-encoding: chunked, since that
can indicate end-of-body)
zwoop_
7:54
Amaryllis we should talk to amc (he knows everything, we don't need Google
here) about this
7:54
zwoop_ is now known as woop
7:54
woop is now known as zwoop
7:54
zwoop left the room (quit: Changing host).
7:54
zwoop [~zwoop@apache/committer/zwoop] entered the room.
7:54
mode (+o zwoop) by ChanServ
zwoop
7:55
Amaryllis amc Maybe we could have a plugin API, that basically forces to set
f.allow_empty_doc ?
amc
7:55
I think you can change the CacheVC structure without problem.
Amaryllis
7:55
i think some sort of fix for this should be in core, at the moment TS won't
cache any of our redirects
amc
7:56
There's not a global config to allow that?
zwoop
7:56
Amaryllis does it send a Cache-Control header with the redirects ?
Amaryllis
7:56
amc, zwoop: the origin sends transfer-encoding: chunked instead of
content-length.
7:56
so even with cache-control it won't be cached, that's what this PR is to change
7:56
TS-3978
ASFBot
7:56
TS-3978: Allow empty document caching to follow normal logic -
https://issues.apache.org/jira/browse/TS-3978
zwoop
7:56
ah
7:57
yeah, that's expected
7:57
and is why we added that option to allow empty docs to be cached
Amaryllis
7:57
this is with that option enabled
zwoop
7:57
huh
Amaryllis
7:57
it still won't cache any document without content-length
zwoop
7:57
yeah, need CL: too
7:57
that's a requirement
Amaryllis
7:57
so i'll update the PR to also recognise chunked responses as being cacheable
even if empty
zwoop
7:57
otherwise, it can't distinguish the cases you were worried about (a broken
connection) vs a truly empty doc
Amaryllis
7:58
zwoop: right, but the PR makes it optional, only if allow_empty_doc=2
zwoop
7:58
heh, your redirect is Chunked ??
Amaryllis
7:58
yes, an empty chunked response
zwoop
7:58
is that even correct?
Amaryllis
7:58
it's perfectly valid, if somewhat unusual
zwoop
7:58
doesn't the chunking require the final "0" ?
7:58
which means, the doc isn't empty
Amaryllis
7:58
i think ATS is looking at 'empty' after de-chucking, isn't it?
7:59
because it's definitely not cacheing these responses
zwoop
7:59
not sure
7:59
gancho_ left the room (quit: Ping timeout: 272 seconds).
amc
7:59
I think Amaryllis is correct.
zwoop
7:59
Amaryllis but, I definitely remember that the CL: header was a requirement
that can not be ignored (safely), so not sure I think having an
allow_empty_doc=2 is ok
8:00
unless allow_empty_doc=2 also means allow Chunked content to be empty
amc
8:00
I need to check to see what ATS actually caches - the chunked data or the
payload.
zwoop
8:00
but, you have to have some indicator telling us that the doc really is empty
before we can cache it
8:00
amc is caches the unchunked data
8:00
it dechunks it, and caches that
8:01
is dechunk even a proper verb?
amc
8:01
Ah, but it caches the encoding header.
Amaryllis
8:01
zwoop: https://dpaste.de/6kUT
zwoop
8:01
amc Hmmm, really ? That doesn't sound right
amc
8:01
"zwoop drank too much at the summit and dechunked himself in the hallway". Yep,
a proper verb.
Amaryllis
8:01
that's the actual origin response causing problems for us
zwoop
8:01
amc I'd expect it to change it from chunked to a Content-Length:
amc
8:02
I was wondering about that.
zwoop
8:02
amc lets dechunk big time at the Bar camp
amc
8:02
What happens when the content is served? Is the encoding preserved and obeyed?
zwoop
8:03
for the first client (the cache miss) I think it seems the chunked response
Amaryllis
8:03
yes, TS returns a correct thunked response
8:03
and never caches it, so it's always the same
zwoop
8:03
but subsequent requests (when served out of cache) should have a CL:
amc
8:03
I was thinking of what happens for chunked responses from origin that are
non-zero lenght.
zwoop
8:03
Amaryllis can you not convince your origin th
[jira] [Comment Edited] (TS-3978) Allow empty document caching to follow normal logic
[ https://issues.apache.org/jira/browse/TS-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971121#comment-14971121 ] Sudheer Vinukonda edited comment on TS-3978 at 10/23/15 3:17 PM: - Yes, I understand that - My point is the patch must ensure that the final frame was received (unless, of course, chunked handling code already handles it indirectly). There are other cases where empty body without Content-Length may be received (e.g. when ATS supports outbound H2/SPDY). was (Author: sudheerv): Yes, I understand that - My point is the patch must ensure that the final frame was received (unless, of course, chunked handling code already handles it indirectly). > Allow empty document caching to follow normal logic > --- > > Key: TS-3978 > URL: https://issues.apache.org/jira/browse/TS-3978 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Felicity Tarnell > > Currently, allow_empty_doc only works if the origin sends a content-length > header. It should have a setting to enable empty documents to be cached in > the normal way without any special handling. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3978) Allow empty document caching to follow normal logic
[ https://issues.apache.org/jira/browse/TS-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971121#comment-14971121 ] Sudheer Vinukonda commented on TS-3978: --- Yes, I understand that - My point is the patch must ensure that the final frame was received (unless, of course, chunked handling code already handles it indirectly). > Allow empty document caching to follow normal logic > --- > > Key: TS-3978 > URL: https://issues.apache.org/jira/browse/TS-3978 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Felicity Tarnell > > Currently, allow_empty_doc only works if the origin sends a content-length > header. It should have a setting to enable empty documents to be cached in > the normal way without any special handling. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.
[ https://issues.apache.org/jira/browse/TS-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14944464#comment-14944464 ] Sudheer Vinukonda commented on TS-3072: --- Needless to say, I'm +1 on this feature being in the core with the ability to control with a simple config settings. The patch looks cool and simple and I love the fact that it will automatically output any new logs without having to make any additional changes. > Debug logging for a single connection in production traffic. > > > Key: TS-3072 > URL: https://issues.apache.org/jira/browse/TS-3072 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Logging >Affects Versions: 5.0.1 >Reporter: Sudheer Vinukonda > Labels: Yahoo > Fix For: sometime > > Attachments: ts-3072.diff > > > Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is > really hard to isolate/debug with the high traffic. Turning on debug logs in > traffic is unfortunately not an option due to performance impacts. Even if > you took a performance hit and turned on the logs, it is just as hard to > separate out the logs for a single connection/transaction among the millions > of the logs output in a short period of time. > I think it would be good if there's a way to turn on debug logs in a > controlled manner in production environment. One simple option is to support > a config setting for example, with a client-ip, which when set, would turn on > debug logs for any connection made by just that one client. If needed, > instead of one client-ip, we may allow configuring up to 'n' (say, 5) > client-ips. > If there are other ideas, please comment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized
[
https://issues.apache.org/jira/browse/TS-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3952:
--
Backport to Version: 6.0.0
> SSLNetVConnection::free crashes when "nh" is not initialized
>
>
> Key: TS-3952
> URL: https://issues.apache.org/jira/browse/TS-3952
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Sudheer Vinukonda
> Labels: yahoo
> Fix For: 6.1.0
>
>
> On failure to making a connection, the *nh* is not init'ed in netVC and
> ::free crashes on a null pointer.
>
> Below's the backtrace:
> {code}
> (gdb) bt
> #0 0x006da394 in Queue UnixNetVConnection::Link_read_ready_link>::remove (this=0x38,
> e=0x2b46c5b97e10) at ../../lib/ts/List.h:251
> #1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10,
> t=0x2b456810) at SSLNetVConnection.cc:630
> #2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10,
> t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
> #3 0x0073dbf8 in UnixNetProcessor::connect_re_internal
> (this=0x1029960, cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870,
> opt=0x2b456bc36de0,
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
> UnixNetProcessor.cc:255
> #4 0x00521d23 in NetProcessor::connect_re (this=0x1029960,
> cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0,
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
> ../iocore/net/P_UnixNetProcessor.h:87
> #5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0,
> raw=false) at HttpSM.cc:4759
> #6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7128
> #7 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at HttpSM.cc:2415
> #9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at HttpSM.cc:2522
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0,
> url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320,
> pin_in_cache=0, retry=true,
> allow_multiple=false) at HttpCacheSM.cc:297
> #12 0x005da126 in HttpSM::do_cache_prepare_action
> (this=0x2b4a5ca1c5c0, c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320,
> retry=true, allow_multiple=false)
> at HttpSM.cc:4513
> #13 0x005e8850 in HttpSM::do_cache_prepare_write
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4434
> #14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7211
> #15 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #18 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:437
> #20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:6979
> #21 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:3997
> #23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7078
> #24 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #27 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:437
> #29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:6979
> #30 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #33 0x005db6c7 in HttpSM::do_a
[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized
[
https://issues.apache.org/jira/browse/TS-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3952:
--
Fix Version/s: 6.1.0
> SSLNetVConnection::free crashes when "nh" is not initialized
>
>
> Key: TS-3952
> URL: https://issues.apache.org/jira/browse/TS-3952
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Sudheer Vinukonda
> Labels: yahoo
> Fix For: 6.1.0
>
>
> On failure to making a connection, the *nh* is not init'ed in netVC and
> ::free crashes on a null pointer.
>
> Below's the backtrace:
> {code}
> (gdb) bt
> #0 0x006da394 in Queue UnixNetVConnection::Link_read_ready_link>::remove (this=0x38,
> e=0x2b46c5b97e10) at ../../lib/ts/List.h:251
> #1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10,
> t=0x2b456810) at SSLNetVConnection.cc:630
> #2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10,
> t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
> #3 0x0073dbf8 in UnixNetProcessor::connect_re_internal
> (this=0x1029960, cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870,
> opt=0x2b456bc36de0,
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
> UnixNetProcessor.cc:255
> #4 0x00521d23 in NetProcessor::connect_re (this=0x1029960,
> cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0,
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
> ../iocore/net/P_UnixNetProcessor.h:87
> #5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0,
> raw=false) at HttpSM.cc:4759
> #6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7128
> #7 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at HttpSM.cc:2415
> #9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at HttpSM.cc:2522
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0,
> url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320,
> pin_in_cache=0, retry=true,
> allow_multiple=false) at HttpCacheSM.cc:297
> #12 0x005da126 in HttpSM::do_cache_prepare_action
> (this=0x2b4a5ca1c5c0, c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320,
> retry=true, allow_multiple=false)
> at HttpSM.cc:4513
> #13 0x005e8850 in HttpSM::do_cache_prepare_write
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4434
> #14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7211
> #15 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #18 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:437
> #20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:6979
> #21 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:3997
> #23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7078
> #24 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #27 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:437
> #29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:6979
> #30 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #33 0x005db6c7 in HttpSM::do_api_cal
[jira] [Resolved] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized
[
https://issues.apache.org/jira/browse/TS-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda resolved TS-3952.
---
Resolution: Fixed
> SSLNetVConnection::free crashes when "nh" is not initialized
>
>
> Key: TS-3952
> URL: https://issues.apache.org/jira/browse/TS-3952
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Sudheer Vinukonda
>
> On failure to making a connection, the *nh* is not init'ed in netVC and
> ::free crashes on a null pointer.
>
> Below's the backtrace:
> {code}
> (gdb) bt
> #0 0x006da394 in Queue UnixNetVConnection::Link_read_ready_link>::remove (this=0x38,
> e=0x2b46c5b97e10) at ../../lib/ts/List.h:251
> #1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10,
> t=0x2b456810) at SSLNetVConnection.cc:630
> #2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10,
> t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
> #3 0x0073dbf8 in UnixNetProcessor::connect_re_internal
> (this=0x1029960, cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870,
> opt=0x2b456bc36de0,
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
> UnixNetProcessor.cc:255
> #4 0x00521d23 in NetProcessor::connect_re (this=0x1029960,
> cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0,
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
> ../iocore/net/P_UnixNetProcessor.h:87
> #5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0,
> raw=false) at HttpSM.cc:4759
> #6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7128
> #7 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at HttpSM.cc:2415
> #9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at HttpSM.cc:2522
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0,
> url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320,
> pin_in_cache=0, retry=true,
> allow_multiple=false) at HttpCacheSM.cc:297
> #12 0x005da126 in HttpSM::do_cache_prepare_action
> (this=0x2b4a5ca1c5c0, c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320,
> retry=true, allow_multiple=false)
> at HttpSM.cc:4513
> #13 0x005e8850 in HttpSM::do_cache_prepare_write
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4434
> #14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7211
> #15 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #18 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:437
> #20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:6979
> #21 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:3997
> #23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7078
> #24 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #27 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:437
> #29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:6979
> #30 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #33 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #3
[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized
[
https://issues.apache.org/jira/browse/TS-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3952:
--
Description:
On failure to making a connection, the *nh* is not init'ed in netVC and ::free
crashes on a null pointer.
Below's the backtrace:
{code}
(gdb) bt
#0 0x006da394 in Queue::remove (this=0x38, e=0x2b46c5b97e10)
at ../../lib/ts/List.h:251
#1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10,
t=0x2b456810) at SSLNetVConnection.cc:630
#2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10,
t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
#3 0x0073dbf8 in UnixNetProcessor::connect_re_internal (this=0x1029960,
cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870, opt=0x2b456bc36de0,
servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
UnixNetProcessor.cc:255
#4 0x00521d23 in NetProcessor::connect_re (this=0x1029960,
cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0,
servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
../iocore/net/P_UnixNetProcessor.h:87
#5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0,
raw=false) at HttpSM.cc:4759
#6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:7128
#7 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0,
event=1109, data=0xb04f) at HttpSM.cc:2415
#9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0, event=1109,
data=0xb04f) at HttpSM.cc:2522
#10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0,
event=1109, data=0xb04f) at
../iocore/eventsystem/I_Continuation.h:146
#11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0,
url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320,
pin_in_cache=0, retry=true,
allow_multiple=false) at HttpCacheSM.cc:297
#12 0x005da126 in HttpSM::do_cache_prepare_action (this=0x2b4a5ca1c5c0,
c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320, retry=true,
allow_multiple=false)
at HttpSM.cc:4513
#13 0x005e8850 in HttpSM::do_cache_prepare_write (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4434
#14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:7211
#15 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
HttpSM.cc:1502
#17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
event=0, data=0x0) at HttpSM.cc:1438
#18 0x005db6c7 in HttpSM::do_api_callout_internal (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4875
#19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
HttpSM.cc:437
#20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:6979
#21 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at
HttpSM.cc:3997
#23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:7078
#24 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
HttpSM.cc:1502
#26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
event=0, data=0x0) at HttpSM.cc:1438
#27 0x005db6c7 in HttpSM::do_api_callout_internal (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4875
#28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
HttpSM.cc:437
#29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:6979
#30 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
HttpSM.cc:1502
#32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
event=0, data=0x0) at HttpSM.cc:1438
#33 0x005db6c7 in HttpSM::do_api_callout_internal (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4875
#34 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
HttpSM.cc:437
#35 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:6979
#36 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0x5f635a
)
at HttpSM.cc:6945
#37 0x005d2dd4 in HttpSM::state_cache_open_read (this=0x2b4a5ca1c5c0,
event=1102, data=0x2b46b57381d0) at HttpSM.cc:2463
#38 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0,
event=1102, data=0x2b46b57381d0) at HttpSM.cc:2522
#39 0x004f8d4c in Contin
[jira] [Issue Comment Deleted] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized
[
https://issues.apache.org/jira/browse/TS-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3952:
--
Comment: was deleted
(was: {code}
(gdb) bt
#0 0x006da394 in Queue::remove (this=0x38, e=0x2b46c5b97e10)
at ../../lib/ts/List.h:251
#1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10,
t=0x2b456810) at SSLNetVConnection.cc:630
#2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10,
t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
#3 0x0073dbf8 in UnixNetProcessor::connect_re_internal (this=0x1029960,
cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870, opt=0x2b456bc36de0,
servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
UnixNetProcessor.cc:255
#4 0x00521d23 in NetProcessor::connect_re (this=0x1029960,
cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0,
servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
../iocore/net/P_UnixNetProcessor.h:87
#5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0,
raw=false) at HttpSM.cc:4759
#6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:7128
#7 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0,
event=1109, data=0xb04f) at HttpSM.cc:2415
#9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0, event=1109,
data=0xb04f) at HttpSM.cc:2522
#10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0,
event=1109, data=0xb04f) at
../iocore/eventsystem/I_Continuation.h:146
#11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0,
url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320,
pin_in_cache=0, retry=true,
allow_multiple=false) at HttpCacheSM.cc:297
#12 0x005da126 in HttpSM::do_cache_prepare_action (this=0x2b4a5ca1c5c0,
c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320, retry=true,
allow_multiple=false)
at HttpSM.cc:4513
#13 0x005e8850 in HttpSM::do_cache_prepare_write (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4434
#14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:7211
#15 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
HttpSM.cc:1502
#17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
event=0, data=0x0) at HttpSM.cc:1438
#18 0x005db6c7 in HttpSM::do_api_callout_internal (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4875
#19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
HttpSM.cc:437
#20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:6979
#21 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at
HttpSM.cc:3997
#23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:7078
#24 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
HttpSM.cc:1502
#26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
event=0, data=0x0) at HttpSM.cc:1438
#27 0x005db6c7 in HttpSM::do_api_callout_internal (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4875
#28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
HttpSM.cc:437
#29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:6979
#30 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
HttpSM.cc:1502
#32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
event=0, data=0x0) at HttpSM.cc:1438
#33 0x005db6c7 in HttpSM::do_api_callout_internal (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4875
#34 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
HttpSM.cc:437
#35 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:6979
#36 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0x5f635a
)
at HttpSM.cc:6945
#37 0x005d2dd4 in HttpSM::state_cache_open_read (this=0x2b4a5ca1c5c0,
event=1102, data=0x2b46b57381d0) at HttpSM.cc:2463
#38 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0,
event=1102, data=0x2b46b57381d0) at HttpSM.cc:2522
#39 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0,
event=1102, data=0x2b46b57381d0) at ../iocore/eventsystem/I_Continuation.h:1
[jira] [Commented] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized
[
https://issues.apache.org/jira/browse/TS-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933941#comment-14933941
]
Sudheer Vinukonda commented on TS-3952:
---
{code}
(gdb) f 1
#1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10,
t=0x2b456810) at SSLNetVConnection.cc:630
630 SSLNetVConnection.cc: No such file or directory.
in SSLNetVConnection.cc
(gdb) p this
$1 = (SSLNetVConnection * const) 0x2b46c5b97e10
(gdb) p nh
$2 = (NetHandler *) 0x0
{code}
> SSLNetVConnection::free crashes when "nh" is not initialized
>
>
> Key: TS-3952
> URL: https://issues.apache.org/jira/browse/TS-3952
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Sudheer Vinukonda
>
> On failure to making a connection, the *nh* is not init'ed in netVC and
> ::free crashes on a null pointer.
>
> Below's the backtrace:
> {code}
> (gdb) bt
> #0 0x006da394 in Queue UnixNetVConnection::Link_read_ready_link>::remove (this=0x38,
> e=0x2b46c5b97e10) at ../../lib/ts/List.h:251
> #1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10,
> t=0x2b456810) at SSLNetVConnection.cc:630
> #2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10,
> t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
> #3 0x0073dbf8 in UnixNetProcessor::connect_re_internal
> (this=0x1029960, cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870,
> opt=0x2b456bc36de0,
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
> UnixNetProcessor.cc:255
> #4 0x00521d23 in NetProcessor::connect_re (this=0x1029960,
> cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0,
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
> ../iocore/net/P_UnixNetProcessor.h:87
> #5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0,
> raw=false) at HttpSM.cc:4759
> #6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7128
> #7 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at HttpSM.cc:2415
> #9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at HttpSM.cc:2522
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0,
> url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320,
> pin_in_cache=0, retry=true,
> allow_multiple=false) at HttpCacheSM.cc:297
> #12 0x005da126 in HttpSM::do_cache_prepare_action
> (this=0x2b4a5ca1c5c0, c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320,
> retry=true, allow_multiple=false)
> at HttpSM.cc:4513
> #13 0x005e8850 in HttpSM::do_cache_prepare_write
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4434
> #14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7211
> #15 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #18 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:437
> #20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:6979
> #21 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:3997
> #23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7078
> #24 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #27 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:437
> #29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:6979
> #30 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a
[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized
[
https://issues.apache.org/jira/browse/TS-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3952:
--
{code}
(gdb) bt
#0 0x006da394 in Queue::remove (this=0x38, e=0x2b46c5b97e10)
at ../../lib/ts/List.h:251
#1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10,
t=0x2b456810) at SSLNetVConnection.cc:630
#2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10,
t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
#3 0x0073dbf8 in UnixNetProcessor::connect_re_internal (this=0x1029960,
cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870, opt=0x2b456bc36de0,
servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
UnixNetProcessor.cc:255
#4 0x00521d23 in NetProcessor::connect_re (this=0x1029960,
cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0,
servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
../iocore/net/P_UnixNetProcessor.h:87
#5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0,
raw=false) at HttpSM.cc:4759
#6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:7128
#7 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0,
event=1109, data=0xb04f) at HttpSM.cc:2415
#9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0, event=1109,
data=0xb04f) at HttpSM.cc:2522
#10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0,
event=1109, data=0xb04f) at
../iocore/eventsystem/I_Continuation.h:146
#11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0,
url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320,
pin_in_cache=0, retry=true,
allow_multiple=false) at HttpCacheSM.cc:297
#12 0x005da126 in HttpSM::do_cache_prepare_action (this=0x2b4a5ca1c5c0,
c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320, retry=true,
allow_multiple=false)
at HttpSM.cc:4513
#13 0x005e8850 in HttpSM::do_cache_prepare_write (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4434
#14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:7211
#15 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
HttpSM.cc:1502
#17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
event=0, data=0x0) at HttpSM.cc:1438
#18 0x005db6c7 in HttpSM::do_api_callout_internal (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4875
#19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
HttpSM.cc:437
#20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:6979
#21 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at
HttpSM.cc:3997
#23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:7078
#24 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
HttpSM.cc:1502
#26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
event=0, data=0x0) at HttpSM.cc:1438
#27 0x005db6c7 in HttpSM::do_api_callout_internal (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4875
#28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
HttpSM.cc:437
#29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:6979
#30 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
#31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
HttpSM.cc:1502
#32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
event=0, data=0x0) at HttpSM.cc:1438
#33 0x005db6c7 in HttpSM::do_api_callout_internal (this=0x2b4a5ca1c5c0)
at HttpSM.cc:4875
#34 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
HttpSM.cc:437
#35 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
HttpSM.cc:6979
#36 0x005e2178 in HttpSM::call_transact_and_set_next_state
(this=0x2b4a5ca1c5c0, f=0x5f635a
)
at HttpSM.cc:6945
#37 0x005d2dd4 in HttpSM::state_cache_open_read (this=0x2b4a5ca1c5c0,
event=1102, data=0x2b46b57381d0) at HttpSM.cc:2463
#38 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0,
event=1102, data=0x2b46b57381d0) at HttpSM.cc:2522
#39 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0,
event=1102, data=0x2b46b57381d0) at ../iocore/eventsystem/I_Continuation.h:146
--Type to continue, or q t
[jira] [Created] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized
Sudheer Vinukonda created TS-3952:
-
Summary: SSLNetVConnection::free crashes when "nh" is not
initialized
Key: TS-3952
URL: https://issues.apache.org/jira/browse/TS-3952
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Sudheer Vinukonda
On failure to making a connection, the *nh* is not init'ed in netVC and ::free
crashes on a null pointer.
Below's the backtrace:
{code}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3950) PluginVC receives events after it's already closed.
[
https://issues.apache.org/jira/browse/TS-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933697#comment-14933697
]
Sudheer Vinukonda commented on TS-3950:
---
An example of an (timeout) event being delivered to a continuation that did not
register for it.
{code}
(gdb)
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0038fb433e05 in abort () at abort.c:92
#2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78 "%s:%d: failed
assert `%s`", ap=0x2ad27f7159f0)
at ink_error.cc:65
#4 0x2ad27ce811ae in ink_fatal (return_code=1,
message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries to
use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc", line=990) at
ink_assert.cc:37
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
event=106, edata=0x2ad3dad0) at InkAPI.cc:990
#7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at PluginVC.cc:762
#9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0, event=2,
data=0x2ad360081ef0) at PluginVC.cc:193
#10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
#11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
#12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
UnixEThread.cc:224
#13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
#14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
pthread_create.c:301
#15 0x0038fb4e88fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
{code}
The continuation that registered for timeout event is a different one that was
destroyed already, and the timeout event (106) got delivered to a different
continuation, likely coz, it was reassigned.
> PluginVC receives events after it's already closed.
> ---
>
> Key: TS-3950
> URL: https://issues.apache.org/jira/browse/TS-3950
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Plugins
>Reporter: Sudheer Vinukonda
>
> This is a follow up to TS-3949. It looks like PluginVC receives events (read,
> write, timeout etc) even after it's already closed. It currently ignores
> those events by checking the *closed* state. However, this looks to be
> inherently incorrect, since, accessing the data inside an already closed
> pluginVC is fraught with bugs (e.g. it could have been reallocated etc).
> Opening this jira to track the problem and see if it can be fixed better.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3950) PluginVC receives events after it's already closed.
Sudheer Vinukonda created TS-3950: - Summary: PluginVC receives events after it's already closed. Key: TS-3950 URL: https://issues.apache.org/jira/browse/TS-3950 Project: Traffic Server Issue Type: Bug Components: Core, Plugins Reporter: Sudheer Vinukonda This is a follow up to TS-3949. It looks like PluginVC receives events (read, write, timeout etc) even after it's already closed. It currently ignores those events by checking the *closed* state. However, this looks to be inherently incorrect, since, accessing the data inside an already closed pluginVC is fraught with bugs (e.g. it could have been reallocated etc). Opening this jira to track the problem and see if it can be fixed better. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3949) Ignore timeout event on PluginVC after it's already closed.
[
https://issues.apache.org/jira/browse/TS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3949:
--
Description:
When a plugin sets TS_EVENT_VCONN_ACTIVE_TIMEOUT on Plugin VC, it looks like,
in some race conditions, the active timer event could still get fired after the
Plugin VC is already closed, leading *INKContInternal::handle_event* to assert
a use-after-free.
Note: The plugin VC's process_close does cancel the active timeout event, so,
this doesn't happen every time. It might happen in some race conditions or when
the timeout and close are on different threads (?)..
Below's the fatal log and gdb info of the assert for the timeout event after a
close.
{code}
Sep 26 21:54:54 my_dev_host traffic_server[20653]: FATAL: InkAPI.cc:990: failed
assert `!"Plugin tries to use a continuation which is deleted"`
gdb stack trace:
Core was generated by `/home/y/bin/traffic_server -M --httpport
80:fd=8,443:fd=9:ssl'.
Program terminated with signal 6, Aborted.
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0038fb433e05 in abort () at abort.c:92
#2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78 "%s:%d: failed
assert `%s`", ap=0x2ad27f7159f0)
at ink_error.cc:65
#4 0x2ad27ce811ae in ink_fatal (return_code=1,
message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries to
use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc", line=990) at
ink_assert.cc:37
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
event=106, edata=0x2ad3dad0) at InkAPI.cc:990
#7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at PluginVC.cc:762
#9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0, event=2,
data=0x2ad360081ef0) at PluginVC.cc:193
#10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
#11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
#12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
UnixEThread.cc:224
#13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
#14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
pthread_create.c:301
#15 0x0038fb4e88fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) bt
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0038fb433e05 in abort () at abort.c:92
#2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78 "%s:%d: failed
assert `%s`", ap=0x2ad27f7159f0)
at ink_error.cc:65
#4 0x2ad27ce811ae in ink_fatal (return_code=1,
message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries to
use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc", line=990) at
ink_assert.cc:37
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
event=106, edata=0x2ad3dad0) at InkAPI.cc:990
#7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at PluginVC.cc:762
#9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0, event=2,
data=0x2ad360081ef0) at PluginVC.cc:193
#10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
#11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
#12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
UnixEThread.cc:224
#13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
#14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
pthread_create.c:301
#15 0x0038fb4e88fd
[jira] [Updated] (TS-3949) Ignore timeout event on PluginVC after it's already closed.
[
https://issues.apache.org/jira/browse/TS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3949:
--
Summary: Ignore timeout event on PluginVC after it's already closed. (was:
Active timeout event on PluginVC may fire after it's already closed.)
> Ignore timeout event on PluginVC after it's already closed.
> ---
>
> Key: TS-3949
> URL: https://issues.apache.org/jira/browse/TS-3949
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Plugins
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.1.0
>
>
> When a plugin sets TS_EVENT_VCONN_ACTIVE_TIMEOUT on Plugin VC, it looks like,
> in some race conditions, the active timer event could still get fired after
> the Plugin VC is already closed, leading INKContInternal::handle_event to
> assert a use-after-free.
> Note: The plugin VC's process_close does cancel the active timeout event, so,
> this doesn't happen every time. It might happen in some race conditions or
> when the timeout and close are on different threads (?)..
> Below's the fatal log and gdb info of the assert for the timeout event after
> a close.
> {code}
> Sep 26 21:54:54 my_dev_host traffic_server[20653]: FATAL: InkAPI.cc:990:
> failed assert `!"Plugin tries to use a continuation which is deleted"`
> gdb stack trace:
> Core was generated by `/home/y/bin/traffic_server -M --httpport
> 80:fd=8,443:fd=9:ssl'.
> Program terminated with signal 6, Aborted.
> #0 0x0038fb432625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) bt
> #0 0x0038fb432625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x0038fb433e05 in abort () at abort.c:92
> #2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78
> "%s:%d: failed assert `%s`", ap=0x2ad27f7159f0)
> at ink_error.cc:65
> #4 0x2ad27ce811ae in ink_fatal (return_code=1,
> message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries
> to use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc",
> line=990) at ink_assert.cc:37
> #6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
> event=106, edata=0x2ad3dad0) at InkAPI.cc:990
> #7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
> event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
> #8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
> e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at
> PluginVC.cc:762
> #9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0,
> event=2, data=0x2ad360081ef0) at PluginVC.cc:193
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
> event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
> #11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
> e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
> #12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
> UnixEThread.cc:224
> #13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
> #14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
> pthread_create.c:301
> #15 0x0038fb4e88fd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> (gdb) bt
> #0 0x0038fb432625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x0038fb433e05 in abort () at abort.c:92
> #2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78
> "%s:%d: failed assert `%s`", ap=0x2ad27f7159f0)
> at ink_error.cc:65
> #4 0x2ad27ce811ae in ink_fatal (return_code=1,
> message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries
> to use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc",
> line=990) at ink_assert.cc:37
> #6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
> event=106, edata=0x2ad3dad0) at InkAPI.cc:990
> #7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
> event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
> #8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
> e=0x2ad360081ef0, event_to_send=106, our_e
[jira] [Commented] (TS-3949) Active timeout event on PluginVC may fire after it's already closed.
[
https://issues.apache.org/jira/browse/TS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909804#comment-14909804
]
Sudheer Vinukonda commented on TS-3949:
---
Another related issue - perhaps, on a read/write, we should also check if the
vio's continuation in PluginVC is dead and not call handle_event (which would
assert).
{code}
(gdb) bt
#0 0x2b5379e21625 in raise () from /lib64/libc.so.6
#1 0x2b5379e22e05 in abort () from /lib64/libc.so.6
#2 0x2b537722a018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b537722a0e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2b5377238d78 "%s:%d: failed
assert `%s`", ap=0x2b5381311900)
at ink_error.cc:65
#4 0x2b537722a1ae in ink_fatal (return_code=1,
message_format=0x2b5377238d78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2b5377228d20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries to
use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc", line=990) at
ink_assert.cc:37
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2b538c221400,
event=100, edata=0x2b54d0017e00) at InkAPI.cc:990
#7 0x004f8d4c in Continuation::handleEvent (this=0x2b538c221400,
event=100, data=0x2b54d0017e00) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x00534355 in PluginVC::process_read_side (this=0x2b54d0017d00,
other_side_call=true) at PluginVC.cc:670
#9 0x00533bea in PluginVC::process_write_side (this=0x2b54d0017ee8,
other_side_call=false) at PluginVC.cc:566
#10 0x00532904 in PluginVC::main_handler (this=0x2b54d0017ee8, event=1,
data=0x2b54c405ee80) at PluginVC.cc:212
#11 0x004f8d4c in Continuation::handleEvent (this=0x2b54d0017ee8,
event=1, data=0x2b54c405ee80) at ../iocore/eventsystem/I_Continuation.h:146
#12 0x0076080a in EThread::process_event (this=0x2b5380707010,
e=0x2b54c405ee80, calling_code=1) at UnixEThread.cc:145
#13 0x007609d8 in EThread::execute (this=0x2b5380707010) at
UnixEThread.cc:196
#14 0x0075fd7c in spawn_thread_internal (a=0x11581c0) at Thread.cc:88
#15 0x2b5378ee09d1 in start_thread () from /lib64/libpthread.so.0
#16 0x2b5379ed78fd in clone () from /lib64/libc.so.6
(gdb) f 6
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2b538c221400,
event=100, edata=0x2b54d0017e00) at InkAPI.cc:990
990 InkAPI.cc: No such file or directory.
in InkAPI.cc
(gdb) p *this
$1 = { = { = { =
{ = {_vptr.force_VFPT_to_top = 0x2b54642db000}, handler =
(int (Continuation::*)(Continuation *, int,
void *)) 0x50d686 , mutex =
{m_ptr = 0x0}, link = {> = {next = 0x0}, prev = 0x0}},
lerrno = 0}, },
mdata = 0x2b54d0001280, m_event_func = 0x2b5383b8bebc
, m_event_count = 0, m_closed
= 1, m_deletable = 1, m_deleted = 1,
m_free_magic = INKCONT_INTERN_MAGIC_DEAD}
(gdb) f 8
#8 0x00534355 in PluginVC::process_read_side (this=0x2b54d0017d00,
other_side_call=true) at PluginVC.cc:670
670 PluginVC.cc: No such file or directory.
in PluginVC.cc
(gdb) p closed
$2 = false
(gdb) p read_side
No symbol "read_side" in current context.
(gdb) p read_state
$3 = {vio = {_cont = 0x2b538c221400, nbytes = 9223372036854775807, ndone = 477,
op = 1, buffer = {mbuf = 0x2b548c15f390, entry = 0x0}, vc_server =
0x2b54d0017d00, mutex = {
m_ptr = 0x2b548c0b9840}}, shutdown = false}
(gdb) p write_state
$4 = {vio = {_cont = 0x2b538c221400, nbytes = 125, ndone = 125, op = 2, buffer
= {mbuf = 0x2b546404c910, entry = 0x2b546404c928}, vc_server = 0x2b54d0017d00,
mutex = {m_ptr = 0x2b548c0b9840}},
shutdown = false}
(gdb) p magci
No symbol "magci" in current context.
(gdb) p magic
$5 = 2864434397
(gdb) p/x magic
$6 = 0xaabbccdd
(gdb) f 8
#8 0x00534355 in PluginVC::process_read_side (this=0x2b54d0017d00,
other_side_call=true) at PluginVC.cc:670
670 in PluginVC.cc
(gdb) p read_state
$7 = {vio = {_cont = 0x2b538c221400, nbytes = 9223372036854775807, ndone = 477,
op = 1, buffer = {mbuf = 0x2b548c15f390, entry = 0x0}, vc_server =
0x2b54d0017d00, mutex = {
m_ptr = 0x2b548c0b9840}}, shutdown = false}
(gdb) p *(INKContInternal*) 0x2b538c221400
$8 = { = { = { =
{ = {_vptr.force_VFPT_to_top = 0x2b54642db000}, handler =
(int (Continuation::*)(Continuation *, int,
void *)) 0x50d686 , mutex =
{m_ptr = 0x0}, link = {> = {next = 0x0}, prev = 0x0}},
lerrno = 0}, },
mdata = 0x2b54d0001280, m_event_func = 0x2b5383b8bebc
, m_event_count = 0, m_closed
= 1, m_deletable = 1, m_deleted = 1,
m_free_magic = INKCONT_INTERN_MAGIC_DEAD}
(gdb) p closed
$9 = false
(gdb)
$10 = false
{code}
> Active timeout event on PluginVC may fire after it's already closed.
>
>
> Key: TS-3949
> URL: https://issues.apache.org/jira/browse/TS-3949
>
[jira] [Updated] (TS-3949) Active timeout event on PluginVC may fire after it's already closed.
[
https://issues.apache.org/jira/browse/TS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3949:
--
Description:
When a plugin sets TS_EVENT_VCONN_ACTIVE_TIMEOUT on Plugin VC, it looks like,
in some race conditions, the active timer event could still get fired after the
Plugin VC is already closed, leading INKContInternal::handle_event to assert a
use-after-free.
Note: The plugin VC's process_close does cancel the active timeout event, so,
this doesn't happen every time. It might happen in some race conditions or when
the timeout and close are on different threads (?)..
Below's the fatal log and gdb info of the assert for the timeout event after a
close.
{code}
Sep 26 21:54:54 host traffic_server[20653]: FATAL: InkAPI.cc:990: failed assert
`!"Plugin tries to use a continuation which is deleted"`
gdb stack trace:
Core was generated by `/home/y/bin/traffic_server -M --httpport
80:fd=8,443:fd=9:ssl'.
Program terminated with signal 6, Aborted.
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0038fb433e05 in abort () at abort.c:92
#2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78 "%s:%d: failed
assert `%s`", ap=0x2ad27f7159f0)
at ink_error.cc:65
#4 0x2ad27ce811ae in ink_fatal (return_code=1,
message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries to
use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc", line=990) at
ink_assert.cc:37
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
event=106, edata=0x2ad3dad0) at InkAPI.cc:990
#7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at PluginVC.cc:762
#9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0, event=2,
data=0x2ad360081ef0) at PluginVC.cc:193
#10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
#11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
#12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
UnixEThread.cc:224
#13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
#14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
pthread_create.c:301
#15 0x0038fb4e88fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) bt
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0038fb433e05 in abort () at abort.c:92
#2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78 "%s:%d: failed
assert `%s`", ap=0x2ad27f7159f0)
at ink_error.cc:65
#4 0x2ad27ce811ae in ink_fatal (return_code=1,
message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries to
use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc", line=990) at
ink_assert.cc:37
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
event=106, edata=0x2ad3dad0) at InkAPI.cc:990
#7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at PluginVC.cc:762
#9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0, event=2,
data=0x2ad360081ef0) at PluginVC.cc:193
#10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
#11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
#12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
UnixEThread.cc:224
#13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
#14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
pthread_create.c:301
#15 0x0038fb4e88fd in clone
[jira] [Updated] (TS-3949) Active timeout event on PluginVC may fire after it's already closed.
[
https://issues.apache.org/jira/browse/TS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3949:
--
Description:
When a plugin sets TS_EVENT_VCONN_ACTIVE_TIMEOUT on Plugin VC, it looks like,
in some race conditions, the active timer event could still get fired after the
Plugin VC is already closed, leading INKContInternal::handle_event to assert a
use-after-free.
Note: The plugin VC's process_close does cancel the active timeout event, so,
this doesn't happen every time. It might happen in some race conditions or when
the timeout and close are on different threads (?)..
Below's the fatal log and gdb info of the assert for the timeout event after a
close.
{code}
Sep 26 21:54:54 my_dev_host traffic_server[20653]: FATAL: InkAPI.cc:990: failed
assert `!"Plugin tries to use a continuation which is deleted"`
gdb stack trace:
Core was generated by `/home/y/bin/traffic_server -M --httpport
80:fd=8,443:fd=9:ssl'.
Program terminated with signal 6, Aborted.
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0038fb433e05 in abort () at abort.c:92
#2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78 "%s:%d: failed
assert `%s`", ap=0x2ad27f7159f0)
at ink_error.cc:65
#4 0x2ad27ce811ae in ink_fatal (return_code=1,
message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries to
use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc", line=990) at
ink_assert.cc:37
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
event=106, edata=0x2ad3dad0) at InkAPI.cc:990
#7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at PluginVC.cc:762
#9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0, event=2,
data=0x2ad360081ef0) at PluginVC.cc:193
#10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
#11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
#12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
UnixEThread.cc:224
#13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
#14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
pthread_create.c:301
#15 0x0038fb4e88fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) bt
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0038fb433e05 in abort () at abort.c:92
#2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78 "%s:%d: failed
assert `%s`", ap=0x2ad27f7159f0)
at ink_error.cc:65
#4 0x2ad27ce811ae in ink_fatal (return_code=1,
message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries to
use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc", line=990) at
ink_assert.cc:37
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
event=106, edata=0x2ad3dad0) at InkAPI.cc:990
#7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at PluginVC.cc:762
#9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0, event=2,
data=0x2ad360081ef0) at PluginVC.cc:193
#10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
#11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
#12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
UnixEThread.cc:224
#13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
#14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
pthread_create.c:301
#15 0x0038fb4e88fd in
[jira] [Updated] (TS-3949) Active timeout event on PluginVC may fire after it's already closed.
[
https://issues.apache.org/jira/browse/TS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3949:
--
Description:
When a plugin sets TS_EVENT_VCONN_ACTIVE_TIMEOUT on Plugin VC, it looks like,
in some race conditions, the active timer event could still get fired after the
Plugin VC is already closed, leading INKContInternal::handle_event to assert a
use-after-free.
Note: The plugin VC's process_close does cancel the active timeout event, so,
this doesn't happen every time. It might happen in some race conditions or when
the timeout and close are on different threads (?)..
Below's the stack trace of the assert for the timeout event after a close
{code}
Core was generated by `/home/y/bin/traffic_server -M --httpport
80:fd=8,443:fd=9:ssl'.
Program terminated with signal 6, Aborted.
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0038fb433e05 in abort () at abort.c:92
#2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78 "%s:%d: failed
assert `%s`", ap=0x2ad27f7159f0)
at ink_error.cc:65
#4 0x2ad27ce811ae in ink_fatal (return_code=1,
message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries to
use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc", line=990) at
ink_assert.cc:37
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
event=106, edata=0x2ad3dad0) at InkAPI.cc:990
#7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at PluginVC.cc:762
#9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0, event=2,
data=0x2ad360081ef0) at PluginVC.cc:193
#10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
#11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
#12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
UnixEThread.cc:224
#13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
#14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
pthread_create.c:301
#15 0x0038fb4e88fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) bt
#0 0x0038fb432625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0038fb433e05 in abort () at abort.c:92
#2 0x2ad27ce81018 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2ad27ce810e5 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=0x2ad27ce8fd78 "%s:%d: failed
assert `%s`", ap=0x2ad27f7159f0)
at ink_error.cc:65
#4 0x2ad27ce811ae in ink_fatal (return_code=1,
message_format=0x2ad27ce8fd78 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x2ad27ce7fd20 in _ink_assert (expression=0x770ba0 "!\"Plugin tries to
use a continuation which is deleted\"", file=0x770b3d "InkAPI.cc", line=990) at
ink_assert.cc:37
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
event=106, edata=0x2ad3dad0) at InkAPI.cc:990
#7 0x004f8d4c in Continuation::handleEvent (this=0x2ad37b27e500,
event=106, data=0x2ad3dad0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0053478b in PluginVC::process_timeout (this=0x2ad3d9d0,
e=0x2ad360081ef0, event_to_send=106, our_eptr=0x2ad3db88) at PluginVC.cc:762
#9 0x005327b1 in PluginVC::main_handler (this=0x2ad3d9d0, event=2,
data=0x2ad360081ef0) at PluginVC.cc:193
#10 0x004f8d4c in Continuation::handleEvent (this=0x2ad3d9d0,
event=2, data=0x2ad360081ef0) at ../iocore/eventsystem/I_Continuation.h:146
#11 0x0076080a in EThread::process_event (this=0x2ad27eb0b010,
e=0x2ad360081ef0, calling_code=2) at UnixEThread.cc:145
#12 0x00760b25 in EThread::execute (this=0x2ad27eb0b010) at
UnixEThread.cc:224
#13 0x0075fd7c in spawn_thread_internal (a=0x2fc9f80) at Thread.cc:88
#14 0x2ad27d4009d1 in start_thread (arg=0x2ad27f716700) at
pthread_create.c:301
#15 0x0038fb4e88fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) f
#6 0x0050d6bc in INKContInternal::handle_event (this=0x2ad37b27e500,
event=106, edata=0x2ad3dad
[jira] [Updated] (TS-3949) Active timeout event on PluginVC may fire after it's already closed.
[ https://issues.apache.org/jira/browse/TS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3949: -- Assignee: Sudheer Vinukonda Fix Version/s: 6.1.0 > Active timeout event on PluginVC may fire after it's already closed. > > > Key: TS-3949 > URL: https://issues.apache.org/jira/browse/TS-3949 > Project: Traffic Server > Issue Type: Bug > Components: Core, Plugins >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > When a plugin sets TS_EVENT_VCONN_ACTIVE_TIMEOUT on Plugin VC, it looks like, > in some race conditions, the active timer event could still get fired after > the Plugin VC is already closed, leading INKContInternal::handle_event to > assert a use-after-free. > Note: The plugin VC's process_close does cancel the active timeout event, so, > this doesn't happen every time. It might happen in some race conditions or > when the timeout and close are on different threads (?).. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3949) Active timeout event on PluginVC may fire after it's already closed.
Sudheer Vinukonda created TS-3949: - Summary: Active timeout event on PluginVC may fire after it's already closed. Key: TS-3949 URL: https://issues.apache.org/jira/browse/TS-3949 Project: Traffic Server Issue Type: Bug Components: Core, Plugins Reporter: Sudheer Vinukonda When a plugin sets TS_EVENT_VCONN_ACTIVE_TIMEOUT on Plugin VC, it looks like, in some race conditions, the active timer event could still get fired after the Plugin VC is already closed, leading INKContInternal::handle_event to assert a use-after-free. Note: The plugin VC's process_close does cancel the active timeout event, so, this doesn't happen every time. It might happen in some race conditions or when the timeout and close are on different threads (?).. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
