date:20161018

[jira] [Work logged] (TS-4399) Management API breaks diagnostic log rotation

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4399?focusedWorklogId=30870=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30870
 ]

ASF GitHub Bot logged work on TS-4399:
--

Author: ASF GitHub Bot
Created on: 19/Oct/16 04:16
Start Date: 19/Oct/16 04:16
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1073#discussion_r83994912
  
--- Diff: cmd/traffic_manager/traffic_manager.cc ---
@@ -610,32 +616,37 @@ main(int argc, const char **argv)
   RecLocalStart(configFiles);
 
   /* Update cmd line overrides/environmental overrides/etc */
-  if (tsArgs) { /* Passed command line args for proxy */
-ats_free(lmgmt->proxy_options);
-lmgmt->proxy_options = tsArgs;
-mgmt_log("[main] Traffic Server Args: '%s'\n", lmgmt->proxy_options);
-  }
+  if (tsArgs)  /* Passed command line args for proxy */
+callback_proxy_options.push_back(ats_strdup(tsArgs));
 
-  // we must pass in bind_stdout and bind_stderr values to TS
-  // we do it so TS is able to create BaseLogFiles for each value
+  // we must give bind_stdout and bind_stderr values to 
callback_proxy_options
+  // so LocalManager can start up TS with the correct options
+  //
+  // TS needs them to be able to create BaseLogFiles for each value
   if (*bind_stdout != 0) {
-size_t l = strlen(lmgmt->proxy_options);
-size_t n = 3/* " --" */
-   + sizeof(TM_OPT_BIND_STDOUT) /* nul accounted for here */
-   + 1  /* space */
-   + strlen(bind_stdout);
-lmgmt->proxy_options = static_cast(ats_realloc(lmgmt->proxy_options, n + l));
-snprintf(lmgmt->proxy_options + l, n, " --%s %s", TM_OPT_BIND_STDOUT, 
bind_stdout);
+char *bind_stdout_opt = new char[strlen("--") + 
strlen(TM_OPT_BIND_STDOUT)];
+strcpy(bind_stdout_opt, "--");
+strcat(bind_stdout_opt, TM_OPT_BIND_STDOUT);
+callback_proxy_options.push_back(bind_stdout_opt);
+callback_proxy_options.push_back(ats_strdup(bind_stdout));
   }
 
   if (*bind_stderr != 0) {
-size_t l = strlen(lmgmt->proxy_options);
-size_t n = 3/* space dash dash */
-   + sizeof(TM_OPT_BIND_STDERR) /* nul accounted for here */
-   + 1  /* space */
-   + strlen(bind_stderr);
-lmgmt->proxy_options = static_cast(ats_realloc(lmgmt->proxy_options, n + l));
-snprintf(lmgmt->proxy_options + l, n, " --%s %s", TM_OPT_BIND_STDERR, 
bind_stderr);
+char *bind_stderr_opt = new char[strlen("--") + 
strlen(TM_OPT_BIND_STDERR)];
+strcpy(bind_stderr_opt, "--");
+strcat(bind_stderr_opt, TM_OPT_BIND_STDERR);
--- End diff --

```C
foo.push_back("--" TM_OPT_BIND_STDERR")


Issue Time Tracking
---

Worklog Id: (was: 30870)
Time Spent: 40m  (was: 0.5h)

> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Start up Traffic Server:
> {code}
> 0 26950 1   0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950   0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager 
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr 
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951   0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server 
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr 
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1   0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950   0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager 
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr 
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951   0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server 
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1073: TS-4399 TS-4400 Management API messes up p...

2016-10-18 Thread jpeach

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1073#discussion_r83994912
  
--- Diff: cmd/traffic_manager/traffic_manager.cc ---
@@ -610,32 +616,37 @@ main(int argc, const char **argv)
   RecLocalStart(configFiles);
 
   /* Update cmd line overrides/environmental overrides/etc */
-  if (tsArgs) { /* Passed command line args for proxy */
-ats_free(lmgmt->proxy_options);
-lmgmt->proxy_options = tsArgs;
-mgmt_log("[main] Traffic Server Args: '%s'\n", lmgmt->proxy_options);
-  }
+  if (tsArgs)  /* Passed command line args for proxy */
+callback_proxy_options.push_back(ats_strdup(tsArgs));
 
-  // we must pass in bind_stdout and bind_stderr values to TS
-  // we do it so TS is able to create BaseLogFiles for each value
+  // we must give bind_stdout and bind_stderr values to 
callback_proxy_options
+  // so LocalManager can start up TS with the correct options
+  //
+  // TS needs them to be able to create BaseLogFiles for each value
   if (*bind_stdout != 0) {
-size_t l = strlen(lmgmt->proxy_options);
-size_t n = 3/* " --" */
-   + sizeof(TM_OPT_BIND_STDOUT) /* nul accounted for here */
-   + 1  /* space */
-   + strlen(bind_stdout);
-lmgmt->proxy_options = static_cast(ats_realloc(lmgmt->proxy_options, n + l));
-snprintf(lmgmt->proxy_options + l, n, " --%s %s", TM_OPT_BIND_STDOUT, 
bind_stdout);
+char *bind_stdout_opt = new char[strlen("--") + 
strlen(TM_OPT_BIND_STDOUT)];
+strcpy(bind_stdout_opt, "--");
+strcat(bind_stdout_opt, TM_OPT_BIND_STDOUT);
+callback_proxy_options.push_back(bind_stdout_opt);
+callback_proxy_options.push_back(ats_strdup(bind_stdout));
   }
 
   if (*bind_stderr != 0) {
-size_t l = strlen(lmgmt->proxy_options);
-size_t n = 3/* space dash dash */
-   + sizeof(TM_OPT_BIND_STDERR) /* nul accounted for here */
-   + 1  /* space */
-   + strlen(bind_stderr);
-lmgmt->proxy_options = static_cast(ats_realloc(lmgmt->proxy_options, n + l));
-snprintf(lmgmt->proxy_options + l, n, " --%s %s", TM_OPT_BIND_STDERR, 
bind_stderr);
+char *bind_stderr_opt = new char[strlen("--") + 
strlen(TM_OPT_BIND_STDERR)];
+strcpy(bind_stderr_opt, "--");
+strcat(bind_stderr_opt, TM_OPT_BIND_STDERR);
--- End diff --

```C
foo.push_back("--" TM_OPT_BIND_STDERR")


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4972) Allow collapsed_forwarding plugin to be configured global or per remap

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4972:
--
Fix Version/s: 7.1.0

> Allow collapsed_forwarding plugin to be configured global or per remap
> --
>
> Key: TS-4972
> URL: https://issues.apache.org/jira/browse/TS-4972
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Currently collpased_forwarding plugin can only be configured on remap rules.  
> It would be convenient to just configure it globally for some environments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4970) Crash in INKVConnInternal when handle_event is called after destroy()

2016-10-18 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15585471#comment-15585471
 ] 

Leif Hedstrom commented on TS-4970:
---

Are those two PR's duplicates of each other?

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.1.0
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = { = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4970) Crash in INKVConnInternal when handle_event is called after destroy()

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4970:
--
Fix Version/s: 7.1.0

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.1.0
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = { = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1114: TS-4976: Remove useless casts from plugins...

2016-10-18 Thread SolidWallOfCode

Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1114#discussion_r83854785
  
--- Diff: example/intercept/intercept.cc ---
@@ -538,9 +538,9 @@ TSPluginInit(int /* argc */, const char * /* argv */ [])
 {
   TSPluginRegistrationInfo info;
 
-  info.plugin_name   = (char *)PLUGIN;
-  info.vendor_name   = (char *)"MyCompany";
-  info.support_email = (char *)"ts-api-supp...@mycompany.com";
+  info.plugin_name   = PLUGIN;
+  info.vendor_name   = "MyCompany";
+  info.support_email = "ts-api-supp...@mycompany.com";
--- End diff --

I fixed `example/add-header` and `example/append-transform` this way. See 
if that looks reasonable. For `.cc` files I would replace `static` with the 
anonymous namespace.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4976) Clean up casting in the plugins.

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4976?focusedWorklogId=30802=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30802
 ]

ASF GitHub Bot logged work on TS-4976:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 13:51
Start Date: 18/Oct/16 13:51
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1114
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1038/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30802)
Time Spent: 1.5h  (was: 1h 20m)

> Clean up casting in the plugins.
> 
>
> Key: TS-4976
> URL: https://issues.apache.org/jira/browse/TS-4976
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> With TS-4971 committed, we should clean up the {{const_cast}} formerly 
> required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4976) Clean up casting in the plugins.

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4976?focusedWorklogId=30801=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30801
 ]

ASF GitHub Bot logged work on TS-4976:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 13:46
Start Date: 18/Oct/16 13:46
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1114
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/929/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30801)
Time Spent: 1h 20m  (was: 1h 10m)

> Clean up casting in the plugins.
> 
>
> Key: TS-4976
> URL: https://issues.apache.org/jira/browse/TS-4976
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> With TS-4971 committed, we should clean up the {{const_cast}} formerly 
> required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4960) Undo internal request tunnelling hacks

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4960:
--
Fix Version/s: sometime

> Undo internal request tunnelling hacks
> --
>
> Key: TS-4960
> URL: https://issues.apache.org/jira/browse/TS-4960
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: James Peach
> Fix For: sometime
>
>
> {noformat}
> proxy/http/HttpSM.cc:is_eligible_post_request &= 
> !vc->get_is_internal_request();
> {noformat}
> {{HttpSM::tunnel_handler_ua}} does shenanigans based on whether this is an 
> internal transaction or not. This is a complete hack. Internal transactions 
> are no supposed to behave differently.
> AFAICT, this hack from  TS-3404 led to TS-3777, which led to TS-4924, which 
> makes it impossible for protocol plugins to use keepalive.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4597) Coverity Null-Check after deref in NetworkUtilisRemote.cc

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4597:
--
Assignee: Tyler Stroh

> Coverity Null-Check after deref in NetworkUtilisRemote.cc
> -
>
> Key: TS-4597
> URL: https://issues.apache.org/jira/browse/TS-4597
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.1.0
>
>
> ** 1237320 Dereference before null check **
> __
> 660  event_notice = (TSMgmtEvent *)arg;
>   deref_ptr: Directly dereferencing pointer event_notice.
> 661  index= (int)event_notice->id;
> 662  LLQ *func_q; // list of callback functions need to call
> 663
> 664  func_q = create_queue();
> 665  if (!func_q) {
>   
> CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking event_notice suggests that it may be null, 
> but it has already been dereferenced on all paths leading to the check.
> 666if (event_notice)
> 667  TSEventDestroy(event_notice);
> 668return NULL;
> 669  }
>  __



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4944) Should collapsed_forwarding.so really need to retry on 500 ?

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4944:
--
Fix Version/s: sometime

> Should collapsed_forwarding.so really need to retry on 500 ?
> 
>
> Key: TS-4944
> URL: https://issues.apache.org/jira/browse/TS-4944
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: James Fang
> Fix For: sometime
>
>
> if OS really return 500, then it will retry 
> OPEN_WRITE_FAIL_MAX_REQ_DELAY_RETRIES times ?
> i am also wondering when 500 will be returned besides the above case ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4952) Improve mutex error checking.

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4952:
--
Fix Version/s: 7.1.0

> Improve mutex error checking.
> -
>
> Key: TS-4952
> URL: https://issues.apache.org/jira/browse/TS-4952
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> If any {{ink_mutex}} operations fail, we just abort. Use {{ink_abort}} so 
> that we can log an error if this happens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4952) Improve mutex error checking.

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4952:
--
Assignee: James Peach

> Improve mutex error checking.
> -
>
> Key: TS-4952
> URL: https://issues.apache.org/jira/browse/TS-4952
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> If any {{ink_mutex}} operations fail, we just abort. Use {{ink_abort}} so 
> that we can log an error if this happens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4597) Coverity Null-Check after deref in NetworkUtilisRemote.cc

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4597:
--
Fix Version/s: 7.1.0

> Coverity Null-Check after deref in NetworkUtilisRemote.cc
> -
>
> Key: TS-4597
> URL: https://issues.apache.org/jira/browse/TS-4597
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Tyler Stroh
> Fix For: 7.1.0
>
>
> ** 1237320 Dereference before null check **
> __
> 660  event_notice = (TSMgmtEvent *)arg;
>   deref_ptr: Directly dereferencing pointer event_notice.
> 661  index= (int)event_notice->id;
> 662  LLQ *func_q; // list of callback functions need to call
> 663
> 664  func_q = create_queue();
> 665  if (!func_q) {
>   
> CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking event_notice suggests that it may be null, 
> but it has already been dereferenced on all paths leading to the check.
> 666if (event_notice)
> 667  TSEventDestroy(event_notice);
> 668return NULL;
> 669  }
>  __



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4975) ATS crashing when taking it out of rotation

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4975:
--
Fix Version/s: 7.1.0

> ATS crashing when taking it out of rotation
> ---
>
> Key: TS-4975
> URL: https://issues.apache.org/jira/browse/TS-4975
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 7.0.0
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>
> ATS crashing when setting keep-alive to 0 and http2 inactive timeout to 10.
> {noformat}
> =
> ==64589==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x6180062bcf98 at pc 0x00723b51 bp 0x2ab58616d520 sp 0x2ab58616d518
> WRITE of size 8 at 0x6180062bcf98 thread T29 ([ET_NET 27])
> #0 0x723b50 in Http1ClientTransaction::transaction_done() 
> ../../../trafficserver/proxy/http/Http1ClientTransaction.cc:70
> #1 0x775452 in HttpSM::kill_this() 
> ../../../trafficserver/proxy/http/HttpSM.cc:6798
> #2 0x74f808 in HttpSM::main_handler(int, void*) 
> ../../../trafficserver/proxy/http/HttpSM.cc:2674
> #3 0x5ef2b4 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #4 0x8211fd in HttpTunnel::main_handler(int, void*) 
> ../../../trafficserver/proxy/http/HttpTunnel.cc:1662
> #5 0x5ef2b4 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0xae565d in write_signal_and_update 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:179
> #7 0xae5aae in write_signal_done 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:221
> #8 0xae7b31 in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) ../../../trafficserver/iocore/net/UnixNetVConnection.cc:552
> #9 0xae6d92 in write_to_net(NetHandler*, UnixNetVConnection*, EThread*) 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:419
> #10 0xad210c in NetHandler::mainNetEvent(int, Event*) 
> ../../../trafficserver/iocore/net/UnixNet.cc:542
> #11 0x5ef2b4 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #12 0xb310f2 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:143
> #13 0xb31d85 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:270
> #14 0xb2fb6b in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:84
> #15 0x2ab57cbe6aa0 in start_thread (/lib64/libpthread.so.0+0x32efa07aa0)
> #16 0x32ef2e893c in clone (/lib64/libc.so.6+0x32ef2e893c)
> 0x6180062bcf98 is located 792 bytes inside of 880-byte region 
> [0x6180062bcc80,0x6180062bcff0)
> freed by thread T29 ([ET_NET 27]) here:
> #0 0x5835ea in __interceptor_free (/home/y/bin64/traffic_server+0x5835ea)
> #1 0x2ab57bd5a154 in ats_memalign_free 
> ../../../trafficserver/lib/ts/ink_memory.cc:141
> #2 0x2ab57bd5bfc3 in malloc_bulkfree 
> ../../../trafficserver/lib/ts/ink_queue.cc:384
> #3 0x2ab57bd5bc94 in ink_freelist_free_bulk 
> ../../../trafficserver/lib/ts/ink_queue.cc:326
> #4 0x723343 in 
> ClassAllocator::free_bulk(Http1ClientSession*, 
> Http1ClientSession*, unsigned long) 
> ../../../trafficserver/lib/ts/Allocator.h:148
> #5 0x723266 in void 
> thread_freeup(ClassAllocator&, 
> ProxyAllocator&) (/home/y/bin64/traffic_server+0x723266)
> #6 0x71e016 in Http1ClientSession::free() 
> ../../../trafficserver/proxy/http/Http1ClientSession.cc:125
> #7 0x67e16c in ProxyClientSession::handle_api_return(int) 
> ../../trafficserver/proxy/ProxyClientSession.cc:206
> #8 0x67dcfc in ProxyClientSession::do_api_callout(TSHttpHookID) 
> ../../trafficserver/proxy/ProxyClientSession.cc:177
> #9 0x71dc3b in Http1ClientSession::destroy() 
> ../../../trafficserver/proxy/http/Http1ClientSession.cc:94
> #10 0x723b2b in Http1ClientTransaction::transaction_done() 
> ../../../trafficserver/proxy/http/Http1ClientTransaction.cc:69
> #11 0x775452 in HttpSM::kill_this() 
> ../../../trafficserver/proxy/http/HttpSM.cc:6798
> #12 0x74f808 in HttpSM::main_handler(int, void*) 
> ../../../trafficserver/proxy/http/HttpSM.cc:2674
> #13 0x5ef2b4 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #14 0x8211fd in HttpTunnel::main_handler(int, void*) 
> ../../../trafficserver/proxy/http/HttpTunnel.cc:1662
> #15 0x5ef2b4 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #16 0xae565d in write_signal_and_update 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:179
> #17 0xae5aae in write_signal_done 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:221
>

[jira] [Created] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc

2016-10-18 Thread Leif Hedstrom (JIRA)

Leif Hedstrom created TS-4978:
-

 Summary: CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE) 
in iocore/net/SSLConfig.cc
 Key: TS-4978
 URL: https://issues.apache.org/jira/browse/TS-4978
 Project: Traffic Server
  Issue Type: Bug
  Components: TLS
Reporter: Leif Hedstrom


I think this is perhaps from TS-4858:

{code}
*** CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
/iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
252   ats_free(ssl_server_ca_cert_filename);
253   ats_free(CACertRelativePath);
254 
255 #if HAVE_OPENSSL_SESSION_TICKETS
256   REC_ReadConfigStringAlloc(ticket_key_filename, 
"proxy.config.ssl.server.ticket_key.filename");
257   if (this->ticket_key_filename != NULL) {
   CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
   Passing freed pointer "this->ticket_key_filename" as an argument to 
"relative_to".
258 ats_scoped_str 
ticket_key_path(Layout::relative_to(this->serverCertPathOnly, 
this->ticket_key_filename));
259 default_global_keyblock = 
ssl_create_ticket_keyblock(ticket_key_path);
260   } else {
261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
262   }
263 #endif
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4978:
--
Fix Version/s: 7.1.0

> CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE) in 
> iocore/net/SSLConfig.cc
> 
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TLS
>Reporter: Leif Hedstrom
> Fix For: 7.1.0
>
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252   ats_free(ssl_server_ca_cert_filename);
> 253   ats_free(CACertRelativePath);
> 254 
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256   REC_ReadConfigStringAlloc(ticket_key_filename, 
> "proxy.config.ssl.server.ticket_key.filename");
> 257   if (this->ticket_key_filename != NULL) {
>CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to 
> "relative_to".
> 258 ats_scoped_str 
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly, 
> this->ticket_key_filename));
> 259 default_global_keyblock = 
> ssl_create_ticket_keyblock(ticket_key_path);
> 260   } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262   }
> 263 #endif
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4978:
--
Assignee: Susan Hinrichs

> CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE) in 
> iocore/net/SSLConfig.cc
> 
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252   ats_free(ssl_server_ca_cert_filename);
> 253   ats_free(CACertRelativePath);
> 254 
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256   REC_ReadConfigStringAlloc(ticket_key_filename, 
> "proxy.config.ssl.server.ticket_key.filename");
> 257   if (this->ticket_key_filename != NULL) {
>CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to 
> "relative_to".
> 258 ats_scoped_str 
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly, 
> this->ticket_key_filename));
> 259 default_global_keyblock = 
> ssl_create_ticket_keyblock(ticket_key_path);
> 260   } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262   }
> 263 #endif
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1114: TS-4976: Remove useless casts from plugins.

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1114
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1037/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4968) Log a warning if connect_attempts_rr_retries is >= connect_attempts_max_retries

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4968:
--
Fix Version/s: 7.1.0

> Log a warning if connect_attempts_rr_retries is >= 
> connect_attempts_max_retries
> ---
>
> Key: TS-4968
> URL: https://issues.apache.org/jira/browse/TS-4968
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Thomas Jackson
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> If connect_attempts_rr_retries >= connect_attempts_max_retries requests going 
> to an RR DNS record will never be redispatched. To make it a bit more 
> obvious-- I think we should log a warning when we load the configs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4968) Log a warning if connect_attempts_rr_retries is >= connect_attempts_max_retries

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4968:
--
Assignee: Thomas Jackson

> Log a warning if connect_attempts_rr_retries is >= 
> connect_attempts_max_retries
> ---
>
> Key: TS-4968
> URL: https://issues.apache.org/jira/browse/TS-4968
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> If connect_attempts_rr_retries >= connect_attempts_max_retries requests going 
> to an RR DNS record will never be redispatched. To make it a bit more 
> obvious-- I think we should log a warning when we load the configs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4976) Clean up casting in the plugins.

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4976?focusedWorklogId=30799=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30799
 ]

ASF GitHub Bot logged work on TS-4976:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 13:37
Start Date: 18/Oct/16 13:37
Worklog Time Spent: 10m 
  Work Description: Github user SolidWallOfCode commented on a diff in the 
pull request:

https://github.com/apache/trafficserver/pull/1114#discussion_r83854785
  
--- Diff: example/intercept/intercept.cc ---
@@ -538,9 +538,9 @@ TSPluginInit(int /* argc */, const char * /* argv */ [])
 {
   TSPluginRegistrationInfo info;
 
-  info.plugin_name   = (char *)PLUGIN;
-  info.vendor_name   = (char *)"MyCompany";
-  info.support_email = (char *)"ts-api-supp...@mycompany.com";
+  info.plugin_name   = PLUGIN;
+  info.vendor_name   = "MyCompany";
+  info.support_email = "ts-api-supp...@mycompany.com";
--- End diff --

I fixed `example/add-header` and `example/append-transform` this way. See 
if that looks reasonable. For `.cc` files I would replace `static` with the 
anonymous namespace.


Issue Time Tracking
---

Worklog Id: (was: 30799)
Time Spent: 1h  (was: 50m)

> Clean up casting in the plugins.
> 
>
> Key: TS-4976
> URL: https://issues.apache.org/jira/browse/TS-4976
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> With TS-4971 committed, we should clean up the {{const_cast}} formerly 
> required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1114: TS-4976: Remove useless casts from plugins.

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1114
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/929/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4976) Clean up casting in the plugins.

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4976?focusedWorklogId=30800=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30800
 ]

ASF GitHub Bot logged work on TS-4976:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 13:45
Start Date: 18/Oct/16 13:45
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1114
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1037/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30800)
Time Spent: 1h 10m  (was: 1h)

> Clean up casting in the plugins.
> 
>
> Key: TS-4976
> URL: https://issues.apache.org/jira/browse/TS-4976
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> With TS-4971 committed, we should clean up the {{const_cast}} formerly 
> required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1114: TS-4976: Remove useless casts from plugins.

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1114
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1038/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4974) Bad debug assert in HttpSM::handle_server_setup_error

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4974:
--
Fix Version/s: 7.1.0

> Bad debug assert in HttpSM::handle_server_setup_error
> -
>
> Key: TS-4974
> URL: https://issues.apache.org/jira/browse/TS-4974
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When running with debug_enable, the non-release assert in 
> HttpSM::handle_server_setup_error sometimes goes off.
> ink_assert(server_entry->read_vio == data);
> In the crash case, the data corresponds to server_entry->write_vio. Reviewing 
> the function, I don't see why it is bad that this function is called with the 
> write vio.  The actual IO operations are performed against 
> server_entry->read_vio and server_entry->write_io instead of the parameter 
> vio directly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4597) CID 1237320: Null-Check after deref in NetworkUtilisRemote.cc

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4597:
--
Summary: CID 1237320: Null-Check after deref in NetworkUtilisRemote.cc  
(was: Coverity Null-Check after deref in NetworkUtilisRemote.cc)

> CID 1237320: Null-Check after deref in NetworkUtilisRemote.cc
> -
>
> Key: TS-4597
> URL: https://issues.apache.org/jira/browse/TS-4597
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.1.0
>
>
> {code}
> ** 1237320 Dereference before null check **
> __
> 660  event_notice = (TSMgmtEvent *)arg;
>   deref_ptr: Directly dereferencing pointer event_notice.
> 661  index= (int)event_notice->id;
> 662  LLQ *func_q; // list of callback functions need to call
> 663
> 664  func_q = create_queue();
> 665  if (!func_q) {
>   
> CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking event_notice suggests that it may be null, 
> but it has already been dereferenced on all paths leading to the check.
> 666if (event_notice)
> 667  TSEventDestroy(event_notice);
> 668return NULL;
> 669  }
>  __
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4597) Coverity Null-Check after deref in NetworkUtilisRemote.cc

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4597:
--
Description: 
{code}
** 1237320 Dereference before null check **
__
660  event_notice = (TSMgmtEvent *)arg;
deref_ptr: Directly dereferencing pointer event_notice.
661  index= (int)event_notice->id;
662  LLQ *func_q; // list of callback functions need to call
663
664  func_q = create_queue();
665  if (!func_q) {

CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking event_notice suggests that it may be null, but 
it has already been dereferenced on all paths leading to the check.
666if (event_notice)
667  TSEventDestroy(event_notice);
668return NULL;
669  }
 __
{code}

  was:
** 1237320 Dereference before null check **
__
660  event_notice = (TSMgmtEvent *)arg;
deref_ptr: Directly dereferencing pointer event_notice.
661  index= (int)event_notice->id;
662  LLQ *func_q; // list of callback functions need to call
663
664  func_q = create_queue();
665  if (!func_q) {

CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking event_notice suggests that it may be null, but 
it has already been dereferenced on all paths leading to the check.
666if (event_notice)
667  TSEventDestroy(event_notice);
668return NULL;
669  }
 __


> Coverity Null-Check after deref in NetworkUtilisRemote.cc
> -
>
> Key: TS-4597
> URL: https://issues.apache.org/jira/browse/TS-4597
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.1.0
>
>
> {code}
> ** 1237320 Dereference before null check **
> __
> 660  event_notice = (TSMgmtEvent *)arg;
>   deref_ptr: Directly dereferencing pointer event_notice.
> 661  index= (int)event_notice->id;
> 662  LLQ *func_q; // list of callback functions need to call
> 663
> 664  func_q = create_queue();
> 665  if (!func_q) {
>   
> CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking event_notice suggests that it may be null, 
> but it has already been dereferenced on all paths leading to the check.
> 666if (event_notice)
> 667  TSEventDestroy(event_notice);
> 668return NULL;
> 669  }
>  __
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4977) Adopt nullptr

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4977:
--
Fix Version/s: 7.1.0

> Adopt nullptr
> -
>
> Key: TS-4977
> URL: https://issues.apache.org/jira/browse/TS-4977
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, Core
>Reporter: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Adopt {{nullptr}} to replace {{NULL}} in all C++ files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4977) Adopt nullptr

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4977:
--
Assignee: James Peach

> Adopt nullptr
> -
>
> Key: TS-4977
> URL: https://issues.apache.org/jira/browse/TS-4977
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Adopt {{nullptr}} to replace {{NULL}} in all C++ files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4597) Coverity Null-Check after deref in NetworkUtilisRemote.cc

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4597:
--
Component/s: Network

> Coverity Null-Check after deref in NetworkUtilisRemote.cc
> -
>
> Key: TS-4597
> URL: https://issues.apache.org/jira/browse/TS-4597
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.1.0
>
>
> {code}
> ** 1237320 Dereference before null check **
> __
> 660  event_notice = (TSMgmtEvent *)arg;
>   deref_ptr: Directly dereferencing pointer event_notice.
> 661  index= (int)event_notice->id;
> 662  LLQ *func_q; // list of callback functions need to call
> 663
> 664  func_q = create_queue();
> 665  if (!func_q) {
>   
> CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking event_notice suggests that it may be null, 
> but it has already been dereferenced on all paths leading to the check.
> 666if (event_notice)
> 667  TSEventDestroy(event_notice);
> 668return NULL;
> 669  }
>  __
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4976) Clean up casting in the plugins.

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4976:
--
Assignee: Alan M. Carroll

> Clean up casting in the plugins.
> 
>
> Key: TS-4976
> URL: https://issues.apache.org/jira/browse/TS-4976
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> With TS-4971 committed, we should clean up the {{const_cast}} formerly 
> required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4976) Clean up casting in the plugins.

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4976:
--
Fix Version/s: 7.1.0

> Clean up casting in the plugins.
> 
>
> Key: TS-4976
> URL: https://issues.apache.org/jira/browse/TS-4976
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> With TS-4971 committed, we should clean up the {{const_cast}} formerly 
> required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4962) Restructure and simplify connection acceptance

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4962:
--
Fix Version/s: sometime

> Restructure and simplify connection acceptance
> --
>
> Key: TS-4962
> URL: https://issues.apache.org/jira/browse/TS-4962
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: James Peach
> Fix For: sometime
>
>
> The connection acceptance code {{NetAccept}}, etc. is overly complex and 
> contains a lot of variants that are not used. For example, 
> {{NetAccept::accept_fn}} is always a fixed value.
> This should be cleaned up and restructured to make it simpler and easier to 
> follow. While we are at it, we can make some changes to improve accept 
> performance by {{dup}}ing the listen sockets or using {{SO_REUSEADDR}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1097: Make the use of madvise() with MADV_DONTDUMP conf...

2016-10-18 Thread jpeach

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1097
  
No I think it is trivial to remove the global and we should just do it

> On Oct 18, 2016, at 7:29 AM, John J. Rushford  
wrote:
> 
> @jrushford commented on this pull request.
> 
> In iocore/eventsystem/I_IOBuffer.h:
> 
> > @@ -58,6 +58,7 @@ class VIO;
>  inkcoreapi extern int64_t max_iobuffer_size;
>  extern int64_t default_small_iobuffer_size;
>  extern int64_t default_large_iobuffer_size; // matched to size of OS 
buffers
> +extern int iobuffer_advice;
> @jpeach I'd like to land this as is and write a JIRA to come back to the 
global variable once we've had time to evaluate this. Are you okay with this?
> 
> â
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4930) Unfold request headers that are using obs continuations

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4930?focusedWorklogId=30805=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30805
 ]

ASF GitHub Bot logged work on TS-4930:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 15:54
Start Date: 18/Oct/16 15:54
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/1078


Issue Time Tracking
---

Worklog Id: (was: 30805)
Time Spent: 1h 50m  (was: 1h 40m)

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4979) clang-analyzer error in HttpTransact.cc

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4979?focusedWorklogId=30807=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30807
 ]

ASF GitHub Bot logged work on TS-4979:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 16:03
Start Date: 18/Oct/16 16:03
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1116
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/930/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30807)
Time Spent: 20m  (was: 10m)

> clang-analyzer error in HttpTransact.cc
> ---
>
> Key: TS-4979
> URL: https://issues.apache.org/jira/browse/TS-4979
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {code}
> if (mimefield_value_equal(host_field, *host_val, host_val_len) == false) {
> 7
> ←
> Passing null pointer value via 2nd parameter 'value'  
> →
> 8
> ←
> Calling 'mimefield_value_equal'   
> →
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4979) clang-analyzer error in HttpTransact.cc

2016-10-18 Thread Leif Hedstrom (JIRA)

Leif Hedstrom created TS-4979:
-

 Summary: clang-analyzer error in HttpTransact.cc
 Key: TS-4979
 URL: https://issues.apache.org/jira/browse/TS-4979
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Leif Hedstrom


{code}
if (mimefield_value_equal(host_field, *host_val, host_val_len) == false) {
7
←
Passing null pointer value via 2nd parameter 'value'
→
8
←
Calling 'mimefield_value_equal' 
→
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1116: TS-4979: Fix clang-analyzer complaint about poten...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1116
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/930/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1116: TS-4979: Fix clang-analyzer complaint about poten...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1116
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1039/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4979) clang-analyzer error in HttpTransact.cc

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4979:
--
Fix Version/s: 7.1.0

> clang-analyzer error in HttpTransact.cc
> ---
>
> Key: TS-4979
> URL: https://issues.apache.org/jira/browse/TS-4979
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
> Fix For: 7.1.0
>
>
> {code}
> if (mimefield_value_equal(host_field, *host_val, host_val_len) == false) {
> 7
> ←
> Passing null pointer value via 2nd parameter 'value'  
> →
> 8
> ←
> Calling 'mimefield_value_equal'   
> →
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4979) clang-analyzer error in HttpTransact.cc

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4979:
--
Assignee: Alan M. Carroll

> clang-analyzer error in HttpTransact.cc
> ---
>
> Key: TS-4979
> URL: https://issues.apache.org/jira/browse/TS-4979
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>
> {code}
> if (mimefield_value_equal(host_field, *host_val, host_val_len) == false) {
> 7
> ←
> Passing null pointer value via 2nd parameter 'value'  
> →
> 8
> ←
> Calling 'mimefield_value_equal'   
> →
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1078: TS-4930: Unfolds request headers that are ...

2016-10-18 Thread zwoop

Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/1078


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1116: TS-4979: Fix coverity complaint about pote...

2016-10-18 Thread SolidWallOfCode

GitHub user SolidWallOfCode opened a pull request:

https://github.com/apache/trafficserver/pull/1116

TS-4979: Fix coverity complaint about potential null pointer.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SolidWallOfCode/trafficserver ts-4979

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1116.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1116


commit ea965643027e96a22016b3c916ecbeb7ee2fa0ee
Author: Alan M. Carroll 
Date:   2016-10-18T16:00:07Z

TS-4979: Fix coverity complaint about potential null pointer.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4979) clang-analyzer error in HttpTransact.cc

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4979?focusedWorklogId=30809=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30809
 ]

ASF GitHub Bot logged work on TS-4979:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 16:19
Start Date: 18/Oct/16 16:19
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1116
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/931/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30809)
Time Spent: 40m  (was: 0.5h)

> clang-analyzer error in HttpTransact.cc
> ---
>
> Key: TS-4979
> URL: https://issues.apache.org/jira/browse/TS-4979
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> if (mimefield_value_equal(host_field, *host_val, host_val_len) == false) {
> 7
> ←
> Passing null pointer value via 2nd parameter 'value'  
> →
> 8
> ←
> Calling 'mimefield_value_equal'   
> →
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4979) clang-analyzer error in HttpTransact.cc

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4979?focusedWorklogId=30810=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30810
 ]

ASF GitHub Bot logged work on TS-4979:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 16:22
Start Date: 18/Oct/16 16:22
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1116#discussion_r83893797
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -1075,6 +1073,8 @@ HttpTransact::ModifyRequest(State *s)
   if (!request.is_target_in_url()) {
 s->hdr_info.client_req_is_server_style = true;
   }
+  // Make Coverity happy. hostname is non-null iff 
request.is_target_in_url().
--- End diff --

Since we're bike shedding, this probably should have said "clang-analyzer". 
;-)


Issue Time Tracking
---

Worklog Id: (was: 30810)
Time Spent: 50m  (was: 40m)

> clang-analyzer error in HttpTransact.cc
> ---
>
> Key: TS-4979
> URL: https://issues.apache.org/jira/browse/TS-4979
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {code}
> if (mimefield_value_equal(host_field, *host_val, host_val_len) == false) {
> 7
> ←
> Passing null pointer value via 2nd parameter 'value'  
> →
> 8
> ←
> Calling 'mimefield_value_equal'   
> →
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1116: TS-4979: Fix clang-analyzer complaint abou...

2016-10-18 Thread zwoop

Github user zwoop commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1116#discussion_r83893797
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -1075,6 +1073,8 @@ HttpTransact::ModifyRequest(State *s)
   if (!request.is_target_in_url()) {
 s->hdr_info.client_req_is_server_style = true;
   }
+  // Make Coverity happy. hostname is non-null iff 
request.is_target_in_url().
--- End diff --

Since we're bike shedding, this probably should have said "clang-analyzer". 
;-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4979) clang-analyzer error in HttpTransact.cc

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4979?focusedWorklogId=30806=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30806
 ]

ASF GitHub Bot logged work on TS-4979:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 16:01
Start Date: 18/Oct/16 16:01
Worklog Time Spent: 10m 
  Work Description: GitHub user SolidWallOfCode opened a pull request:

https://github.com/apache/trafficserver/pull/1116

TS-4979: Fix coverity complaint about potential null pointer.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SolidWallOfCode/trafficserver ts-4979

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1116.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1116


commit ea965643027e96a22016b3c916ecbeb7ee2fa0ee
Author: Alan M. Carroll 
Date:   2016-10-18T16:00:07Z

TS-4979: Fix coverity complaint about potential null pointer.




Issue Time Tracking
---

Worklog Id: (was: 30806)
Time Spent: 10m
Remaining Estimate: 0h

> clang-analyzer error in HttpTransact.cc
> ---
>
> Key: TS-4979
> URL: https://issues.apache.org/jira/browse/TS-4979
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {code}
> if (mimefield_value_equal(host_field, *host_val, host_val_len) == false) {
> 7
> ←
> Passing null pointer value via 2nd parameter 'value'  
> →
> 8
> ←
> Calling 'mimefield_value_equal'   
> →
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1116: TS-4979: Fix clang-analyzer complaint about poten...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1116
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/931/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4979) clang-analyzer error in HttpTransact.cc

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4979?focusedWorklogId=30808=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30808
 ]

ASF GitHub Bot logged work on TS-4979:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 16:16
Start Date: 18/Oct/16 16:16
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1116
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1039/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30808)
Time Spent: 0.5h  (was: 20m)

> clang-analyzer error in HttpTransact.cc
> ---
>
> Key: TS-4979
> URL: https://issues.apache.org/jira/browse/TS-4979
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {code}
> if (mimefield_value_equal(host_field, *host_val, host_val_len) == false) {
> 7
> ←
> Passing null pointer value via 2nd parameter 'value'  
> →
> 8
> ←
> Calling 'mimefield_value_equal'   
> →
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4947) Collation Server is broken?

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4947?focusedWorklogId=30811=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30811
 ]

ASF GitHub Bot logged work on TS-4947:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 16:33
Start Date: 18/Oct/16 16:33
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1104
  
Build and I ran the tests.  Code looks OK, but I don't know the lua API.


Issue Time Tracking
---

Worklog Id: (was: 30811)
Time Spent: 40m  (was: 0.5h)

> Collation Server is broken?
> ---
>
> Key: TS-4947
> URL: https://issues.apache.org/jira/browse/TS-4947
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 7.0.0
>Reporter: bettydramit
>Assignee: James Peach
>Priority: Critical
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> from gitmaster(github.com/apache/trafficserver)
> config Collation Client 
> {code:xml}
> CONFIG proxy.config.url_remap.filename STRING remap.config
> CONFIG proxy.config.log.config.filename STRING logging.config
> CONFIG proxy.config.log.collation_host STRING 192.168.2.33
> CONFIG proxy.config.log.collation_secret STRING testlog
> LOCAL proxy.local.log.collation_mode INT 2
> CONFIG proxy.config.log.collation_port INT 8085
> {code}
> config Collation Server
> {code:xml}
> CONFIG proxy.local.log.collation_mode INT 1
> CONFIG proxy.config.log.collation_port INT 8085
> CONFIG proxy.config.log.collation_secret STRING testlog
> {code}
> logging.config
> {code:xml}
> w3c = format {
>   Format='% %<{Cdn-Real-Ip}cqh> - % [%] \"% % 
> %\" % % \"%<{Referer}cqh>\" \"%<{user-agent}cqh>\" % 
> % % % % % %'
> }
> log.ascii {
>   Filename = 'c11',
>   Format = w3c,
>   CollationHosts = { '192.168.2.33:8085' }
> }
> {code}
> It still flush log to local disk not to remote collation server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1104: TS-4947: Fix log collation hosts configuration.

2016-10-18 Thread bryancall

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1104
  
Build and I ran the tests.  Code looks OK, but I don't know the lua API.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1097: Make the use of madvise() with MADV_DONTDU...

2016-10-18 Thread jrushford

Github user jrushford commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1097#discussion_r83866632
  
--- Diff: iocore/eventsystem/I_IOBuffer.h ---
@@ -58,6 +58,7 @@ class VIO;
 inkcoreapi extern int64_t max_iobuffer_size;
 extern int64_t default_small_iobuffer_size;
 extern int64_t default_large_iobuffer_size; // matched to size of OS 
buffers
+extern int iobuffer_advice;
--- End diff --

@jpeach I'd like to land this as is and write a JIRA to come back to the 
global variable once we've had time to evaluate this.  Are you okay with this?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc

2016-10-18 Thread Alan M. Carroll (JIRA)


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

Alan M. Carroll updated TS-4978:

Assignee: Syeda Persia Aziz  (was: Susan Hinrichs)

> CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE) in 
> iocore/net/SSLConfig.cc
> 
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252   ats_free(ssl_server_ca_cert_filename);
> 253   ats_free(CACertRelativePath);
> 254 
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256   REC_ReadConfigStringAlloc(ticket_key_filename, 
> "proxy.config.ssl.server.ticket_key.filename");
> 257   if (this->ticket_key_filename != NULL) {
>CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to 
> "relative_to".
> 258 ats_scoped_str 
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly, 
> this->ticket_key_filename));
> 259 default_global_keyblock = 
> ssl_create_ticket_keyblock(ticket_key_path);
> 260   } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262   }
> 263 #endif
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4970) Crash in INKVConnInternal when handle_event is called after destroy()

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4970?focusedWorklogId=30803=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30803
 ]

ASF GitHub Bot logged work on TS-4970:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 15:07
Start Date: 18/Oct/16 15:07
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
Not a complete solution as Thomas noted, but may be sufficient to keep 
6.2.x moving.  Alternatively, we may just want to back port TS-4590.


Issue Time Tracking
---

Worklog Id: (was: 30803)
Time Spent: 4h 40m  (was: 4.5h)

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.1.0
>
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = { = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1109: TS-4970: Crash in INKVConnInternal when handle_ev...

2016-10-18 Thread shinrich

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
Not a complete solution as Thomas noted, but may be sufficient to keep 
6.2.x moving.  Alternatively, we may just want to back port TS-4590.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4970) Crash in INKVConnInternal when handle_event is called after destroy()

2016-10-18 Thread Thomas Jackson (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15585605#comment-15585605
 ] 

Thomas Jackson commented on TS-4970:


Not duplicate as they are PRs against different branches, although I
imagine we won't back port to 5.2.x since it goes out of support in a
couple of weeks.




> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.1.0
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = { = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc

2016-10-18 Thread Alan M. Carroll (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15585649#comment-15585649
 ] 

Alan M. Carroll commented on TS-4978:
-

I changed my mind, I think Coverity might be on to something here. The intent 
of the code seems to be that erlier in this method {{cleanup}} is called which 
does {{free}} {{ticket_key_filename}}. Then {{REC_ReadConfigStringAlloc}} is 
called to get a newly allocated copy. However, {{ticket_key_filename}} is not 
reset after {{free}} and {{REC_ReadConfigStringAlloc}} does not update the 
pointer on failure. Therefore if {{ticket_key_filename}} was previously 
allocated and {{REC_ReadConfigStringAlloc}} fails a use after free could occur. 
One solution is to clear {{ticket_key_filename}}, another is to just the return 
value of {{REC_ReadConfigStringAlloc}} rather than check the value of 
{{ticket_key_filename}}.

> CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE) in 
> iocore/net/SSLConfig.cc
> 
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252   ats_free(ssl_server_ca_cert_filename);
> 253   ats_free(CACertRelativePath);
> 254 
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256   REC_ReadConfigStringAlloc(ticket_key_filename, 
> "proxy.config.ssl.server.ticket_key.filename");
> 257   if (this->ticket_key_filename != NULL) {
>CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to 
> "relative_to".
> 258 ats_scoped_str 
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly, 
> this->ticket_key_filename));
> 259 default_global_keyblock = 
> ssl_create_ticket_keyblock(ticket_key_path);
> 260   } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262   }
> 263 #endif
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc

2016-10-18 Thread Syeda Persia Aziz (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15586115#comment-15586115
 ] 

Syeda Persia Aziz commented on TS-4978:
---

Does Coverity complain about other such type of members like cipherSuite, 
serverCACertFilename etc.?

> CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE) in 
> iocore/net/SSLConfig.cc
> 
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252   ats_free(ssl_server_ca_cert_filename);
> 253   ats_free(CACertRelativePath);
> 254 
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256   REC_ReadConfigStringAlloc(ticket_key_filename, 
> "proxy.config.ssl.server.ticket_key.filename");
> 257   if (this->ticket_key_filename != NULL) {
>CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to 
> "relative_to".
> 258 ats_scoped_str 
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly, 
> this->ticket_key_filename));
> 259 default_global_keyblock = 
> ssl_create_ticket_keyblock(ticket_key_path);
> 260   } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262   }
> 263 #endif
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4980) Create ASAN leak suppression file for regression tests

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4980?focusedWorklogId=30823=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30823
 ]

ASF GitHub Bot logged work on TS-4980:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:55
Start Date: 18/Oct/16 17:55
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1118
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/934/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30823)
Time Spent: 0.5h  (was: 20m)

> Create ASAN leak suppression file for regression tests
> --
>
> Key: TS-4980
> URL: https://issues.apache.org/jira/browse/TS-4980
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently the regression tests leak memory when running.  It would be great 
> to make asan builds and run regression tests on ci.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4982) Fix memory leaks in test_Http2DependencyTree

2016-10-18 Thread Bryan Call (JIRA)


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

Bryan Call reassigned TS-4982:
--

Assignee: Bryan Call

> Fix memory leaks in test_Http2DependencyTree
> 
>
> Key: TS-4982
> URL: https://issues.apache.org/jira/browse/TS-4982
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
>
> {noformat}
> [bcall@homer http2]$ ./test_Http2DependencyTree
> REGRESSION_TEST initialization begun
> REGRESSION TEST Http2DependencyTree_max_depth started
> REGRESSION_RESULT Http2DependencyTree_max_depth:PASSED
> REGRESSION TEST Http2DependencyTree_remove_2 started
> REGRESSION_RESULT Http2DependencyTree_remove_2: PASSED
> REGRESSION TEST Http2DependencyTree_remove_1 started
> REGRESSION_RESULT Http2DependencyTree_remove_1: PASSED
> REGRESSION TEST Http2DependencyTree_Chrome_51 started
> REGRESSION_RESULT Http2DependencyTree_Chrome_51:PASSED
> REGRESSION TEST Http2DependencyTree_Chrome_50 started
> REGRESSION_RESULT Http2DependencyTree_Chrome_50:PASSED
> REGRESSION TEST Http2DependencyTree_6 started
> REGRESSION_RESULT Http2DependencyTree_6:PASSED
> REGRESSION TEST Http2DependencyTree_5 started
> REGRESSION_RESULT Http2DependencyTree_5:PASSED
> REGRESSION TEST Http2DependencyTree_4 started
> REGRESSION_RESULT Http2DependencyTree_4:PASSED
> REGRESSION TEST Http2DependencyTree_3 started
> REGRESSION_RESULT Http2DependencyTree_3:PASSED
> REGRESSION TEST Http2DependencyTree_2 started
> REGRESSION_RESULT Http2DependencyTree_2:PASSED
> REGRESSION TEST Http2DependencyTree_1 started
> REGRESSION_RESULT Http2DependencyTree_1:PASSED
> =
> ==16503==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x4032cc in 
> RegressionTest_Http2DependencyTree_max_depth(RegressionTest*, int, int*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:502
> #2 0x7f31159b39a8 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
> #3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
> #4 0x402034 in main 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
> #5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x41884f in 
> RegressionTest_Http2DependencyTree_remove_2(RegressionTest*, int, int*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:464
> #2 0x7f31159b39a8 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
> #3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
> #4 0x402034 in main 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
> #5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x413aaf in 
> RegressionTest_Http2DependencyTree_remove_1(RegressionTest*, int, int*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:410
> #2 0x7f31159b39a8 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
> #3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
> #4 0x402034 in main 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
> #5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Indirect leak of 14400 byte(s) in 200 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402d19 in Http2DependencyTree std::char_traits, std::allocator >*>::add(unsigned int, unsigned 
> int, unsigned int, bool, std::__cxx11::basic_string std::char_traits, std::allocator >*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/Http2DependencyTree.h:174
> #2 0x403602 in 
>

[jira] [Created] (TS-4982) Fix memory leaks in test_Http2DependencyTree

2016-10-18 Thread Bryan Call (JIRA)

Bryan Call created TS-4982:
--

 Summary: Fix memory leaks in test_Http2DependencyTree
 Key: TS-4982
 URL: https://issues.apache.org/jira/browse/TS-4982
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Bryan Call


{noformat}
[bcall@homer http2]$ ./test_Http2DependencyTree
REGRESSION_TEST initialization begun
REGRESSION TEST Http2DependencyTree_max_depth started
REGRESSION_RESULT Http2DependencyTree_max_depth:PASSED
REGRESSION TEST Http2DependencyTree_remove_2 started
REGRESSION_RESULT Http2DependencyTree_remove_2: PASSED
REGRESSION TEST Http2DependencyTree_remove_1 started
REGRESSION_RESULT Http2DependencyTree_remove_1: PASSED
REGRESSION TEST Http2DependencyTree_Chrome_51 started
REGRESSION_RESULT Http2DependencyTree_Chrome_51:PASSED
REGRESSION TEST Http2DependencyTree_Chrome_50 started
REGRESSION_RESULT Http2DependencyTree_Chrome_50:PASSED
REGRESSION TEST Http2DependencyTree_6 started
REGRESSION_RESULT Http2DependencyTree_6:PASSED
REGRESSION TEST Http2DependencyTree_5 started
REGRESSION_RESULT Http2DependencyTree_5:PASSED
REGRESSION TEST Http2DependencyTree_4 started
REGRESSION_RESULT Http2DependencyTree_4:PASSED
REGRESSION TEST Http2DependencyTree_3 started
REGRESSION_RESULT Http2DependencyTree_3:PASSED
REGRESSION TEST Http2DependencyTree_2 started
REGRESSION_RESULT Http2DependencyTree_2:PASSED
REGRESSION TEST Http2DependencyTree_1 started
REGRESSION_RESULT Http2DependencyTree_1:PASSED

=
==16503==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7f3115cc2ea0 in operator new(unsigned long) 
(/lib64/libasan.so.3+0xc7ea0)
#1 0x4032cc in 
RegressionTest_Http2DependencyTree_max_depth(RegressionTest*, int, int*) 
/home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:502
#2 0x7f31159b39a8 in start_test 
/home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
#3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
/home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
#4 0x402034 in main 
/home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
#5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)

Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7f3115cc2ea0 in operator new(unsigned long) 
(/lib64/libasan.so.3+0xc7ea0)
#1 0x41884f in RegressionTest_Http2DependencyTree_remove_2(RegressionTest*, 
int, int*) 
/home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:464
#2 0x7f31159b39a8 in start_test 
/home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
#3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
/home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
#4 0x402034 in main 
/home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
#5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)

Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7f3115cc2ea0 in operator new(unsigned long) 
(/lib64/libasan.so.3+0xc7ea0)
#1 0x413aaf in RegressionTest_Http2DependencyTree_remove_1(RegressionTest*, 
int, int*) 
/home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:410
#2 0x7f31159b39a8 in start_test 
/home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
#3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
/home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
#4 0x402034 in main 
/home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
#5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)

Indirect leak of 14400 byte(s) in 200 object(s) allocated from:
#0 0x7f3115cc2ea0 in operator new(unsigned long) 
(/lib64/libasan.so.3+0xc7ea0)
#1 0x402d19 in Http2DependencyTree*>::add(unsigned int, unsigned 
int, unsigned int, bool, std::__cxx11::basic_string*) 
/home/bcall/dev/apache/trafficserver/proxy/http2/Http2DependencyTree.h:174
#2 0x403602 in 
RegressionTest_Http2DependencyTree_max_depth(RegressionTest*, int, int*) 
/home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:506
#3 0x7f31159b39a8 in start_test 
/home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
#4 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
/home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
#5 0x402034 in main 
/home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
#6

[jira] [Updated] (TS-4982) Fix memory leaks in test_Http2DependencyTree

2016-10-18 Thread Bryan Call (JIRA)


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

Bryan Call updated TS-4982:
---
Fix Version/s: 7.1.0

> Fix memory leaks in test_Http2DependencyTree
> 
>
> Key: TS-4982
> URL: https://issues.apache.org/jira/browse/TS-4982
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
>
> {noformat}
> [bcall@homer http2]$ ./test_Http2DependencyTree
> REGRESSION_TEST initialization begun
> REGRESSION TEST Http2DependencyTree_max_depth started
> REGRESSION_RESULT Http2DependencyTree_max_depth:PASSED
> REGRESSION TEST Http2DependencyTree_remove_2 started
> REGRESSION_RESULT Http2DependencyTree_remove_2: PASSED
> REGRESSION TEST Http2DependencyTree_remove_1 started
> REGRESSION_RESULT Http2DependencyTree_remove_1: PASSED
> REGRESSION TEST Http2DependencyTree_Chrome_51 started
> REGRESSION_RESULT Http2DependencyTree_Chrome_51:PASSED
> REGRESSION TEST Http2DependencyTree_Chrome_50 started
> REGRESSION_RESULT Http2DependencyTree_Chrome_50:PASSED
> REGRESSION TEST Http2DependencyTree_6 started
> REGRESSION_RESULT Http2DependencyTree_6:PASSED
> REGRESSION TEST Http2DependencyTree_5 started
> REGRESSION_RESULT Http2DependencyTree_5:PASSED
> REGRESSION TEST Http2DependencyTree_4 started
> REGRESSION_RESULT Http2DependencyTree_4:PASSED
> REGRESSION TEST Http2DependencyTree_3 started
> REGRESSION_RESULT Http2DependencyTree_3:PASSED
> REGRESSION TEST Http2DependencyTree_2 started
> REGRESSION_RESULT Http2DependencyTree_2:PASSED
> REGRESSION TEST Http2DependencyTree_1 started
> REGRESSION_RESULT Http2DependencyTree_1:PASSED
> =
> ==16503==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x4032cc in 
> RegressionTest_Http2DependencyTree_max_depth(RegressionTest*, int, int*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:502
> #2 0x7f31159b39a8 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
> #3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
> #4 0x402034 in main 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
> #5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x41884f in 
> RegressionTest_Http2DependencyTree_remove_2(RegressionTest*, int, int*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:464
> #2 0x7f31159b39a8 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
> #3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
> #4 0x402034 in main 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
> #5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x413aaf in 
> RegressionTest_Http2DependencyTree_remove_1(RegressionTest*, int, int*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:410
> #2 0x7f31159b39a8 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
> #3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
> #4 0x402034 in main 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
> #5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Indirect leak of 14400 byte(s) in 200 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402d19 in Http2DependencyTree std::char_traits, std::allocator >*>::add(unsigned int, unsigned 
> int, unsigned int, bool, std::__cxx11::basic_string std::char_traits, std::allocator >*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/Http2DependencyTree.h:174
> #2 0x403602 in 
> RegressionTest_Http2DependencyTree_max_depth(RegressionTest*, int,

[jira] [Updated] (TS-4982) Fix memory leaks in test_Http2DependencyTree

2016-10-18 Thread Bryan Call (JIRA)


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

Bryan Call updated TS-4982:
---
Component/s: Tests
 HTTP/2

> Fix memory leaks in test_Http2DependencyTree
> 
>
> Key: TS-4982
> URL: https://issues.apache.org/jira/browse/TS-4982
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
>
> {noformat}
> [bcall@homer http2]$ ./test_Http2DependencyTree
> REGRESSION_TEST initialization begun
> REGRESSION TEST Http2DependencyTree_max_depth started
> REGRESSION_RESULT Http2DependencyTree_max_depth:PASSED
> REGRESSION TEST Http2DependencyTree_remove_2 started
> REGRESSION_RESULT Http2DependencyTree_remove_2: PASSED
> REGRESSION TEST Http2DependencyTree_remove_1 started
> REGRESSION_RESULT Http2DependencyTree_remove_1: PASSED
> REGRESSION TEST Http2DependencyTree_Chrome_51 started
> REGRESSION_RESULT Http2DependencyTree_Chrome_51:PASSED
> REGRESSION TEST Http2DependencyTree_Chrome_50 started
> REGRESSION_RESULT Http2DependencyTree_Chrome_50:PASSED
> REGRESSION TEST Http2DependencyTree_6 started
> REGRESSION_RESULT Http2DependencyTree_6:PASSED
> REGRESSION TEST Http2DependencyTree_5 started
> REGRESSION_RESULT Http2DependencyTree_5:PASSED
> REGRESSION TEST Http2DependencyTree_4 started
> REGRESSION_RESULT Http2DependencyTree_4:PASSED
> REGRESSION TEST Http2DependencyTree_3 started
> REGRESSION_RESULT Http2DependencyTree_3:PASSED
> REGRESSION TEST Http2DependencyTree_2 started
> REGRESSION_RESULT Http2DependencyTree_2:PASSED
> REGRESSION TEST Http2DependencyTree_1 started
> REGRESSION_RESULT Http2DependencyTree_1:PASSED
> =
> ==16503==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x4032cc in 
> RegressionTest_Http2DependencyTree_max_depth(RegressionTest*, int, int*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:502
> #2 0x7f31159b39a8 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
> #3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
> #4 0x402034 in main 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
> #5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x41884f in 
> RegressionTest_Http2DependencyTree_remove_2(RegressionTest*, int, int*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:464
> #2 0x7f31159b39a8 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
> #3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
> #4 0x402034 in main 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
> #5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x413aaf in 
> RegressionTest_Http2DependencyTree_remove_1(RegressionTest*, int, int*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:410
> #2 0x7f31159b39a8 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:81
> #3 0x7f31159b39a8 in RegressionTest::run(char const*, int) 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:103
> #4 0x402034 in main 
> /home/bcall/dev/apache/trafficserver/proxy/http2/test_Http2DependencyTree.cc:517
> #5 0x7f3112f3b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Indirect leak of 14400 byte(s) in 200 object(s) allocated from:
> #0 0x7f3115cc2ea0 in operator new(unsigned long) 
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402d19 in Http2DependencyTree std::char_traits, std::allocator >*>::add(unsigned int, unsigned 
> int, unsigned int, bool, std::__cxx11::basic_string std::char_traits, std::allocator >*) 
> /home/bcall/dev/apache/trafficserver/proxy/http2/Http2DependencyTree.h:174
> #2 0x403602 in 
>

[GitHub] trafficserver issue #1118: TS-4980: Create ASAN leak suppression file for re...

2016-10-18 Thread bryancall

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1118
  
Added 2 more lines for -R 3


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1097: Make the use of madvise() with MADV_DONTDUMP conf...

2016-10-18 Thread jrushford

Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/1097
  
@jpeach and @PSUdaemon - I've made iobuffer_advice a local variable.  
Tested and it is working okay.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4979) clang-analyzer error in HttpTransact.cc

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4979?focusedWorklogId=30812=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30812
 ]

ASF GitHub Bot logged work on TS-4979:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:05
Start Date: 18/Oct/16 17:05
Worklog Time Spent: 10m 
  Work Description: Github user SolidWallOfCode commented on a diff in the 
pull request:

https://github.com/apache/trafficserver/pull/1116#discussion_r83902560
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -1075,6 +1073,8 @@ HttpTransact::ModifyRequest(State *s)
   if (!request.is_target_in_url()) {
 s->hdr_info.client_req_is_server_style = true;
   }
+  // Make Coverity happy. hostname is non-null iff 
request.is_target_in_url().
--- End diff --

It's just who we are.


Issue Time Tracking
---

Worklog Id: (was: 30812)
Time Spent: 1h  (was: 50m)

> clang-analyzer error in HttpTransact.cc
> ---
>
> Key: TS-4979
> URL: https://issues.apache.org/jira/browse/TS-4979
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {code}
> if (mimefield_value_equal(host_field, *host_val, host_val_len) == false) {
> 7
> ←
> Passing null pointer value via 2nd parameter 'value'  
> →
> 8
> ←
> Calling 'mimefield_value_equal'   
> →
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1116: TS-4979: Fix clang-analyzer complaint abou...

2016-10-18 Thread SolidWallOfCode

Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1116#discussion_r83902560
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -1075,6 +1073,8 @@ HttpTransact::ModifyRequest(State *s)
   if (!request.is_target_in_url()) {
 s->hdr_info.client_req_is_server_style = true;
   }
+  // Make Coverity happy. hostname is non-null iff 
request.is_target_in_url().
--- End diff --

It's just who we are.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

2016-10-18 Thread Susan Hinrichs (JIRA)


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

Susan Hinrichs updated TS-4813:
---
Backport to Version: 6.2.1

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>Priority: Blocker
>  Labels: crash
> Fix For: 7.0.0
>
>  Time Spent: 5h 10m
>  Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4980) Create ASAN leak suppression file for regression tests

2016-10-18 Thread Bryan Call (JIRA)

Bryan Call created TS-4980:
--

 Summary: Create ASAN leak suppression file for regression tests
 Key: TS-4980
 URL: https://issues.apache.org/jira/browse/TS-4980
 Project: Traffic Server
  Issue Type: Improvement
  Components: Tests
Reporter: Bryan Call


Currently the regression tests leak memory when running.  It would be great to 
make asan builds and run regression tests on ci.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30814=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30814
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:21
Start Date: 18/Oct/16 17:21
Worklog Time Spent: 10m 
  Work Description: GitHub user gtenev opened a pull request:

https://github.com/apache/trafficserver/pull/1117

TS-4916 Add safety net to avoid H2-infinite-loop deadlock.

Current Http2ConnectionState implementation uses a memory pool for
instantiating streams and DLL<> stream_list for storing active streams.
Destroying a stream before deleting it from stream_list and then creating
a new one + reusing the same chunk from the memory pool right away always
leads to destroying the DLL structure (deadlocks, inconsistencies).
Added a safety net since the consequences are disastrous.
Until the design/implementation changes it seems less error prone
to (double) delete before destroying (noop if already deleted).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gtenev/trafficserver TS-4916-master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1117.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1117


commit ed72728800fb3a5387172644b1cc586b74c4f0a0
Author: Gancho Tenev 
Date:   2016-10-17T22:10:12Z

TS-4916 Add safety net to avoid H2-infinite-loop deadlock.

Current Http2ConnectionState implementation uses a memory pool for
instantiating streams and DLL<> stream_list for storing active streams.
Destroying a stream before deleting it from stream_list and then creating
a new one + reusing the same chunk from the memory pool right away always
leads to destroying the DLL structure (deadlocks, inconsistencies).
Added a safety net since the consequences are disastrous.
Until the design/implementation changes it seems less error prone
to (double) delete before destroying (noop if already deleted).




Issue Time Tracking
---

Worklog Id: (was: 30814)
Time Spent: 5h 10m  (was: 5h)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 5h 10m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
>

[GitHub] trafficserver pull request #1118: TS-4980: Create ASAN leak suppression file...

2016-10-18 Thread bryancall

GitHub user bryancall opened a pull request:

https://github.com/apache/trafficserver/pull/1118

TS-4980: Create ASAN leak suppression file for regression tests



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bryancall/trafficserver TS-4980

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1118.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1118


commit 59de84b233fcd58faf6fc0c4b141090b119f16ad
Author: Bryan Call 
Date:   2016-10-18T17:36:02Z

TS-4980: Create ASAN leak suppression file for regression tests




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30820=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30820
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:38
Start Date: 18/Oct/16 17:38
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1117
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1041/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30820)
Time Spent: 6h 10m  (was: 6h)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 6h 10m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
>

[GitHub] trafficserver issue #1117: TS-4916 Add safety net to avoid H2-infinite-loop ...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1117
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1041/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4980) Create ASAN leak suppression file for regression tests

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4980?focusedWorklogId=30821=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30821
 ]

ASF GitHub Bot logged work on TS-4980:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:39
Start Date: 18/Oct/16 17:39
Worklog Time Spent: 10m 
  Work Description: GitHub user bryancall opened a pull request:

https://github.com/apache/trafficserver/pull/1118

TS-4980: Create ASAN leak suppression file for regression tests



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bryancall/trafficserver TS-4980

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1118.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1118


commit 59de84b233fcd58faf6fc0c4b141090b119f16ad
Author: Bryan Call 
Date:   2016-10-18T17:36:02Z

TS-4980: Create ASAN leak suppression file for regression tests




Issue Time Tracking
---

Worklog Id: (was: 30821)
Time Spent: 10m
Remaining Estimate: 0h

> Create ASAN leak suppression file for regression tests
> --
>
> Key: TS-4980
> URL: https://issues.apache.org/jira/browse/TS-4980
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the regression tests leak memory when running.  It would be great 
> to make asan builds and run regression tests on ci.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4981) Create ASAN builds for CI

2016-10-18 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom updated TS-4981:
--
Fix Version/s: Infrastructure

> Create ASAN builds for CI
> -
>
> Key: TS-4981
> URL: https://issues.apache.org/jira/browse/TS-4981
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: CI, Tests
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: Infrastructure
>
>
> Create ASAN builds to check for memory issues and memory leaks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1118: TS-4980: Create ASAN leak suppression file for re...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1118
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1042/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1118: TS-4980: Create ASAN leak suppression file for re...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1118
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/934/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1097: Make the use of madvise() with MADV_DONTDUMP conf...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1097
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/936/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1116: TS-4979: Fix clang-analyzer complaint abou...

2016-10-18 Thread SolidWallOfCode

Github user SolidWallOfCode closed the pull request at:

https://github.com/apache/trafficserver/pull/1116


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1117: TS-4916 Add safety net to avoid H2-infinit...

2016-10-18 Thread gtenev

GitHub user gtenev opened a pull request:

https://github.com/apache/trafficserver/pull/1117

TS-4916 Add safety net to avoid H2-infinite-loop deadlock.

Current Http2ConnectionState implementation uses a memory pool for
instantiating streams and DLL<> stream_list for storing active streams.
Destroying a stream before deleting it from stream_list and then creating
a new one + reusing the same chunk from the memory pool right away always
leads to destroying the DLL structure (deadlocks, inconsistencies).
Added a safety net since the consequences are disastrous.
Until the design/implementation changes it seems less error prone
to (double) delete before destroying (noop if already deleted).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gtenev/trafficserver TS-4916-master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1117.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1117


commit ed72728800fb3a5387172644b1cc586b74c4f0a0
Author: Gancho Tenev 
Date:   2016-10-17T22:10:12Z

TS-4916 Add safety net to avoid H2-infinite-loop deadlock.

Current Http2ConnectionState implementation uses a memory pool for
instantiating streams and DLL<> stream_list for storing active streams.
Destroying a stream before deleting it from stream_list and then creating
a new one + reusing the same chunk from the memory pool right away always
leads to destroying the DLL structure (deadlocks, inconsistencies).
Added a safety net since the consequences are disastrous.
Until the design/implementation changes it seems less error prone
to (double) delete before destroying (noop if already deleted).




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30815=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30815
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:24
Start Date: 18/Oct/16 17:24
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1117
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/932/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30815)
Time Spent: 5h 20m  (was: 5h 10m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 5h 20m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900

[GitHub] trafficserver issue #1117: TS-4916 Add safety net to avoid H2-infinite-loop ...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1117
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/932/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1117: TS-4916 Add safety net to avoid H2-infinite-loop ...

2016-10-18 Thread bryancall

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1117
  
ð - Looks good


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1097: Make the use of madvise() with MADV_DONTDUMP conf...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1097
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1040/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4980) Create ASAN leak suppression file for regression tests

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4980?focusedWorklogId=30822=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30822
 ]

ASF GitHub Bot logged work on TS-4980:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:51
Start Date: 18/Oct/16 17:51
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1118
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1042/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30822)
Time Spent: 20m  (was: 10m)

> Create ASAN leak suppression file for regression tests
> --
>
> Key: TS-4980
> URL: https://issues.apache.org/jira/browse/TS-4980
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the regression tests leak memory when running.  It would be great 
> to make asan builds and run regression tests on ci.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4980) Create ASAN leak suppression file for regression tests

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4980?focusedWorklogId=30826=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30826
 ]

ASF GitHub Bot logged work on TS-4980:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 18:26
Start Date: 18/Oct/16 18:26
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1118
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1043/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30826)
Time Spent: 50m  (was: 40m)

> Create ASAN leak suppression file for regression tests
> --
>
> Key: TS-4980
> URL: https://issues.apache.org/jira/browse/TS-4980
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Currently the regression tests leak memory when running.  It would be great 
> to make asan builds and run regression tests on ci.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4980) Create ASAN leak suppression file for regression tests

2016-10-18 Thread Bryan Call (JIRA)


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

Bryan Call reassigned TS-4980:
--

Assignee: Bryan Call

> Create ASAN leak suppression file for regression tests
> --
>
> Key: TS-4980
> URL: https://issues.apache.org/jira/browse/TS-4980
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
>
> Currently the regression tests leak memory when running.  It would be great 
> to make asan builds and run regression tests on ci.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30816=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30816
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:27
Start Date: 18/Oct/16 17:27
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1117
  
 - Looks good


Issue Time Tracking
---

Worklog Id: (was: 30816)
Time Spent: 5.5h  (was: 5h 20m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 5.5h
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900
> next=0x2ae5b6bbec00
> prev=0x2ae673f0c840
> --- count=2 ---
> id=19
>

Jenkins build is back to normal : clang-analyzer #2712

2016-10-18 Thread jenkins

See

[jira] [Work logged] (TS-4980) Create ASAN leak suppression file for regression tests

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4980?focusedWorklogId=30824=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30824
 ]

ASF GitHub Bot logged work on TS-4980:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 18:16
Start Date: 18/Oct/16 18:16
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1118
  
Added 2 more lines for -R 3


Issue Time Tracking
---

Worklog Id: (was: 30824)
Time Spent: 40m  (was: 0.5h)

> Create ASAN leak suppression file for regression tests
> --
>
> Key: TS-4980
> URL: https://issues.apache.org/jira/browse/TS-4980
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the regression tests leak memory when running.  It would be great 
> to make asan builds and run regression tests on ci.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1118: TS-4980: Create ASAN leak suppression file for re...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1118
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1043/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1118: TS-4980: Create ASAN leak suppression file for re...

2016-10-18 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1118
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/935/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4980) Create ASAN leak suppression file for regression tests

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4980?focusedWorklogId=30827=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30827
 ]

ASF GitHub Bot logged work on TS-4980:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 18:29
Start Date: 18/Oct/16 18:29
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1118
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/935/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30827)
Time Spent: 1h  (was: 50m)

> Create ASAN leak suppression file for regression tests
> --
>
> Key: TS-4980
> URL: https://issues.apache.org/jira/browse/TS-4980
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Currently the regression tests leak memory when running.  It would be great 
> to make asan builds and run regression tests on ci.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4979) clang-analyzer error in HttpTransact.cc

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4979?focusedWorklogId=30813=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30813
 ]

ASF GitHub Bot logged work on TS-4979:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:05
Start Date: 18/Oct/16 17:05
Worklog Time Spent: 10m 
  Work Description: Github user SolidWallOfCode closed the pull request at:

https://github.com/apache/trafficserver/pull/1116


Issue Time Tracking
---

Worklog Id: (was: 30813)
Time Spent: 1h 10m  (was: 1h)

> clang-analyzer error in HttpTransact.cc
> ---
>
> Key: TS-4979
> URL: https://issues.apache.org/jira/browse/TS-4979
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {code}
> if (mimefield_value_equal(host_field, *host_val, host_val_len) == false) {
> 7
> ←
> Passing null pointer value via 2nd parameter 'value'  
> →
> 8
> ←
> Calling 'mimefield_value_equal'   
> →
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1117: TS-4916 Add safety net to avoid H2-infinit...

2016-10-18 Thread zwoop

Github user zwoop commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1117#discussion_r83908521
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -675,6 +675,17 @@ Http2Stream::destroy()
   }
   chunked_handler.clear();
   super::destroy();
+
+  // Current Http2ConnectionState implementation uses a memory pool for 
instantiating streams and DLL<> stream_list for storing
+  // active streams. Destroying a stream before deleting it from 
stream_list and then creating a new one + reusing the same chunk
+  // from the memory pool right away always leads to destroying the DLL 
structure (deadlocks, inconsistencies).
+  // The following is meant as a safety net since the consequences are 
disastrous. Until the design/implementation changes it seems
+  // less error prone to (double) delete before destroying (noop if 
already deleted).
+  if (parent) {
+static_cast(parent)->connection_state.delete_stream(this);
+Warning("Http2Stream was about to be deallocated without removing it 
from the active stream list");
--- End diff --

We are sure this is not going to produce a lot of warnings, right ? :)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...

2016-10-18 Thread gtenev

Github user gtenev closed the pull request at:

https://github.com/apache/trafficserver/pull/1100


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30819=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30819
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:34
Start Date: 18/Oct/16 17:34
Worklog Time Spent: 10m 
  Work Description: Github user gtenev closed the pull request at:

https://github.com/apache/trafficserver/pull/1100


Issue Time Tracking
---

Worklog Id: (was: 30819)
Time Spent: 6h  (was: 5h 50m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 6h
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900
> next=0x2ae5b6bbec00
> prev=0x2ae673f0c840
> --- count=2 ---
> id=19
> this=0x2ae5b6bbec00
>

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

2016-10-18 Thread gtenev

Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Chatted with @shinrich offline and she is going to mark related fixes 
TS-4813 and TS-4507 for backport from 7.0.0 to 6.2.1, which should take care of 
the "missing to delete the stream cases". 

Submitted a new PR against master #1117 to add the "safety net" delete 
stream call in `destroy()` before `THREAD_FREE()` and backport to 6.2.1 
(changes are not 6.2.1 specific anymore).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

2016-10-18 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30818=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30818
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 18/Oct/16 17:34
Start Date: 18/Oct/16 17:34
Worklog Time Spent: 10m 
  Work Description: Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Chatted with @shinrich offline and she is going to mark related fixes 
TS-4813 and TS-4507 for backport from 7.0.0 to 6.2.1, which should take care of 
the "missing to delete the stream cases". 

Submitted a new PR against master #1117 to add the "safety net" delete 
stream call in `destroy()` before `THREAD_FREE()` and backport to 6.2.1 
(changes are not 6.2.1 specific anymore).


Issue Time Tracking
---

Worklog Id: (was: 30818)
Time Spent: 5h 50m  (was: 5h 40m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 5h 50m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0

1 2 3 >

1 - 100 of 221 matches

Mail list logo