[jira] [Commented] (TS-1045) PATCH: add new TSFetchHdrGet API
[
https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164988#comment-13164988
]
James Peach commented on TS-1045:
-
Thanks Brian, I'll test that out and let you know.
AFAICT from gdb, TSFetchRespGet() returns the request body:
305 body = TSFetchRespGet(txn, &len);
(gdb)
306 if (body) {
(gdb)
307 debug_http("body %p is %d bytes", body, len);
[Dec 7 20:36:22.064] Server {0x7fff7b5f9960} DIAG: body 0x10115e800 is 288
bytes
(gdb) p body
$2 = 0x10115e800 "\n\n404 Not Found\n\nNot
Found\nThe requested URL /favicon.ico was not found on this
server.\n\n<"...
> PATCH: add new TSFetchHdrGet API
>
>
> Key: TS-1045
> URL: https://issues.apache.org/jira/browse/TS-1045
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
>Reporter: James Peach
>Priority: Minor
> Attachments: 0007-Add-new-public-API-TSFetchHdrGet.patch
>
>
> TSFetchUrl does not provide any way to get the headers from the result. This
> patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet()
> and returns the headers.
--
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-1045) PATCH: add new TSFetchHdrGet API
[
https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164974#comment-13164974
]
Brian Geffon commented on TS-1045:
--
You can get headers from a request sent via TSFetchURL using standard ATS APIs,
I do it all the time:
const char *dataStart = TSFetchRespGet(txn, &dataLen);
const char *dataEnd = dataStart + dataLen;
TSHttpParser parser = TSHttpParserCreate();
TSMBuffer buf = TSMBufferCreate();
TSMLoc hdrLoc = TSHttpHdrCreate(buf);
TSHttpHdrTypeSet(buf, hdrLoc, TS_HTTP_TYPE_RESPONSE);
if (TSHttpHdrParseResp(parser, buf, hdrLoc, &dataStart, dataEnd) ==
TS_PARSE_DONE)
{
// you can now access hdrLoc like any other TSMLoc to a header
}
> PATCH: add new TSFetchHdrGet API
>
>
> Key: TS-1045
> URL: https://issues.apache.org/jira/browse/TS-1045
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
>Reporter: James Peach
>Priority: Minor
> Attachments: 0007-Add-new-public-API-TSFetchHdrGet.patch
>
>
> TSFetchUrl does not provide any way to get the headers from the result. This
> patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet()
> and returns the headers.
--
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] [Issue Comment Edited] (TS-1045) PATCH: add new TSFetchHdrGet API
[
https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164974#comment-13164974
]
Brian Geffon edited comment on TS-1045 at 12/8/11 4:12 AM:
---
You can get headers from a request sent via TSFetchURL using standard ATS APIs
const char *dataStart = TSFetchRespGet(txn, &dataLen);
const char *dataEnd = dataStart + dataLen;
TSHttpParser parser = TSHttpParserCreate();
TSMBuffer buf = TSMBufferCreate();
TSMLoc hdrLoc = TSHttpHdrCreate(buf);
TSHttpHdrTypeSet(buf, hdrLoc, TS_HTTP_TYPE_RESPONSE);
if (TSHttpHdrParseResp(parser, buf, hdrLoc, &dataStart, dataEnd) ==
TS_PARSE_DONE)
{
// you can now access hdrLoc like any other TSMLoc to a header
}
was (Author: briang):
You can get headers from a request sent via TSFetchURL using standard ATS
APIs, I do it all the time:
const char *dataStart = TSFetchRespGet(txn, &dataLen);
const char *dataEnd = dataStart + dataLen;
TSHttpParser parser = TSHttpParserCreate();
TSMBuffer buf = TSMBufferCreate();
TSMLoc hdrLoc = TSHttpHdrCreate(buf);
TSHttpHdrTypeSet(buf, hdrLoc, TS_HTTP_TYPE_RESPONSE);
if (TSHttpHdrParseResp(parser, buf, hdrLoc, &dataStart, dataEnd) ==
TS_PARSE_DONE)
{
// you can now access hdrLoc like any other TSMLoc to a header
}
> PATCH: add new TSFetchHdrGet API
>
>
> Key: TS-1045
> URL: https://issues.apache.org/jira/browse/TS-1045
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
>Reporter: James Peach
>Priority: Minor
> Attachments: 0007-Add-new-public-API-TSFetchHdrGet.patch
>
>
> TSFetchUrl does not provide any way to get the headers from the result. This
> patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet()
> and returns the headers.
--
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-1045) PATCH: add new TSFetchHdrGet API
PATCH: add new TSFetchHdrGet API Key: TS-1045 URL: https://issues.apache.org/jira/browse/TS-1045 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: James Peach Priority: Minor Attachments: 0007-Add-new-public-API-TSFetchHdrGet.patch TSFetchUrl does not provide any way to get the headers from the result. This patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet() and returns the headers. -- 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-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1045: Attachment: 0007-Add-new-public-API-TSFetchHdrGet.patch > PATCH: add new TSFetchHdrGet API > > > Key: TS-1045 > URL: https://issues.apache.org/jira/browse/TS-1045 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: James Peach >Priority: Minor > Attachments: 0007-Add-new-public-API-TSFetchHdrGet.patch > > > TSFetchUrl does not provide any way to get the headers from the result. This > patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet() > and returns the headers. -- 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-1044) PATCH: Fix TSVConn{Read,Write}VIOGet in UnixNetVConnection.
[
https://issues.apache.org/jira/browse/TS-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1044:
Attachment: 0006-Fix-TSVConn-Read-Write-VIOGet-in-UnixNetVConnection.patch
> PATCH: Fix TSVConn{Read,Write}VIOGet in UnixNetVConnection.
> ---
>
> Key: TS-1044
> URL: https://issues.apache.org/jira/browse/TS-1044
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
> Attachments:
> 0006-Fix-TSVConn-Read-Write-VIOGet-in-UnixNetVConnection.patch
>
>
> UnixNetVConnection does not actually implement the virtual interface
> necessary to support the TSVConn{Read,Write}VIOGet() APIs. Even worse, the
> API layer assumes that this can't fail and proceeds to return a pointer to
> stack junk.
> This patch implements TSVConn{Read,Write}VIOGet() for UnixNetVConnection and
> allows the API to return NULL.
--
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-1044) PATCH: Fix TSVConn{Read,Write}VIOGet in UnixNetVConnection.
PATCH: Fix TSVConn{Read,Write}VIOGet in UnixNetVConnection.
---
Key: TS-1044
URL: https://issues.apache.org/jira/browse/TS-1044
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
UnixNetVConnection does not actually implement the virtual interface necessary
to support the TSVConn{Read,Write}VIOGet() APIs. Even worse, the API layer
assumes that this can't fail and proceeds to return a pointer to stack junk.
This patch implements TSVConn{Read,Write}VIOGet() for UnixNetVConnection and
allows the API to return NULL.
--
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-1043) PATCH: teach TSFetchUrl to use the content-length to find the after_body event
[ https://issues.apache.org/jira/browse/TS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1043: Attachment: 0005-TSFetchUrl-use-content-length-to-fire-after_body-eve.patch > PATCH: teach TSFetchUrl to use the content-length to find the after_body event > -- > > Key: TS-1043 > URL: https://issues.apache.org/jira/browse/TS-1043 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: James Peach > Attachments: > 0005-TSFetchUrl-use-content-length-to-fire-after_body-eve.patch > > > TSFetchUrl() does not fire the after_body event until the TCP connection is > closed. The fix is to check the content-length when we receive more bytes and > to fire the after_body event when all the byte are received. > This looks like https://issues.apache.org/jira/browse/TS-817 and possibly > https://issues.apache.org/jira/browse/TS-912 -- 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-1043) PATCH: teach TSFetchUrl to use the content-length to find the after_body event
PATCH: teach TSFetchUrl to use the content-length to find the after_body event -- Key: TS-1043 URL: https://issues.apache.org/jira/browse/TS-1043 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: James Peach Attachments: 0005-TSFetchUrl-use-content-length-to-fire-after_body-eve.patch TSFetchUrl() does not fire the after_body event until the TCP connection is closed. The fix is to check the content-length when we receive more bytes and to fire the after_body event when all the byte are received. This looks like https://issues.apache.org/jira/browse/TS-817 and possibly https://issues.apache.org/jira/browse/TS-912 -- 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-1042) PATCH: correct debug message in FetchSM
[ https://issues.apache.org/jira/browse/TS-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1042: Attachment: 0004-Fix-FetchSM-debugging-message.patch > PATCH: correct debug message in FetchSM > --- > > Key: TS-1042 > URL: https://issues.apache.org/jira/browse/TS-1042 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: James Peach >Priority: Minor > Attachments: 0004-Fix-FetchSM-debugging-message.patch > > > In the FetchSM module, there is a debug message that can walk off the end of > the buffer. This patch corrects that by limiting the printed string to the > known length. -- 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-1042) PATCH: correct debug message in FetchSM
PATCH: correct debug message in FetchSM --- Key: TS-1042 URL: https://issues.apache.org/jira/browse/TS-1042 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: James Peach Priority: Minor In the FetchSM module, there is a debug message that can walk off the end of the buffer. This patch corrects that by limiting the printed string to the known length. -- 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-1041) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet
[ https://issues.apache.org/jira/browse/TS-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1041: Attachment: 0003-Ensure-sockaddr-length-is-always-populated.patch > PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet > -- > > Key: TS-1041 > URL: https://issues.apache.org/jira/browse/TS-1041 > Project: Traffic Server > Issue Type: Improvement > Components: DNS > Environment: Mac OS X 10.7 >Reporter: James Peach >Priority: Minor > Attachments: 0003-Ensure-sockaddr-length-is-always-populated.patch > > > The sockaddr returned by TSHostLookupResultAddrGet() does not always get it's > sa_len field populated correctly. This patch guarantees to populate it to the > correct value so that plugin authors can rely on that field when copying the > TSHostLookupResultAddrGet() result. -- 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-1041) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet
PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet -- Key: TS-1041 URL: https://issues.apache.org/jira/browse/TS-1041 Project: Traffic Server Issue Type: Improvement Components: DNS Environment: Mac OS X 10.7 Reporter: James Peach Priority: Minor Attachments: 0003-Ensure-sockaddr-length-is-always-populated.patch The sockaddr returned by TSHostLookupResultAddrGet() does not always get it's sa_len field populated correctly. This patch guarantees to populate it to the correct value so that plugin authors can rely on that field when copying the TSHostLookupResultAddrGet() result. -- 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-1040) PATCH: teach TSHostLookup to use const
[ https://issues.apache.org/jira/browse/TS-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1040: Attachment: 0002-TSHostLookup-should-take-const-hostname-argument.patch > PATCH: teach TSHostLookup to use const > -- > > Key: TS-1040 > URL: https://issues.apache.org/jira/browse/TS-1040 > Project: Traffic Server > Issue Type: Improvement > Components: DNS >Reporter: James Peach >Priority: Minor > Attachments: > 0002-TSHostLookup-should-take-const-hostname-argument.patch > > > This patch improves the TSHostLookup() API by specifying it's hostname > argument as const. This reduces the number of casts required of plugin > authors. > The new prototype is: > tsapi TSAction TSHostLookup(TSCont contp, const char* hostname, size_t > namelen) -- 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-1040) PATCH: teach TSHostLookup to use const
PATCH: teach TSHostLookup to use const -- Key: TS-1040 URL: https://issues.apache.org/jira/browse/TS-1040 Project: Traffic Server Issue Type: Improvement Components: DNS Reporter: James Peach Priority: Minor This patch improves the TSHostLookup() API by specifying it's hostname argument as const. This reduces the number of casts required of plugin authors. The new prototype is: tsapi TSAction TSHostLookup(TSCont contp, const char* hostname, size_t namelen) -- 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-1039) PATCH: use pcre-config to find libpcre
[ https://issues.apache.org/jira/browse/TS-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1039: Attachment: 0001-Use-pcre-config-to-find-libpcre.patch > PATCH: use pcre-config to find libpcre > -- > > Key: TS-1039 > URL: https://issues.apache.org/jira/browse/TS-1039 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: James Peach >Priority: Minor > Attachments: 0001-Use-pcre-config-to-find-libpcre.patch > > > This patch uses pcre-config to determine the compilation options needed to > use libpcre. This is an improvement over the exiting configure arguments > since it will work without user intervention in more circumstances. The > existing configuration option still works as expected for compatibility > reasons. -- 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-1039) PATCH: use pcre-config to find libpcre
PATCH: use pcre-config to find libpcre -- Key: TS-1039 URL: https://issues.apache.org/jira/browse/TS-1039 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: James Peach Priority: Minor Attachments: 0001-Use-pcre-config-to-find-libpcre.patch This patch uses pcre-config to determine the compilation options needed to use libpcre. This is an improvement over the exiting configure arguments since it will work without user intervention in more circumstances. The existing configuration option still works as expected for compatibility reasons. -- 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-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)
[ https://issues.apache.org/jira/browse/TS-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164927#comment-13164927 ] William Bardwell commented on TS-1038: -- Good catch, although I would note that currently the internal uses of the internal_msg_buffer* fields do not set the type, so this is a bit less serious. > TSHttpTxnErrorBodySet() can leak memory (pt 2) > -- > > Key: TS-1038 > URL: https://issues.apache.org/jira/browse/TS-1038 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Brian Geffon > Attachments: TSHttpTxnErrorBodySet.patch > > > TS-826 resolved a memory leak with TSHttpTxnErrorBodySet but it appears that > mimetype is still being leaked. See HttpSM::setup_internal_transfer line 5416 > which frees internal_msg_buffer_type...it's expected that mimetype was > malloced since clearly it's being freed. So that means there is still a > memory leak in TSHttpTxnErrorBodySet(). > Patch included. -- 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-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Geffon updated TS-937:
Comment: was deleted
(was: FYI, apparently this patch was included in 3.0.2 but there was no
reference in the change log that could get confusing down the road.)
> EThread::execute still processing cancelled event
> -
>
> Key: TS-937
> URL: https://issues.apache.org/jira/browse/TS-937
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.1, 2.1.9
> Environment: RHEL6
>Reporter: Brian Geffon
> Fix For: 3.1.2
>
> Attachments: UnixEThread.patch
>
>
> The included GDB log will show that ATS is trying to process an event that
> has already been canceled, examining the code of UnixEThread.cc line 232
> shows that EThread::process_event gets called without a check for the event
> being cancelled.
> Brian
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x764fa700 (LWP 28518)]
> 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> 130 MUTEX_TRY_LOCK_FOR(lock, e->mutex.m_ptr, this, e->continuation);
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64
> keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.1.x86_64
> libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64
> libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64
> openssl-1.0.0-10.el6_1.4.x86_64 pcre-7.8-3.1.el6.x86_64
> tcl-8.5.7-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64
> (gdb) bt
> #0 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> #1 0x006fcbaf in EThread::execute (this=0x768ff010) at
> UnixEThread.cc:232
> #2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
> #3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
> #4 0x00361f8e577d in clone () from /lib64/libc.so.6
> (gdb) bt full
> #0 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> lock = {m = {m_ptr = 0x764f9d20}, lock_acquired = 202}
> #1 0x006fcbaf in EThread::execute (this=0x768ff010) at
> UnixEThread.cc:232
> done_one = false
> e = 0x1db45c0
> NegativeQueue = {> = {head = 0xfc75f0},
> tail = 0xfc75f0}
> next_time = 1314647904419648000
> #2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
> p = 0xfb7e80
> #3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
> No symbol table info available.
> #4 0x00361f8e577d in clone () from /lib64/libc.so.6
> No symbol table info available.
> (gdb) f 0
> #0 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> 130 MUTEX_TRY_LOCK_FOR(lock, e->mutex.m_ptr, this, e->continuation);
> (gdb) p *e
> $2 = { = {_vptr.Action = 0x775170, continuation = 0x1f2fc08, mutex =
> {m_ptr = 0x7fffd40fba40}, cancelled = 1}, ethread = 0x768ff010,
> in_the_prot_queue = 0, in_the_priority_queue = 0,
> immediate = 1, globally_allocated = 1, in_heap = 0, callback_event = 1,
> timeout_at = 0, period = 0, cookie = 0x0, link = {> = {next =
> 0x0}, prev = 0x0}}
--
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-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164911#comment-13164911
]
Brian Geffon commented on TS-937:
-
Ignore notifications about a comment talking about inclusion in 3.0.2, I was
mistaken.
> EThread::execute still processing cancelled event
> -
>
> Key: TS-937
> URL: https://issues.apache.org/jira/browse/TS-937
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.1, 2.1.9
> Environment: RHEL6
>Reporter: Brian Geffon
> Fix For: 3.1.2
>
> Attachments: UnixEThread.patch
>
>
> The included GDB log will show that ATS is trying to process an event that
> has already been canceled, examining the code of UnixEThread.cc line 232
> shows that EThread::process_event gets called without a check for the event
> being cancelled.
> Brian
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x764fa700 (LWP 28518)]
> 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> 130 MUTEX_TRY_LOCK_FOR(lock, e->mutex.m_ptr, this, e->continuation);
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64
> keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.1.x86_64
> libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64
> libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64
> openssl-1.0.0-10.el6_1.4.x86_64 pcre-7.8-3.1.el6.x86_64
> tcl-8.5.7-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64
> (gdb) bt
> #0 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> #1 0x006fcbaf in EThread::execute (this=0x768ff010) at
> UnixEThread.cc:232
> #2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
> #3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
> #4 0x00361f8e577d in clone () from /lib64/libc.so.6
> (gdb) bt full
> #0 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> lock = {m = {m_ptr = 0x764f9d20}, lock_acquired = 202}
> #1 0x006fcbaf in EThread::execute (this=0x768ff010) at
> UnixEThread.cc:232
> done_one = false
> e = 0x1db45c0
> NegativeQueue = {> = {head = 0xfc75f0},
> tail = 0xfc75f0}
> next_time = 1314647904419648000
> #2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
> p = 0xfb7e80
> #3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
> No symbol table info available.
> #4 0x00361f8e577d in clone () from /lib64/libc.so.6
> No symbol table info available.
> (gdb) f 0
> #0 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> 130 MUTEX_TRY_LOCK_FOR(lock, e->mutex.m_ptr, this, e->continuation);
> (gdb) p *e
> $2 = { = {_vptr.Action = 0x775170, continuation = 0x1f2fc08, mutex =
> {m_ptr = 0x7fffd40fba40}, cancelled = 1}, ethread = 0x768ff010,
> in_the_prot_queue = 0, in_the_priority_queue = 0,
> immediate = 1, globally_allocated = 1, in_heap = 0, callback_event = 1,
> timeout_at = 0, period = 0, cookie = 0x0, link = {> = {next =
> 0x0}, prev = 0x0}}
--
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-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164858#comment-13164858
]
Brian Geffon commented on TS-937:
-
FYI, apparently this patch was included in 3.0.2 but there was no reference in
the change log that could get confusing down the road.
> EThread::execute still processing cancelled event
> -
>
> Key: TS-937
> URL: https://issues.apache.org/jira/browse/TS-937
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.1, 2.1.9
> Environment: RHEL6
>Reporter: Brian Geffon
> Fix For: 3.1.2
>
> Attachments: UnixEThread.patch
>
>
> The included GDB log will show that ATS is trying to process an event that
> has already been canceled, examining the code of UnixEThread.cc line 232
> shows that EThread::process_event gets called without a check for the event
> being cancelled.
> Brian
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x764fa700 (LWP 28518)]
> 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> 130 MUTEX_TRY_LOCK_FOR(lock, e->mutex.m_ptr, this, e->continuation);
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64
> keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.1.x86_64
> libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64
> libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64
> openssl-1.0.0-10.el6_1.4.x86_64 pcre-7.8-3.1.el6.x86_64
> tcl-8.5.7-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64
> (gdb) bt
> #0 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> #1 0x006fcbaf in EThread::execute (this=0x768ff010) at
> UnixEThread.cc:232
> #2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
> #3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
> #4 0x00361f8e577d in clone () from /lib64/libc.so.6
> (gdb) bt full
> #0 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> lock = {m = {m_ptr = 0x764f9d20}, lock_acquired = 202}
> #1 0x006fcbaf in EThread::execute (this=0x768ff010) at
> UnixEThread.cc:232
> done_one = false
> e = 0x1db45c0
> NegativeQueue = {> = {head = 0xfc75f0},
> tail = 0xfc75f0}
> next_time = 1314647904419648000
> #2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
> p = 0xfb7e80
> #3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
> No symbol table info available.
> #4 0x00361f8e577d in clone () from /lib64/libc.so.6
> No symbol table info available.
> (gdb) f 0
> #0 0x006fc663 in EThread::process_event (this=0x768ff010,
> e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
> 130 MUTEX_TRY_LOCK_FOR(lock, e->mutex.m_ptr, this, e->continuation);
> (gdb) p *e
> $2 = { = {_vptr.Action = 0x775170, continuation = 0x1f2fc08, mutex =
> {m_ptr = 0x7fffd40fba40}, cancelled = 1}, ethread = 0x768ff010,
> in_the_prot_queue = 0, in_the_priority_queue = 0,
> immediate = 1, globally_allocated = 1, in_heap = 0, callback_event = 1,
> timeout_at = 0, period = 0, cookie = 0x0, link = {> = {next =
> 0x0}, prev = 0x0}}
--
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-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)
[ https://issues.apache.org/jira/browse/TS-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1038: - Attachment: TSHttpTxnErrorBodySet.patch > TSHttpTxnErrorBodySet() can leak memory (pt 2) > -- > > Key: TS-1038 > URL: https://issues.apache.org/jira/browse/TS-1038 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Brian Geffon > Attachments: TSHttpTxnErrorBodySet.patch > > > TS-826 resolved a memory leak with TSHttpTxnErrorBodySet but it appears that > mimetype is still being leaked. See HttpSM::setup_internal_transfer line 5416 > which frees internal_msg_buffer_type...it's expected that mimetype was > malloced since clearly it's being freed. So that means there is still a > memory leak in TSHttpTxnErrorBodySet(). > Patch included. -- 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-826) TSHttpTxnErrorBodySet() can leak memory
[ https://issues.apache.org/jira/browse/TS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164747#comment-13164747 ] Brian Geffon commented on TS-826: - Opened bug https://issues.apache.org/jira/browse/TS-1038 > TSHttpTxnErrorBodySet() can leak memory > --- > > Key: TS-826 > URL: https://issues.apache.org/jira/browse/TS-826 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 >Reporter: William Bardwell >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.0, 3.0.1 > > Attachments: ebs.diff > > > TSHttpTxnErrorBodySet() sets HttpSM::t_state.internal_msg_buffer without > freeing any old contents in there. > There can be an error message in that if you have a request with a bad > hostname and you let the transaction get past DNS > lookup. Instead it should free the contents, or there should be another > field that it sets and nothing else does. -- 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-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)
TSHttpTxnErrorBodySet() can leak memory (pt 2) -- Key: TS-1038 URL: https://issues.apache.org/jira/browse/TS-1038 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.1 Reporter: Brian Geffon TS-826 resolved a memory leak with TSHttpTxnErrorBodySet but it appears that mimetype is still being leaked. See HttpSM::setup_internal_transfer line 5416 which frees internal_msg_buffer_type...it's expected that mimetype was malloced since clearly it's being freed. So that means there is still a memory leak in TSHttpTxnErrorBodySet(). Patch included. -- 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] [Issue Comment Edited] (TS-826) TSHttpTxnErrorBodySet() can leak memory
[ https://issues.apache.org/jira/browse/TS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164734#comment-13164734 ] Brian Geffon edited comment on TS-826 at 12/7/11 9:42 PM: -- Correct me if I'm wrong but with this patch it's still leaking mimetype. See HttpSM::setup_internal_transfer line 5416 which frees internal_msg_buffer_type...it's expected that mimetype was malloced since clearly it's being freed. So that means there is still a memory leak in TSHttpTxnErrorBodySet(). was (Author: briang): Correct me if I'm wrong but with this patch it's still leaking mimetype... > TSHttpTxnErrorBodySet() can leak memory > --- > > Key: TS-826 > URL: https://issues.apache.org/jira/browse/TS-826 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 >Reporter: William Bardwell >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.0, 3.0.1 > > Attachments: ebs.diff > > > TSHttpTxnErrorBodySet() sets HttpSM::t_state.internal_msg_buffer without > freeing any old contents in there. > There can be an error message in that if you have a request with a bad > hostname and you let the transaction get past DNS > lookup. Instead it should free the contents, or there should be another > field that it sets and nothing else does. -- 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-826) TSHttpTxnErrorBodySet() can leak memory
[ https://issues.apache.org/jira/browse/TS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164734#comment-13164734 ] Brian Geffon commented on TS-826: - Correct me if I'm wrong but with this patch it's still leaking mimetype... > TSHttpTxnErrorBodySet() can leak memory > --- > > Key: TS-826 > URL: https://issues.apache.org/jira/browse/TS-826 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 >Reporter: William Bardwell >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.0, 3.0.1 > > Attachments: ebs.diff > > > TSHttpTxnErrorBodySet() sets HttpSM::t_state.internal_msg_buffer without > freeing any old contents in there. > There can be an error message in that if you have a request with a bad > hostname and you let the transaction get past DNS > lookup. Instead it should free the contents, or there should be another > field that it sets and nothing else does. -- 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-949) key->volume hash table is not consistent when a disk is marked as bad or removed due to failure
[
https://issues.apache.org/jira/browse/TS-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164579#comment-13164579
]
John Plevyak commented on TS-949:
-
I admit I haven't looked at this code in a long time, but isn't the vol->len
the length of the volume? What we want is a hash function H(h) which
distributes the key proportional to the size of the volumes. Let's say we have
disk A: 1TB disk B: 200GB and disk C: 500GB. With your changes they would all
get he same number of keys, so that disk B would quickly fill up and start to
loose documents while disk A was still mostly empty.
In order to handle this, the random numbers need to be scaled down so that they
allocate the right proportions. This will not cause the earlier problem
because it preserves the pairwise order between any two disks, that is if B
drops but A and C are still present and A won the first time it will win again
(because the random values will be scale with the same proportion and if x > y
then x * C > y * C for all 0 <= C).
That said, the proportionality multiplier I was using wasn't right. I'll send
out a new patch with the right multiplier. Size needs to be
proportional to (total*total)/size rather than just size.
Thanx for the feedback, please check out the new patch and let's work out some
examples to make sure it does what we want.
The new multiplier should allocate proportional to the size of each vol and not
have any inconsistencies.
> key->volume hash table is not consistent when a disk is marked as bad or
> removed due to failure
> ---
>
> Key: TS-949
> URL: https://issues.apache.org/jira/browse/TS-949
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 3.1.0
> Environment: Multi-volume cache with apparently faulty drives
>Reporter: B Wyatt
>Assignee: John Plevyak
> Fix For: 3.1.2
>
> Attachments: TS-949-jp-1.patch, TS949-BW-p1.patch
>
>
> The method for resolving collisions when distributing hash-table space to
> volumes for the object_key->volume hash table creates inconsistency when a
> disk is determined to be bad, or when a failed disk is removed from the
> volume.config.
> Background:
> The hash space is distributed by round robin draft where each volume "drafts"
> a random index in the hash table until the hash space is exhausted. The
> random order in which a given volume drafts hash table slots is consistent
> across reboot/crash/disk-failure, however when a volume attempts to draft a
> slot which has already been occupied, it skips to its next random pick and
> attempts to draft that slot until it finds an open slot. This ensures that
> the hash is partitioned evenly between volumes.
> The issue:
> Resolving slot contention breaks the consistency as it is dependent on the
> order that the volumes draft. When rebuilding the hash after disk failure or
> reboot with fewer drives, a volume may secure an index that was previously
> occupied by the dead-disk. In the old hash, the surviving volume would have
> selected another random index due to contention. If this index is taken, by
> the next draft round it will represent an inconsistent key->volume result.
> The effects of one inconsistency will then cascade as whichever volume
> occupies that index after removing a dead disk is now behind on its draft
> sequence as well.
> An Example:
> ||Disk||Draft Sequence||
> |A|1,4,7,5|
> |B|4,2,8,1|
> |C|3,7,5,2|
> Pre-failure Hash Table after 2 rounds of draft:
> |A|B|C|B|C|?|A|?|
> Post-failure of drive B Hash Table after 3 rounds of draft:
> |A|C|C|A|{color:red}A{color}|?|{color:red}C{color}|?|
> Two slots have become inconsistent and more will probably follow. These
> inconsistencies become objects stored in a volume but lost to the top level
> cache for open/lookup.
--
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
