date:20120202


 [ 
https://issues.apache.org/jira/browse/TS-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić updated TS-1038:
---

Backport to Version:   (was: 3.0.3)

> 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
>Assignee: Igor Galić
> Fix For: 3.1.2, 3.0.3
>
> 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] [Resolved] (TS-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)

2012-02-02 Thread Resolved


 [ 
https://issues.apache.org/jira/browse/TS-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić resolved TS-1038.


   Resolution: Fixed
Fix Version/s: 3.0.3

> 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
>Assignee: Igor Galić
> Fix For: 3.1.2, 3.0.3
>
> 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] [Assigned] (TS-1095) 3.0.x ts.h.in has incorrect declaration for TSFetchURL


 [ 
https://issues.apache.org/jira/browse/TS-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reassigned TS-1095:
--

Assignee: Igor Galić  (was: Brian Geffon)

> 3.0.x ts.h.in has incorrect declaration for TSFetchURL
> --
>
> Key: TS-1095
> URL: https://issues.apache.org/jira/browse/TS-1095
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 3.0.2
>Reporter: Brian Geffon
>Assignee: Igor Galić
> Fix For: 3.0.3
>
> Attachments: ts.h.in.patch
>
>
> If you look at the declaration in ts.h.in for TSFetchURL it doesn't match the 
> definition in InkAPI.cc.
> Patch attached, and updating STATUS file.

--
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] [Reopened] (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
 ]

Igor Galić reopened TS-1038:



reopen for backport

> 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
>Assignee: Igor Galić
> Fix For: 3.1.2
>
> 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] [Assigned] (TS-876) forward map based on request receive port


 [ 
https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reassigned TS-876:
-

Assignee: Igor Galić  (was: Brian Geffon)

> forward map based on request receive port
> -
>
> Key: TS-876
> URL: https://issues.apache.org/jira/browse/TS-876
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Remap API
>Reporter: Manjesh Nilange
>Assignee: Igor Galić
> Fix For: 3.1.0
>
> Attachments: TS876.fixed.patch, map_with_recv_port.patch
>
>
> Currently the port in the "from" fields of all remap rules are compared 
> against the port in the request (explicitly in the request or implicitly 
> deduced from the protocol). TS supports listening on multiple ports, so there 
> is a use case for a remap rule that uses the TS port at which the request is 
> received instead of the "request port".

--
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] [Reopened] (TS-1049) TS hangs (dead lock) on HTTPS POST requests


 [ 
https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reopened TS-1049:



reopen for backport

> TS hangs (dead lock) on HTTPS POST requests
> ---
>
> Key: TS-1049
> URL: https://issues.apache.org/jira/browse/TS-1049
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP, SSL
>Affects Versions: 3.1.1, 3.1.0, 3.0.2
> Environment: RedHat Enterprise Linux 6.0, Intel 32-bit
>Reporter: Wilson Ho
>Assignee: Igor Galić
>Priority: Blocker
> Fix For: 3.1.2
>
> Attachments: records.config
>
>
> A very reproducible bug where the body of a HTTPS POST request is never 
> forwarded to the origin server.
> Client submits a HTTPS POST request to TS, which is supposed to forward to 
> the backend/origin server via HTTP.  TS process the HTTP headers and 
> establishes connection to the origin server, but the body of the HTTPS POST 
> is never read.  This hangs until the client times out and shuts down the 
> connection.
> To reproduce:
> # Client connects to TS using HTTPS (works OK if it is just HTTP).
> # It must be a POST request.
> # TS must use at least 2 worker threads.
> # Easier to reproduce when the connections to the origin server is HTTP (not 
> HTTPS).
> # POST body must be large enough so that the HTTP request headers and POST 
> body do *NOT* fit within the same TCP packet. (2000 bytes is a good size)
> # I can consistently reproduce this problem using 2 separate clients each 
> simultaneously submitting 2 requests back to back (i.e., 2 requests from each 
> client, a total of 4 requests).  This gives you a high probability that at 
> least one of the requests would hang.
> Observation:
> # Thread A accepted and processed the HTTP headers, and called 
> "UnixNetProcessor::connect_re" to prepare a new connection to the origin 
> server.
> # Thread A must not have read the body of the POST.  Otherwise, it works fine.
> # Thread B was assigned the task to handle the origin server connection.  If 
> the same thread A was picked, then everything works fine.
> # Apparently, one of the first things that thread B does is to acquire the 
> mutex for reading from the client.  (Why does it do that??)
> # While thread B was holding the mutex, thread A proceeded in 
> "SSLNetVConnection::net_read_io", tried and failed to acquire the mutex.  
> Thread A typically re-tried calling "SSLNetVConnection::net_read_io" soon, 
> but gave up after the second failure. But if thread B released the mutex soon 
> enough, that thread A could proceed happily and everything works.
> # From this point, the body of the POST is never read from the client, and 
> there is nothing to be proxy'd to the origin server, and both the consumer 
> and producer tasks are never scheduled to run again -- or until the client 
> times out.  I tried setting the client-side time out to as long as 3-5 
> minutes and TS really does not recover by itself until the client closed the 
> connection.
> This is the first time I uses this bug system.  Please let me know how I 
> could produce the configuration files and trace logs, etc.  Thanks!

--
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] [Reopened] (TS-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed a


 [ 
https://issues.apache.org/jira/browse/TS-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reopened TS-1061:



reopen for backport

> TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter 
> (int *bytes) from the prototype in ./proxy/api/ts/ts.h.  The extra parameter 
> needs to be removed as it is not used.
> -
>
> Key: TS-1061
> URL: https://issues.apache.org/jira/browse/TS-1061
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 3.1.1, 3.0.1
> Environment: Redhat Linux but it is not environment specific
>Reporter: Alistair Stevenson
>Assignee: Igor Galić
>Priority: Minor
>  Labels: api-change
> Fix For: 3.1.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The definitions are:
> ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes)
> ./proxy/api/ts/ts.h.in:  tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn 
> txnp);
> The "int * bytes" parameter is not used and means that the function does not 
> resolve and so cannot be used.

--
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] [Reopened] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.


 [ 
https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reopened TS-1074:



reopen for backport

> PluginVC should schedule to the local queue instead of the external queue.
> --
>
> Key: TS-1074
> URL: https://issues.apache.org/jira/browse/TS-1074
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.0.1
>Reporter: Brian Geffon
>Assignee: Igor Galić
> Fix For: 3.1.2
>
> Attachments: PluginVC.patch
>
>
> In TS-867 a patch was introduced to resolve a crash that was appearing w/ 
> TSFetchURL, the patch would schedule events on the same thread if it is a net 
> thread, if not it will only then schedule with the event processor. If you're 
> scheduling on the same thread, wouldn't it be more efficient to place the 
> event directly on the local queue? It turns out that going to the 
> ExternalQueue under low load it would cause the event to become delayed. 
> Patch Attached.
> To best see the symptoms see complaints in (TS-912 and TS-1043). 
> I have verified that this patch fixes the 10ms symptom seen in TS-912 and 
> TS-1043.

--
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] [Assigned] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.


 [ 
https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reassigned TS-1074:
--

Assignee: Igor Galić  (was: Brian Geffon)

> PluginVC should schedule to the local queue instead of the external queue.
> --
>
> Key: TS-1074
> URL: https://issues.apache.org/jira/browse/TS-1074
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.0.1
>Reporter: Brian Geffon
>Assignee: Igor Galić
> Fix For: 3.1.2
>
> Attachments: PluginVC.patch
>
>
> In TS-867 a patch was introduced to resolve a crash that was appearing w/ 
> TSFetchURL, the patch would schedule events on the same thread if it is a net 
> thread, if not it will only then schedule with the event processor. If you're 
> scheduling on the same thread, wouldn't it be more efficient to place the 
> event directly on the local queue? It turns out that going to the 
> ExternalQueue under low load it would cause the event to become delayed. 
> Patch Attached.
> To best see the symptoms see complaints in (TS-912 and TS-1043). 
> I have verified that this patch fixes the 10ms symptom seen in TS-912 and 
> TS-1043.

--
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] [Assigned] (TS-1004) transformation plugins cause connection close when content length is not known ahead


 [ 
https://issues.apache.org/jira/browse/TS-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reassigned TS-1004:
--

Assignee: Igor Galić  (was: Brian Geffon)

> transformation plugins cause connection close when content length is not 
> known ahead
> 
>
> Key: TS-1004
> URL: https://issues.apache.org/jira/browse/TS-1004
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Plugins
>Affects Versions: 3.0.1
>Reporter: Otto van der Schaaf
>Assignee: Igor Galić
> Fix For: 3.1.1
>
> Attachments: chunk_transform_response.diff
>
>
> whenever the null transform plugin (or gzip) is executed, ATS will force the 
> ua connection closed. 
> when the user agent supports it, sending a chunked response w/ keepalive 
> enabled would be preferred i guess
> i'll add a patch for review.

--
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] [Assigned] (TS-1049) TS hangs (dead lock) on HTTPS POST requests


 [ 
https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reassigned TS-1049:
--

Assignee: Igor Galić  (was: Leif Hedstrom)

> TS hangs (dead lock) on HTTPS POST requests
> ---
>
> Key: TS-1049
> URL: https://issues.apache.org/jira/browse/TS-1049
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP, SSL
>Affects Versions: 3.1.1, 3.1.0, 3.0.2
> Environment: RedHat Enterprise Linux 6.0, Intel 32-bit
>Reporter: Wilson Ho
>Assignee: Igor Galić
>Priority: Blocker
> Fix For: 3.1.2
>
> Attachments: records.config
>
>
> A very reproducible bug where the body of a HTTPS POST request is never 
> forwarded to the origin server.
> Client submits a HTTPS POST request to TS, which is supposed to forward to 
> the backend/origin server via HTTP.  TS process the HTTP headers and 
> establishes connection to the origin server, but the body of the HTTPS POST 
> is never read.  This hangs until the client times out and shuts down the 
> connection.
> To reproduce:
> # Client connects to TS using HTTPS (works OK if it is just HTTP).
> # It must be a POST request.
> # TS must use at least 2 worker threads.
> # Easier to reproduce when the connections to the origin server is HTTP (not 
> HTTPS).
> # POST body must be large enough so that the HTTP request headers and POST 
> body do *NOT* fit within the same TCP packet. (2000 bytes is a good size)
> # I can consistently reproduce this problem using 2 separate clients each 
> simultaneously submitting 2 requests back to back (i.e., 2 requests from each 
> client, a total of 4 requests).  This gives you a high probability that at 
> least one of the requests would hang.
> Observation:
> # Thread A accepted and processed the HTTP headers, and called 
> "UnixNetProcessor::connect_re" to prepare a new connection to the origin 
> server.
> # Thread A must not have read the body of the POST.  Otherwise, it works fine.
> # Thread B was assigned the task to handle the origin server connection.  If 
> the same thread A was picked, then everything works fine.
> # Apparently, one of the first things that thread B does is to acquire the 
> mutex for reading from the client.  (Why does it do that??)
> # While thread B was holding the mutex, thread A proceeded in 
> "SSLNetVConnection::net_read_io", tried and failed to acquire the mutex.  
> Thread A typically re-tried calling "SSLNetVConnection::net_read_io" soon, 
> but gave up after the second failure. But if thread B released the mutex soon 
> enough, that thread A could proceed happily and everything works.
> # From this point, the body of the POST is never read from the client, and 
> there is nothing to be proxy'd to the origin server, and both the consumer 
> and producer tasks are never scheduled to run again -- or until the client 
> times out.  I tried setting the client-side time out to as long as 3-5 
> minutes and TS really does not recover by itself until the client closed the 
> connection.
> This is the first time I uses this bug system.  Please let me know how I 
> could produce the configuration files and trace logs, etc.  Thanks!

--
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] [Reopened] (TS-1065) traffic_cop segment fault when enable TRACE_LOG_COP


 [ 
https://issues.apache.org/jira/browse/TS-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reopened TS-1065:



reopen for backport

> traffic_cop segment fault when enable TRACE_LOG_COP
> ---
>
> Key: TS-1065
> URL: https://issues.apache.org/jira/browse/TS-1065
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 3.1.1, 3.0.2
> Environment: mac os 10.7.2, centos 5.4 64bit
>Reporter: Conan Wang
>Assignee: Igor Galić
>Priority: Minor
> Fix For: 3.1.2
>
> Attachments: traffic_cop.diff
>
>
> When enable traffic_cop's debug log:  #define TRACE_LOG_COP 1 
> Some cop_log invocation will cause segment fault, because va_list object in 
> cop_log is used twice between 'va_start' and 'va_end'.
> {code}
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x
> 0x7fff846b64f0 in strlen ()
> (gdb) bt
> #0  0x7fff846b64f0 in strlen ()
> #1  0x7fff846578c3 in __vfprintf ()
> #2  0x7fff846a109b in vsprintf_l ()
> #3  0x00011883 in cop_log (priority=5, format=0x172a8 "--- Cop 
> Starting [Version: %s] ---\n") at TrafficCop.cc:172
> #4  0x00012244 in check_lockfile () at TrafficCop.cc:1733
> #5  0x000122c0 in init () at TrafficCop.cc:1894
> #6  0x00016689 in main (argc=1, argv=0x7fff5fbffbb0) at 
> TrafficCop.cc:1958
> {code}
> Reference:
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.html

--
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-1055) Wrong implementation of TSHttpSsnArgGet


 [ 
https://issues.apache.org/jira/browse/TS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić updated TS-1055:
---

Backport to Version: 3.0.3

> Wrong implementation of TSHttpSsnArgGet
> ---
>
> Key: TS-1055
> URL: https://issues.apache.org/jira/browse/TS-1055
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Affects Versions: 3.1.1
>Reporter: Yakov Kopel
>Assignee: Leif Hedstrom
>  Labels: api-change
> Fix For: 3.1.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> There is a different between the interface of TSHttpSsnArgGet and it 
> implemenation.
> In the interface (proxy/api/ts/ts.h.in):
>  tsapi void* TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx);
> In the implementation(proxy/InkAPI.cc):
>   void * TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
> So, I wrote a simple patch to fix this problem:
> Index: InkAPI.cc
> ===
> --- InkAPI.cc   (revision 1220421)
> +++ InkAPI.cc   (working copy)
> @@ -5500,7 +5500,7 @@
>  }
>  void *
> -TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
> +TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx)
>  {
>sdk_assert(sdk_sanity_check_http_ssn(ssnp) == TS_SUCCESS);
>sdk_assert(arg_idx >= 0 && arg_idx < HTTP_SSN_TXN_MAX_USER_ARG);

--
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] [Assigned] (TS-1055) Wrong implementation of TSHttpSsnArgGet


 [ 
https://issues.apache.org/jira/browse/TS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reassigned TS-1055:
--

Assignee: Igor Galić  (was: Leif Hedstrom)

> Wrong implementation of TSHttpSsnArgGet
> ---
>
> Key: TS-1055
> URL: https://issues.apache.org/jira/browse/TS-1055
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Affects Versions: 3.1.1
>Reporter: Yakov Kopel
>Assignee: Igor Galić
>  Labels: api-change
> Fix For: 3.1.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> There is a different between the interface of TSHttpSsnArgGet and it 
> implemenation.
> In the interface (proxy/api/ts/ts.h.in):
>  tsapi void* TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx);
> In the implementation(proxy/InkAPI.cc):
>   void * TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
> So, I wrote a simple patch to fix this problem:
> Index: InkAPI.cc
> ===
> --- InkAPI.cc   (revision 1220421)
> +++ InkAPI.cc   (working copy)
> @@ -5500,7 +5500,7 @@
>  }
>  void *
> -TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
> +TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx)
>  {
>sdk_assert(sdk_sanity_check_http_ssn(ssnp) == TS_SUCCESS);
>sdk_assert(arg_idx >= 0 && arg_idx < HTTP_SSN_TXN_MAX_USER_ARG);

--
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] [Assigned] (TS-1065) traffic_cop segment fault when enable TRACE_LOG_COP


 [ 
https://issues.apache.org/jira/browse/TS-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reassigned TS-1065:
--

Assignee: Igor Galić  (was: Leif Hedstrom)

> traffic_cop segment fault when enable TRACE_LOG_COP
> ---
>
> Key: TS-1065
> URL: https://issues.apache.org/jira/browse/TS-1065
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 3.1.1, 3.0.2
> Environment: mac os 10.7.2, centos 5.4 64bit
>Reporter: Conan Wang
>Assignee: Igor Galić
>Priority: Minor
> Fix For: 3.1.2
>
> Attachments: traffic_cop.diff
>
>
> When enable traffic_cop's debug log:  #define TRACE_LOG_COP 1 
> Some cop_log invocation will cause segment fault, because va_list object in 
> cop_log is used twice between 'va_start' and 'va_end'.
> {code}
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x
> 0x7fff846b64f0 in strlen ()
> (gdb) bt
> #0  0x7fff846b64f0 in strlen ()
> #1  0x7fff846578c3 in __vfprintf ()
> #2  0x7fff846a109b in vsprintf_l ()
> #3  0x00011883 in cop_log (priority=5, format=0x172a8 "--- Cop 
> Starting [Version: %s] ---\n") at TrafficCop.cc:172
> #4  0x00012244 in check_lockfile () at TrafficCop.cc:1733
> #5  0x000122c0 in init () at TrafficCop.cc:1894
> #6  0x00016689 in main (argc=1, argv=0x7fff5fbffbb0) at 
> TrafficCop.cc:1958
> {code}
> Reference:
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.html

--
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-1065) traffic_cop segment fault when enable TRACE_LOG_COP


 [ 
https://issues.apache.org/jira/browse/TS-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić updated TS-1065:
---

Backport to Version: 3.0.3

> traffic_cop segment fault when enable TRACE_LOG_COP
> ---
>
> Key: TS-1065
> URL: https://issues.apache.org/jira/browse/TS-1065
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 3.1.1, 3.0.2
> Environment: mac os 10.7.2, centos 5.4 64bit
>Reporter: Conan Wang
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 3.1.2
>
> Attachments: traffic_cop.diff
>
>
> When enable traffic_cop's debug log:  #define TRACE_LOG_COP 1 
> Some cop_log invocation will cause segment fault, because va_list object in 
> cop_log is used twice between 'va_start' and 'va_end'.
> {code}
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x
> 0x7fff846b64f0 in strlen ()
> (gdb) bt
> #0  0x7fff846b64f0 in strlen ()
> #1  0x7fff846578c3 in __vfprintf ()
> #2  0x7fff846a109b in vsprintf_l ()
> #3  0x00011883 in cop_log (priority=5, format=0x172a8 "--- Cop 
> Starting [Version: %s] ---\n") at TrafficCop.cc:172
> #4  0x00012244 in check_lockfile () at TrafficCop.cc:1733
> #5  0x000122c0 in init () at TrafficCop.cc:1894
> #6  0x00016689 in main (argc=1, argv=0x7fff5fbffbb0) at 
> TrafficCop.cc:1958
> {code}
> Reference:
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.html

--
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-1049) TS hangs (dead lock) on HTTPS POST requests

[
https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Igor Galić updated TS-1049:
---

Description:
A very reproducible bug where the body of a HTTPS POST request is never
forwarded to the origin server.

Client submits a HTTPS POST request to TS, which is supposed to forward to the
backend/origin server via HTTP. TS process the HTTP headers and establishes
connection to the origin server, but the body of the HTTPS POST is never read.
This hangs until the client times out and shuts down the connection.

To reproduce:
# Client connects to TS using HTTPS (works OK if it is just HTTP).
# It must be a POST request.
# TS must use at least 2 worker threads.
# Easier to reproduce when the connections to the origin server is HTTP (not
HTTPS).
# POST body must be large enough so that the HTTP request headers and POST body
do *NOT* fit within the same TCP packet. (2000 bytes is a good size)
# I can consistently reproduce this problem using 2 separate clients each
simultaneously submitting 2 requests back to back (i.e., 2 requests from each
client, a total of 4 requests). This gives you a high probability that at
least one of the requests would hang.

Observation:
# Thread A accepted and processed the HTTP headers, and called
"UnixNetProcessor::connect_re" to prepare a new connection to the origin server.
# Thread A must not have read the body of the POST. Otherwise, it works fine.
# Thread B was assigned the task to handle the origin server connection. If
the same thread A was picked, then everything works fine.
# Apparently, one of the first things that thread B does is to acquire the
mutex for reading from the client. (Why does it do that??)
# While thread B was holding the mutex, thread A proceeded in
"SSLNetVConnection::net_read_io", tried and failed to acquire the mutex.
Thread A typically re-tried calling "SSLNetVConnection::net_read_io" soon, but
gave up after the second failure. But if thread B released the mutex soon
enough, that thread A could proceed happily and everything works.
# From this point, the body of the POST is never read from the client, and
there is nothing to be proxy'd to the origin server, and both the consumer and
producer tasks are never scheduled to run again -- or until the client times
out. I tried setting the client-side time out to as long as 3-5 minutes and TS
really does not recover by itself until the client closed the connection.

This is the first time I uses this bug system. Please let me know how I could
produce the configuration files and trace logs, etc. Thanks!

was:
A very reproducible bug where the body of a HTTPS POST request is never
forwarded to the origin server.

To reproduce:
1) Client connects to TS using HTTPS (works OK if it is just HTTP).
2) It must be a POST request.
3) TS must use at least 2 worker threads.
4) Easier to reproduce when the connections to the origin server is HTTP (not
HTTPS).
5) POST body must be large enough so that the HTTP request headers and POST
body do *NOT* fit within the same TCP packet. (2000 bytes is a good size)
6) I can consistently reproduce this problem using 2 separate clients each
simultaneously submitting 2 requests back to back (i.e., 2 requests from each
client, a total of 4 requests). This gives you a high probability that at
least one of the requests would hang.

Observation:
1) Thread A accepted and processed the HTTP headers, and called
"UnixNetProcessor::connect_re" to prepare a new connection to the origin server.
2) Thread A must not have read the body of the POST. Otherwise, it works fine.
3) Thread B was assigned the task to handle the origin server connection. If
the same thread A was picked, then everything works fine.
4) Apparently, one of the first things that thread B does is to acquire the
mutex for reading from the client. (Why does it do that??)
5) While thread B was holding the mutex, thread A proceeded in
"SSLNetVConnection::net_read_io", tried and failed to acquire the mutex.
Thread A typically re-tried calling "SSLNetVConnection::net_read_io" soon, but
gave up after the second failure. But if thread B released the mutex soon
enough, that thread A could proceed happily and everything works.
6) From this point, the body of the POST is never read from the client, and
there is nothing to be proxy'd to the origin server, and both the consumer and
producer tasks are never scheduled to run again -- or until the client times
out. I tried setting the client-side time out to as long as 3-5 minutes and TS
really does not recover by itself until the client cl

[jira] [Updated] (TS-1049) TS hangs (dead lock) on HTTPS POST requests


 [ 
https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić updated TS-1049:
---

Backport to Version: 3.0.3

> TS hangs (dead lock) on HTTPS POST requests
> ---
>
> Key: TS-1049
> URL: https://issues.apache.org/jira/browse/TS-1049
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP, SSL
>Affects Versions: 3.1.1, 3.1.0, 3.0.2
> Environment: RedHat Enterprise Linux 6.0, Intel 32-bit
>Reporter: Wilson Ho
>Assignee: Leif Hedstrom
>Priority: Blocker
> Fix For: 3.1.2
>
> Attachments: records.config
>
>
> A very reproducible bug where the body of a HTTPS POST request is never 
> forwarded to the origin server.
> Client submits a HTTPS POST request to TS, which is supposed to forward to 
> the backend/origin server via HTTP.  TS process the HTTP headers and 
> establishes connection to the origin server, but the body of the HTTPS POST 
> is never read.  This hangs until the client times out and shuts down the 
> connection.
> To reproduce:
> 1) Client connects to TS using HTTPS (works OK if it is just HTTP).
> 2) It must be a POST request.
> 3) TS must use at least 2 worker threads.
> 4) Easier to reproduce when the connections to the origin server is HTTP (not 
> HTTPS).
> 5) POST body must be large enough so that the HTTP request headers and POST 
> body do *NOT* fit within the same TCP packet. (2000 bytes is a good size)
> 6) I can consistently reproduce this problem using 2 separate clients each 
> simultaneously submitting 2 requests back to back (i.e., 2 requests from each 
> client, a total of 4 requests).  This gives you a high probability that at 
> least one of the requests would hang.
> Observation:
> 1) Thread A accepted and processed the HTTP headers, and called 
> "UnixNetProcessor::connect_re" to prepare a new connection to the origin 
> server.
> 2) Thread A must not have read the body of the POST.  Otherwise, it works 
> fine.
> 3) Thread B was assigned the task to handle the origin server connection.  If 
> the same thread A was picked, then everything works fine.
> 4) Apparently, one of the first things that thread B does is to acquire the 
> mutex for reading from the client.  (Why does it do that??)
> 5) While thread B was holding the mutex, thread A proceeded in 
> "SSLNetVConnection::net_read_io", tried and failed to acquire the mutex.  
> Thread A typically re-tried calling "SSLNetVConnection::net_read_io" soon, 
> but gave up after the second failure. But if thread B released the mutex soon 
> enough, that thread A could proceed happily and everything works.
> 6) From this point, the body of the POST is never read from the client, and 
> there is nothing to be proxy'd to the origin server, and both the consumer 
> and producer tasks are never scheduled to run again -- or until the client 
> times out.  I tried setting the client-side time out to as long as 3-5 
> minutes and TS really does not recover by itself until the client closed the 
> connection.
> This is the first time I uses this bug system.  Please let me know how I 
> could produce the configuration files and trace logs, etc.  Thanks!

--
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-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed as


 [ 
https://issues.apache.org/jira/browse/TS-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić updated TS-1061:
---

Backport to Version: 3.0.3

> TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter 
> (int *bytes) from the prototype in ./proxy/api/ts/ts.h.  The extra parameter 
> needs to be removed as it is not used.
> -
>
> Key: TS-1061
> URL: https://issues.apache.org/jira/browse/TS-1061
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 3.1.1, 3.0.1
> Environment: Redhat Linux but it is not environment specific
>Reporter: Alistair Stevenson
>Assignee: Igor Galić
>Priority: Minor
>  Labels: api-change
> Fix For: 3.1.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The definitions are:
> ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes)
> ./proxy/api/ts/ts.h.in:  tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn 
> txnp);
> The "int * bytes" parameter is not used and means that the function does not 
> resolve and so cannot be used.

--
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] [Assigned] (TS-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed a


 [ 
https://issues.apache.org/jira/browse/TS-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Galić reassigned TS-1061:
--

Assignee: Igor Galić  (was: Leif Hedstrom)

> TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter 
> (int *bytes) from the prototype in ./proxy/api/ts/ts.h.  The extra parameter 
> needs to be removed as it is not used.
> -
>
> Key: TS-1061
> URL: https://issues.apache.org/jira/browse/TS-1061
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 3.1.1, 3.0.1
> Environment: Redhat Linux but it is not environment specific
>Reporter: Alistair Stevenson
>Assignee: Igor Galić
>Priority: Minor
>  Labels: api-change
> Fix For: 3.1.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The definitions are:
> ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes)
> ./proxy/api/ts/ts.h.in:  tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn 
> txnp);
> The "int * bytes" parameter is not used and means that the function does not 
> resolve and so cannot be used.

--
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
 ]

Igor Galić updated TS-1038:
---

Backport to Version: 3.0.3

> 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
>Assignee: Igor Galić
> Fix For: 3.1.2
>
> 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] [Assigned] (TS-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)