[jira] [Commented] (TS-996) HTTPHdr::m_host goes stale if HdrHeap::evacuate_from_str_heaps is called
[
https://issues.apache.org/jira/browse/TS-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188160#comment-13188160
]
Leif Hedstrom commented on TS-996:
--
With v3, I get a compilation failure:
{code}
HttpTransact.cc: In function \u2018HttpTransact::StateMachineAction_t
how_to_open_connection(HttpTransact::State*)\u2019:
HttpTransact.cc:5533:58: error: \u2018host_len\u2019 may be used uninitialized
in this function [-Werror=uninitialized]
HttpTransact.cc:5531:7: note: \u2018host_len\u2019 was declared here
cc1plus: all warnings being treated as errors
{code}
> HTTPHdr::m_host goes stale if HdrHeap::evacuate_from_str_heaps is called
>
>
> Key: TS-996
> URL: https://issues.apache.org/jira/browse/TS-996
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, MIME
>Affects Versions: 3.1.0
>Reporter: B Wyatt
>Assignee: Leif Hedstrom
> Fix For: 3.1.2
>
> Attachments: m_host.V2.patch, m_host.patch, m_host.v3.patch
>
>
> class HTTPHdr stores a copy of the string pointer from either the URLimpl or
> the MIMEHdr for the host name in m_host. In both cases, these strings can be
> moved to a new heap underneath the HTTPHdr. When this happens, the process
> will, at best read stale memory and be fine and at worst read unmapped memory
> and segfault.
> Currently, HdrHeap::evacuate_from_str_heaps is called to coalesce multiple
> heaps into a single heap. When this happens it will directly access the low
> level objects via ::move_strings calls. These objects do not posses the
> necessary information to inform parent objects about the change, nor does the
> HdrHeap directly inform interested parties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1081) Eliminate the additional internal copy of the "pristine" URL string
[ https://issues.apache.org/jira/browse/TS-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1081: -- Attachment: TS-1081.diff Proposed changes to eliminate the additional string reference to the pristine URL. > Eliminate the additional internal copy of the "pristine" URL string > --- > > Key: TS-1081 > URL: https://issues.apache.org/jira/browse/TS-1081 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.1.2 > > Attachments: TS-1081.diff > > > We have (at least) two copies of the pristine URL in the code. One is the > actual URL object (as used by the APIs), and one is a string reference to the > URL (char*). The latter is only used in a couple of places, primarily when > the tag is used in a custom log format. I propose that we eliminate > this additional string version of the pristine URL entirely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1081) Eliminate the additional internal copy of the "pristine" URL string
Eliminate the additional internal copy of the "pristine" URL string --- Key: TS-1081 URL: https://issues.apache.org/jira/browse/TS-1081 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.2 We have (at least) two copies of the pristine URL in the code. One is the actual URL object (as used by the APIs), and one is a string reference to the URL (char*). The latter is only used in a couple of places, primarily when the tag is used in a custom log format. I propose that we eliminate this additional string version of the pristine URL entirely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1080) Assert under heavy load with logging enabled
Assert under heavy load with logging enabled
Key: TS-1080
URL: https://issues.apache.org/jira/browse/TS-1080
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Priority: Critical
Fix For: 3.1.2
Given enough load (in the 100,000 QPS or more), we run out of some sort of
buffer space, with an assert of
{code}
#0 0x2ba719d50285 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x2ba719d51b9b in __GI_abort () at abort.c:91
#2 0x006b561a in ink_die_die_die (retval=) at
ink_error.cc:43
#3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *)
(return_code=, message_format=,
ap=0x7fff7275a7d8) at ink_error.cc:65
#4 0x006b56a7 in ink_fatal (return_code=,
message_format=) at ink_error.cc:73
#5 0x006b4970 in _ink_assert (a=0x6fd380
"_num_flush_buffers[_open_flush_array] < FLUSH_ARRAY_SIZE", f=,
l=96) at ink_assert.cc:44
#6 0x005a8b34 in add_to_flush_queue (buffer=0x2ba7443ca970,
this=0x22fb918) at LogObject.h:96
#7 LogObject::_checkout_write (this=0x22fb880, write_offset=0x7fff7275add8,
bytes_needed=152) at LogObject.cc:455
#8 0x005a8fd3 in LogObject::log (this=0x22fb880, lad=0x7fff7275b030,
text_entry=0x0) at LogObject.cc:580
#9 0x0058e956 in log (lad=0x7fff7275b030, this=) at
LogObject.h:475
#10 Log::access (lad=0x7fff7275b030) at Log.cc:1086
{code}
Increasing FLUSH_ARRAY_SIZE alleviates the problem, but really, we shouldn't
end up in this situation at all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-998) Broken ClientReq in TSAPI
[ https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187728#comment-13187728 ] Leif Hedstrom commented on TS-998: -- So, the issue is just that you get the http:// in the URL "printout", is that the case? That's an artifact in how we represent the URLs, I'm fairly certain, but I can check that. I'm still very weary on having this expensive "feature" in there, just to make this copy of the request string that almost no one will ever use. At a minimum, I think this needs to be disabled by default, and turned on via either an API addition, or a records.config (either is fine with me). Let me know if you need help making it records.config'urable. I will look into fixing the PristineURL, but I don't think that will help you anyways. The URL "print" (or stringify getter) would still include the http:// I'm fairly certain. > Broken ClientReq in TSAPI > - > > Key: TS-998 > URL: https://issues.apache.org/jira/browse/TS-998 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.0.1 > Environment: any >Reporter: Nick Kew >Assignee: Nick Kew > Fix For: 3.1.2 > > > Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request > line. > Expected behaviour: In a PRE_REMAP hook it should return the client request > line and headers, ideally verbatim. > Observed behaviour: "http://"; is prepended to the request URL: > GET /path/ HTTP/1.1 > becomes > GET http:///path/ HTTP/1.1 > (yes, that's three slashes) > Pseudo-code to reproduce from a PRE_REMAP hook: > TSHttpTxnClientReqGet(txnp, &buf, &hdr); > TSHttpHdrPrint(buf, hdr, iobuf); > reader = TSIOBufferReaderAlloc(iobuf); > block = TSIOBufferReaderStart(reader); > len = TSIOBufferBlockReadAvail(block, reader); > data = TSIOBufferBlockReadStart(block, reader, &len); > Now examine the contents of data. > Assigned to AMC as suggested yesterday on-list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
