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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1108
  
@jpeach yes, although since 5.2.x drops support in the next month-- its 
probably not work backporting to the 5.2.x branch-- there is another PR for 
6.2.x.


Issue Time Tracking
---

Worklog Id: (was: 30710)
Time Spent: 3h 20m  (was: 3h 10m)

> 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
>  Time Spent: 3h 20m
>  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 #1108: TS-4970: Crash in INKVConnInternal when handle_ev...

[jacksontj]

Github user jacksontj commented on the issue:

https://github.com/apache/trafficserver/pull/1108
  
@jpeach yes, although since 5.2.x drops support in the next month-- its 
probably not work backporting to the 5.2.x branch-- there is another PR for 
6.2.x.


---
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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30709)
Time Spent: 2.5h  (was: 2h 20m)

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver issue #1110: TS-4971: Change TSPluginRegistration to be const.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1027/ 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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1110
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1026/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30708)
Time Spent: 2h 20m  (was: 2h 10m)

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver issue #1110: TS-4971: Change TSPluginRegistration to be const.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1026/ 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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30707)
Time Spent: 2h 10m  (was: 2h)

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver issue #1110: TS-4971: Change TSPluginRegistration to be const.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1025/ 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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1110
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1025/ for details.
 



Issue Time Tracking
---

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

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver issue #1110: TS-4971: Change TSPluginRegistration to be const.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/919/ 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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver issue #1110: TS-4971: Change TSPluginRegistration to be const.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/917/ 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-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1100
  
I was actually thinking to propose just adding a “catch-all-delete-stream” 
call in `destroy()` before `THREAD_FREE()` in 7.0.

It seems to me that the point of this Jira TS-4813 / this PR got somehow 
lost so I would like to reiterate.

Missing a stream deletion from `DLL<>` before calling `THREAD_FREE()` COULD 
lead to breaking the `DLL<>` and then if that happens `DLL<>` traversals ALWAYS 
ends up in infinite loop. 

Host became dysfunctional pretty often because of this (time to live 1-3 
days per host) and it took long time to debug/prove.

This is my (practical?) attempt to make sure we don’t get stuck in this 
debugging again regardless of past/current/future “delete stream” bugs (as long 
us we use `THREAD_ALLOC_INIT/THREAD_FREE` + `DLL<>` of course). 

I wanted to propose a "catch-all-delete-stream" safety net in both 6.2.1 
and 7.0.0 because I think it would be hard to guarantee that the next commit 
would not introduce this weakness again.

This is my first read of the H2 code so I can see how the proposed fix can 
be sub-optimal and will gladly change it, I also hope I provided enough 
reasoning for best results :).

I am pretty confident in my debugging data/conclusions but just by reading 
the code or by sorting through Jiras that “may help” I can only guess if the 
new 7.0 version or back-ports to 6.2.1 definitely fix the issue until I 
test/verify.

We could close this PR:
- If we are confident all “fixes in this area” from 7.0 can be back-ported 
to 6.2.1 and that the issue will be fixed 
- AND If adding the proposed safety net does not make any/enough sense

Cheers!




Issue Time Tracking
---

Worklog Id: (was: 30704)
Time Spent: 5h  (was: 4h 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: 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, 

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

[gtenev]

Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
I was actually thinking to propose just adding a 
“catch-all-delete-stream” call in `destroy()` before `THREAD_FREE()` in 7.0.

It seems to me that the point of this Jira TS-4813 / this PR got somehow 
lost so I would like to reiterate.

Missing a stream deletion from `DLL<>` before calling `THREAD_FREE()` COULD 
lead to breaking the `DLL<>` and then if that happens `DLL<>` traversals ALWAYS 
ends up in infinite loop. 

Host became dysfunctional pretty often because of this (time to live 1-3 
days per host) and it took long time to debug/prove.

This is my (practical?) attempt to make sure we don’t get stuck in this 
debugging again regardless of past/current/future “delete stream” bugs (as 
long us we use `THREAD_ALLOC_INIT/THREAD_FREE` + `DLL<>` of course). 

I wanted to propose a "catch-all-delete-stream" safety net in both 6.2.1 
and 7.0.0 because I think it would be hard to guarantee that the next commit 
would not introduce this weakness again.

This is my first read of the H2 code so I can see how the proposed fix can 
be sub-optimal and will gladly change it, I also hope I provided enough 
reasoning for best results :).

I am pretty confident in my debugging data/conclusions but just by reading 
the code or by sorting through Jiras that “may help” I can only guess if 
the new 7.0 version or back-ports to 6.2.1 definitely fix the issue until I 
test/verify.

We could close this PR:
- If we are confident all “fixes in this area” from 7.0 can be 
back-ported to 6.2.1 and that the issue will be fixed 
- AND If adding the proposed safety net does not make any/enough sense

Cheers!




---
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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30703)
Time Spent: 1h 40m  (was: 1.5h)

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver issue #1110: TS-4971: Change TSPluginRegistration to be const.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/918/ 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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver issue #1110: TS-4971: Change TSPluginRegistration to be const.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/916/ 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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1110
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1024/ for details.
 



Issue Time Tracking
---

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

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver issue #1110: TS-4971: Change TSPluginRegistration to be const.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1024/ 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-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83512075
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -267,10 +267,12 @@ Http2Stream::do_io_close(int /* flags */)
   // Make sure any trailing end of stream frames are sent
   // Ourselve will be removed at send_data_frames or closing 
connection phase
   static_cast(parent)->connection_state.send_data_frames(this);
+
+  // Make sure the stream is deleted at this point since next step is 
self destroy.
+  this->delete_stream();
--- End diff --

This is what actually made sure we delete the stream from the `DLL<>` 
before  triggering `destroy()` (before leaving `do_io_close()`).

In the version 6.2.1 we have `send_data_frames()` delete the stream from 
`DLL<>` on `HTTP2_STREAM_STATE_CLOSED`.

Then in a later version we added `HTTP2_STREAM_STATE_HALF_CLOSED_LOCAL`. 

What caused the destroying of `DLL<>` in our case was 
`HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE` (which does not cause deletion in any 
version).

It seemed to me we have been always vulnerable to this problem despite the 
fixes. That is why I thought I would add this “catch-all-delete-stream” line 
here for all the current and future missing states. After this point we are 
going to `destroy()` the stream  regardless of its state anyway.



Issue Time Tracking
---

Worklog Id: (was: 30700)
Time Spent: 4h 50m  (was: 4h 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: 4h 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 

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1109
  
@shinrich we could-- this patch seems to be working fine for our build 
though-- seemed like a less intrusive patch to an LTS release.


Issue Time Tracking
---

Worklog Id: (was: 30699)
Time Spent: 3h 10m  (was: 3h)

> 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
>  Time Spent: 3h 10m
>  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 #1100: TS-4916: Fix for an H2-infinite-loop deadl...

[gtenev]

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83512075
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -267,10 +267,12 @@ Http2Stream::do_io_close(int /* flags */)
   // Make sure any trailing end of stream frames are sent
   // Ourselve will be removed at send_data_frames or closing 
connection phase
   static_cast(parent)->connection_state.send_data_frames(this);
+
+  // Make sure the stream is deleted at this point since next step is 
self destroy.
+  this->delete_stream();
--- End diff --

This is what actually made sure we delete the stream from the `DLL<>` 
before  triggering `destroy()` (before leaving `do_io_close()`).

In the version 6.2.1 we have `send_data_frames()` delete the stream from 
`DLL<>` on `HTTP2_STREAM_STATE_CLOSED`.

Then in a later version we added `HTTP2_STREAM_STATE_HALF_CLOSED_LOCAL`. 

What caused the destroying of `DLL<>` in our case was 
`HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE` (which does not cause deletion in any 
version).

It seemed to me we have been always vulnerable to this problem despite the 
fixes. That is why I thought I would add this “catch-all-delete-stream” 
line here for all the current and future missing states. After this point we 
are going to `destroy()` the stream  regardless of its state anyway.



---
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 #1109: TS-4970: Crash in INKVConnInternal when handle_ev...

[jacksontj]

Github user jacksontj commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
@shinrich we could-- this patch seems to be working fine for our build 
though-- seemed like a less intrusive patch to an LTS release.


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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83511226
  
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -1097,6 +1141,7 @@ void
 Http2ConnectionState::send_data_frames(Http2Stream *stream)
 {
   if (stream->get_state() == HTTP2_STREAM_STATE_CLOSED) {
+this->delete_stream(stream);
 return;
--- End diff --

No, I may have overdone it here. 

I thought I would add this deletion because few lines below there is 
deleting if state == `HTTP2_STREAM_STATE_CLOSED`. `send_data_frames()` is 
called not only from `do_io_close()`, and calling `delete_stream()` on already 
deleted stream is OK (with this change).



Issue Time Tracking
---

Worklog Id: (was: 30698)
Time Spent: 4h 40m  (was: 4.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: 4h 40m
>  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 

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

[gtenev]

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83511226
  
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -1097,6 +1141,7 @@ void
 Http2ConnectionState::send_data_frames(Http2Stream *stream)
 {
   if (stream->get_state() == HTTP2_STREAM_STATE_CLOSED) {
+this->delete_stream(stream);
 return;
--- End diff --

No, I may have overdone it here. 

I thought I would add this deletion because few lines below there is 
deleting if state == `HTTP2_STREAM_STATE_CLOSED`. `send_data_frames()` is 
called not only from `do_io_close()`, and calling `delete_stream()` on already 
deleted stream is OK (with this change).



---
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 #1112: RFC: Prefer nullptr to NULL.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1112
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1023/ 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 #1100: TS-4916: Fix for an H2-infinite-loop deadl...

[gtenev]

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83510837
  
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -936,30 +940,70 @@ Http2ConnectionState::cleanup_streams()
 void
 Http2ConnectionState::delete_stream(Http2Stream *stream)
 {
+  // The following check allows the method to be called safely on already 
deleted streams.
+  if (deleted_from_active_streams(stream)) {
+return;
+  }
+
+  SCOPED_MUTEX_LOCK(lock, this->mutex, this_ethread());
+
--- End diff --

If we are sure `DLL<>` is always protected by a lock then I must have 
really misunderstood this previous [comment on 
TS-4916](https://issues.apache.org/jira/browse/TS-4916?focusedCommentId=15552505=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15552505])
 where we suspected `DLL<>` to be “manipulated by simultaneous threads”.

That would mean that at least in one thread was not holding the right lock. 
In that case would not that mean that “rearranging some of the stream_count 
book keeping” would rather hide the problem than to fix it?

Trying to help based on the comment decided to trace few paths in the 
source code that may not be holding ConnectionState lock (theoretically) and 
grabbed the lock on the common path closest to the structures that needed 
protection (which based on my understanding should not be a problem if the 
thread is already holding the lock).

Actually never noticed the race condition in my debugging so I am going to 
remove this line from the PR and I will consider limiting my future changes to 
the issue I am trying to fix.



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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83510837
  
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -936,30 +940,70 @@ Http2ConnectionState::cleanup_streams()
 void
 Http2ConnectionState::delete_stream(Http2Stream *stream)
 {
+  // The following check allows the method to be called safely on already 
deleted streams.
+  if (deleted_from_active_streams(stream)) {
+return;
+  }
+
+  SCOPED_MUTEX_LOCK(lock, this->mutex, this_ethread());
+
--- End diff --

If we are sure `DLL<>` is always protected by a lock then I must have 
really misunderstood this previous [comment on 
TS-4916](https://issues.apache.org/jira/browse/TS-4916?focusedCommentId=15552505=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15552505])
 where we suspected `DLL<>` to be “manipulated by simultaneous threads”.

That would mean that at least in one thread was not holding the right lock. 
In that case would not that mean that “rearranging some of the stream_count 
book keeping” would rather hide the problem than to fix it?

Trying to help based on the comment decided to trace few paths in the 
source code that may not be holding ConnectionState lock (theoretically) and 
grabbed the lock on the common path closest to the structures that needed 
protection (which based on my understanding should not be a problem if the 
thread is already holding the lock).

Actually never noticed the race condition in my debugging so I am going to 
remove this line from the PR and I will consider limiting my future changes to 
the issue I am trying to fix.



Issue Time Tracking
---

Worklog Id: (was: 30697)
Time Spent: 4.5h  (was: 4h 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: 4.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 
> 

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1073#discussion_r83509798
  
--- Diff: cmd/traffic_manager/traffic_manager.cc ---
@@ -835,10 +824,11 @@ main(int argc, const char **argv)
   } else {
 sleep_time = 1;
   }
-  if (lmgmt->startProxy()) {
+  if (ProxyStateSet(TS_PROXY_ON, TS_CACHE_CLEAR_NONE) == TS_ERR_OKAY) {
 just_started = 0;
 sleep_time   = 0;
   } else {
+mgmt_log("in ProxyStateSet else branch");
--- End diff --

Note to self: remove this line


Issue Time Tracking
---

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

> 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: 0.5h
>  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...

[danobi]

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

https://github.com/apache/trafficserver/pull/1073#discussion_r83509798
  
--- Diff: cmd/traffic_manager/traffic_manager.cc ---
@@ -835,10 +824,11 @@ main(int argc, const char **argv)
   } else {
 sleep_time = 1;
   }
-  if (lmgmt->startProxy()) {
+  if (ProxyStateSet(TS_PROXY_ON, TS_CACHE_CLEAR_NONE) == TS_ERR_OKAY) {
 just_started = 0;
 sleep_time   = 0;
   } else {
+mgmt_log("in ProxyStateSet else branch");
--- End diff --

Note to self: remove this line


---
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-4975) ATS crashing when taking it out of rotation

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4975:
---
Affects Version/s: 7.0.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
>
> 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
> #18 0xae7b31 in 

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

[Bryan Call (JIRA)]

Bryan Call created TS-4975:
--

 Summary: 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
Reporter: Bryan Call


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
#18 0xae7b31 in write_to_net_io(NetHandler*, UnixNetVConnection*, EThread*) 
../../../trafficserver/iocore/net/UnixNetVConnection.cc:552
#19 0xae6d92 in write_to_net(NetHandler*, UnixNetVConnection*, EThread*) 
../../../trafficserver/iocore/net/UnixNetVConnection.cc:419
#20 0xad210c in NetHandler::mainNetEvent(int, Event*) 
../../../trafficserver/iocore/net/UnixNet.cc:542
#21 0x5ef2b4 

[GitHub] trafficserver issue #1112: RFC: Prefer nullptr to NULL.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1112
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/915/ 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-4399) Management API breaks diagnostic log rotation

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1073
  
@jpeach, is this what you were thinking?

Also, between commit 82037 and 3365b, `traffic_ctl` stopped working 
immediately after ATS starts up. There is ~30s gap between startup any 
`traffic_ctl` commands working, eg. `sudo ./traffic_ctl server stop`. I'm still 
looking into this.


Issue Time Tracking
---

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

> 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: 20m
>  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 issue #1073: TS-4399 TS-4400 Management API messes up proxy op...

[danobi]

Github user danobi commented on the issue:

https://github.com/apache/trafficserver/pull/1073
  
@jpeach, is this what you were thinking?

Also, between commit 82037 and 3365b, `traffic_ctl` stopped working 
immediately after ATS starts up. There is ~30s gap between startup any 
`traffic_ctl` commands working, eg. `sudo ./traffic_ctl server stop`. I'm still 
looking into 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.
---

[GitHub] trafficserver issue #1112: RFC: Prefer nullptr to NULL.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1112
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1022/ 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 #1112: RFC: Prefer nullptr to NULL.

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1112
  
[approve ci]


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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83508421
  
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -936,30 +940,70 @@ Http2ConnectionState::cleanup_streams()
 void
 Http2ConnectionState::delete_stream(Http2Stream *stream)
 {
+  // The following check allows the method to be called safely on already 
deleted streams.
+  if (deleted_from_active_streams(stream)) {
+return;
+  }
+
--- End diff --

OK, needed that for calling `delete_stream()` on already deleted streams 
for my “catch-all-delete-stream” calls (6.2.1). 

Also grouped some of the `DLL<>` + `client_streams_count` updates in 
separate functions.

Looking at how the master changed since I started working on this I may 
need to revert that to be consistent with master.



Issue Time Tracking
---

Worklog Id: (was: 30694)
Time Spent: 4h 20m  (was: 4h 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: 4h 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
> 

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

[gtenev]

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83508421
  
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -936,30 +940,70 @@ Http2ConnectionState::cleanup_streams()
 void
 Http2ConnectionState::delete_stream(Http2Stream *stream)
 {
+  // The following check allows the method to be called safely on already 
deleted streams.
+  if (deleted_from_active_streams(stream)) {
+return;
+  }
+
--- End diff --

OK, needed that for calling `delete_stream()` on already deleted streams 
for my “catch-all-delete-stream” calls (6.2.1). 

Also grouped some of the `DLL<>` + `client_streams_count` updates in 
separate functions.

Looking at how the master changed since I started working on this I may 
need to revert that to be consistent with master.



---
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 #1112: RFC: Prefer nullptr to NULL.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1112
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/914/ 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 #1112: RFC: Prefer nullptr to NULL.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1112
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1021/ 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 #1112: RFC: Prefer nullptr to NULL.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1112
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/913/ 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-4909) Throttling based on resident memory usage

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1063#discussion_r83504741
  
--- Diff: proxy/Main.cc ---
@@ -346,6 +346,54 @@ class DiagsLogContinuation : public Continuation
   }
 };
 
+class MemoryLimit : public Continuation
+{
+public:
+  MemoryLimit() : Continuation(new_ProxyMutex()), _memory_limit(0) { 
SET_HANDLER(::periodic); }
+  ~MemoryLimit() { mutex = NULL; }
+  int
+  periodic(int event, Event *e)
+  {
+if (event == EVENT_IMMEDIATE) {
+  // rescheduled from periodic to immediate event
+  // this is the indication to terminate
+  delete this;
+  return EVENT_DONE;
+}
+if (_memory_limit == 0) {
+  // first time it has been run
+  _memory_limit = 
REC_ConfigReadInteger("proxy.config.memory.max_usage");
--- End diff --

Ok that sounds reasonable.


Issue Time Tracking
---

Worklog Id: (was: 30689)
Time Spent: 2h 10m  (was: 2h)

> Throttling based on resident memory usage
> -
>
> Key: TS-4909
> URL: https://issues.apache.org/jira/browse/TS-4909
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Add a feature to stop accepting connections if the resident memory is over a 
> certain limit.



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

[GitHub] trafficserver pull request #1063: TS-4909: Throttling based on resident memo...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1063#discussion_r83504741
  
--- Diff: proxy/Main.cc ---
@@ -346,6 +346,54 @@ class DiagsLogContinuation : public Continuation
   }
 };
 
+class MemoryLimit : public Continuation
+{
+public:
+  MemoryLimit() : Continuation(new_ProxyMutex()), _memory_limit(0) { 
SET_HANDLER(::periodic); }
+  ~MemoryLimit() { mutex = NULL; }
+  int
+  periodic(int event, Event *e)
+  {
+if (event == EVENT_IMMEDIATE) {
+  // rescheduled from periodic to immediate event
+  // this is the indication to terminate
+  delete this;
+  return EVENT_DONE;
+}
+if (_memory_limit == 0) {
+  // first time it has been run
+  _memory_limit = 
REC_ConfigReadInteger("proxy.config.memory.max_usage");
--- End diff --

Ok that sounds reasonable.


---
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 #1063: TS-4909: Throttling based on resident memo...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1063#discussion_r83504537
  
--- Diff: iocore/net/UnixNetAccept.cc ---
@@ -280,6 +234,14 @@ NetAccept::do_blocking_accept(EThread *t)
   return -1;
 }
 
+// Throttle accepts
+if (!backdoor && (check_net_throttle(ACCEPT, now) || 
net_memory_throttle)) {
+  Debug("net_accept", "Too many connections or too much memory used, 
throttling");
+  check_throttle_warning();
+  con.close();
--- End diff --

Ok, sounds 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.
---

[jira] [Work logged] (TS-4909) Throttling based on resident memory usage

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1063#discussion_r83504537
  
--- Diff: iocore/net/UnixNetAccept.cc ---
@@ -280,6 +234,14 @@ NetAccept::do_blocking_accept(EThread *t)
   return -1;
 }
 
+// Throttle accepts
+if (!backdoor && (check_net_throttle(ACCEPT, now) || 
net_memory_throttle)) {
+  Debug("net_accept", "Too many connections or too much memory used, 
throttling");
+  check_throttle_warning();
+  con.close();
--- End diff --

Ok, sounds good.


Issue Time Tracking
---

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

> Throttling based on resident memory usage
> -
>
> Key: TS-4909
> URL: https://issues.apache.org/jira/browse/TS-4909
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Add a feature to stop accepting connections if the resident memory is over a 
> certain limit.



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

[GitHub] trafficserver issue #1063: TS-4909: Throttling based on resident memory usag...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1063
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/911/ 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-4909) Throttling based on resident memory usage

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Throttling based on resident memory usage
> -
>
> Key: TS-4909
> URL: https://issues.apache.org/jira/browse/TS-4909
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Add a feature to stop accepting connections if the resident memory is over a 
> certain limit.



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

[jira] [Work logged] (TS-4909) Throttling based on resident memory usage

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30686)
Time Spent: 1h 40m  (was: 1.5h)

> Throttling based on resident memory usage
> -
>
> Key: TS-4909
> URL: https://issues.apache.org/jira/browse/TS-4909
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Add a feature to stop accepting connections if the resident memory is over a 
> certain limit.



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

[GitHub] trafficserver issue #1063: TS-4909: Throttling based on resident memory usag...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1063
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1019/ 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 #1063: TS-4909: Throttling based on resident memo...

[bryancall]

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

https://github.com/apache/trafficserver/pull/1063#discussion_r83502802
  
--- Diff: iocore/net/UnixNetAccept.cc ---
@@ -280,6 +234,14 @@ NetAccept::do_blocking_accept(EThread *t)
   return -1;
 }
 
+// Throttle accepts
+if (!backdoor && (check_net_throttle(ACCEPT, now) || 
net_memory_throttle)) {
+  Debug("net_accept", "Too many connections or too much memory used, 
throttling");
+  check_throttle_warning();
+  con.close();
--- End diff --

check_throttle_warning logs an error message.  There currently isn't a stat 
for throttled incoming connections.  I can file a bug for it since I believe it 
will need to be added in a couple places.


---
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-4909) Throttling based on resident memory usage

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1063#discussion_r83502802
  
--- Diff: iocore/net/UnixNetAccept.cc ---
@@ -280,6 +234,14 @@ NetAccept::do_blocking_accept(EThread *t)
   return -1;
 }
 
+// Throttle accepts
+if (!backdoor && (check_net_throttle(ACCEPT, now) || 
net_memory_throttle)) {
+  Debug("net_accept", "Too many connections or too much memory used, 
throttling");
+  check_throttle_warning();
+  con.close();
--- End diff --

check_throttle_warning logs an error message.  There currently isn't a stat 
for throttled incoming connections.  I can file a bug for it since I believe it 
will need to be added in a couple places.


Issue Time Tracking
---

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

> Throttling based on resident memory usage
> -
>
> Key: TS-4909
> URL: https://issues.apache.org/jira/browse/TS-4909
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Add a feature to stop accepting connections if the resident memory is over a 
> certain limit.



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

[jira] [Work logged] (TS-4909) Throttling based on resident memory usage

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1063
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1020/ for details.
 



Issue Time Tracking
---

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

> Throttling based on resident memory usage
> -
>
> Key: TS-4909
> URL: https://issues.apache.org/jira/browse/TS-4909
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add a feature to stop accepting connections if the resident memory is over a 
> certain limit.



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

[GitHub] trafficserver issue #1063: TS-4909: Throttling based on resident memory usag...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1063
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/912/ 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-4909) Throttling based on resident memory usage

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Throttling based on resident memory usage
> -
>
> Key: TS-4909
> URL: https://issues.apache.org/jira/browse/TS-4909
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Add a feature to stop accepting connections if the resident memory is over a 
> certain limit.



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

[GitHub] trafficserver issue #1063: TS-4909: Throttling based on resident memory usag...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1063
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1020/ 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-4909) Throttling based on resident memory usage

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1063#discussion_r83501005
  
--- Diff: proxy/Main.cc ---
@@ -346,6 +346,54 @@ class DiagsLogContinuation : public Continuation
   }
 };
 
+class MemoryLimit : public Continuation
+{
+public:
+  MemoryLimit() : Continuation(new_ProxyMutex()), _memory_limit(0) { 
SET_HANDLER(::periodic); }
+  ~MemoryLimit() { mutex = NULL; }
+  int
+  periodic(int event, Event *e)
+  {
+if (event == EVENT_IMMEDIATE) {
+  // rescheduled from periodic to immediate event
+  // this is the indication to terminate
+  delete this;
+  return EVENT_DONE;
+}
+if (_memory_limit == 0) {
+  // first time it has been run
+  _memory_limit = 
REC_ConfigReadInteger("proxy.config.memory.max_usage");
+}
+if (_memory_limit > 0) {
+  if (getrusage(RUSAGE_SELF, &_usage) == 0) {
+Debug("server", "memory usage - ru_maxrss: %ld memory limit: %" 
PRId64, _usage.ru_maxrss, _memory_limit);
+if (_usage.ru_maxrss > _memory_limit) {
--- End diff --

Fixed this. Did a divide by 1024 for the setting.


Issue Time Tracking
---

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

> Throttling based on resident memory usage
> -
>
> Key: TS-4909
> URL: https://issues.apache.org/jira/browse/TS-4909
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Add a feature to stop accepting connections if the resident memory is over a 
> certain limit.



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

[GitHub] trafficserver pull request #1063: TS-4909: Throttling based on resident memo...

[bryancall]

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

https://github.com/apache/trafficserver/pull/1063#discussion_r83501005
  
--- Diff: proxy/Main.cc ---
@@ -346,6 +346,54 @@ class DiagsLogContinuation : public Continuation
   }
 };
 
+class MemoryLimit : public Continuation
+{
+public:
+  MemoryLimit() : Continuation(new_ProxyMutex()), _memory_limit(0) { 
SET_HANDLER(::periodic); }
+  ~MemoryLimit() { mutex = NULL; }
+  int
+  periodic(int event, Event *e)
+  {
+if (event == EVENT_IMMEDIATE) {
+  // rescheduled from periodic to immediate event
+  // this is the indication to terminate
+  delete this;
+  return EVENT_DONE;
+}
+if (_memory_limit == 0) {
+  // first time it has been run
+  _memory_limit = 
REC_ConfigReadInteger("proxy.config.memory.max_usage");
+}
+if (_memory_limit > 0) {
+  if (getrusage(RUSAGE_SELF, &_usage) == 0) {
+Debug("server", "memory usage - ru_maxrss: %ld memory limit: %" 
PRId64, _usage.ru_maxrss, _memory_limit);
+if (_usage.ru_maxrss > _memory_limit) {
--- End diff --

Fixed this. Did a divide by 1024 for the setting.


---
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-4973) ubuntu 14.04 ATS 6.2.0 proxy/hdrs undefined reference to symbol 'Tcl_NextHashEntry'

[Huaping Gu (JIRA)]

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

Huaping Gu updated TS-4973:
---
Description: 
build failed in Docker, on image ubuntu 14.04, 14.04.5

add explicit command to install tcl, still failed
"RUN apt-get install -y libtcl8.6"

Following are stack trace of the error message. Similar error found in TS-4521

Making check in proxy/hdrs
make[1]: Entering directory `/proxy/hdrs'
make  test_mime
make[2]: Entering directory `/proxy/hdrs'
  CXX  test_mime.o
  CXXLDtest_mime
/usr/bin/ld: ./libhdrs.a(HttpCompat.o): undefined reference to symbol 
'Tcl_NextHashEntry'
//usr/lib/x86_64-linux-gnu/libtcl8.6.so: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
make[2]: *** [test_mime] Error 1
make[2]: Leaving directory `/proxy/hdrs'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/proxy/hdrs'
make: *** [check-recursive] Error 1
The command '/bin/sh -c make check' returned a non-zero code: 2

==

Append: Same source code build success on Mac (10.12)

  was:
build failed in Docker, on image ubuntu 14.04, 14.04.5

add explicit command to install tcl, still failed
"RUN apt-get install -y libtcl8.6"

Following are stack trace of the error message. Similar error found in TS-4521

Making check in proxy/hdrs
make[1]: Entering directory `/proxy/hdrs'
make  test_mime
make[2]: Entering directory `/proxy/hdrs'
  CXX  test_mime.o
  CXXLDtest_mime
/usr/bin/ld: ./libhdrs.a(HttpCompat.o): undefined reference to symbol 
'Tcl_NextHashEntry'
//usr/lib/x86_64-linux-gnu/libtcl8.6.so: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
make[2]: *** [test_mime] Error 1
make[2]: Leaving directory `/proxy/hdrs'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/proxy/hdrs'
make: *** [check-recursive] Error 1
The command '/bin/sh -c make check' returned a non-zero code: 2


> ubuntu 14.04 ATS 6.2.0 proxy/hdrs undefined reference to symbol 
> 'Tcl_NextHashEntry'
> ---
>
> Key: TS-4973
> URL: https://issues.apache.org/jira/browse/TS-4973
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 6.2.0
>Reporter: Huaping Gu
>
> build failed in Docker, on image ubuntu 14.04, 14.04.5
> add explicit command to install tcl, still failed
> "RUN apt-get install -y libtcl8.6"
> Following are stack trace of the error message. Similar error found in TS-4521
> 
> Making check in proxy/hdrs
> make[1]: Entering directory `/proxy/hdrs'
> make  test_mime
> make[2]: Entering directory `/proxy/hdrs'
>   CXX  test_mime.o
>   CXXLDtest_mime
> /usr/bin/ld: ./libhdrs.a(HttpCompat.o): undefined reference to symbol 
> 'Tcl_NextHashEntry'
> //usr/lib/x86_64-linux-gnu/libtcl8.6.so: error adding symbols: DSO missing 
> from command line
> collect2: error: ld returned 1 exit status
> make[2]: *** [test_mime] Error 1
> make[2]: Leaving directory `/proxy/hdrs'
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory `/proxy/hdrs'
> make: *** [check-recursive] Error 1
> The command '/bin/sh -c make check' returned a non-zero code: 2
> ==
> Append: Same source code build success on Mac (10.12)



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

[jira] [Updated] (TS-4973) ubuntu 14.04 ATS 6.2.0 proxy/hdrs undefined reference to symbol 'Tcl_NextHashEntry'

[Huaping Gu (JIRA)]

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

Huaping Gu updated TS-4973:
---
Affects Version/s: 6.2.0

> ubuntu 14.04 ATS 6.2.0 proxy/hdrs undefined reference to symbol 
> 'Tcl_NextHashEntry'
> ---
>
> Key: TS-4973
> URL: https://issues.apache.org/jira/browse/TS-4973
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 6.2.0
>Reporter: Huaping Gu
>
> build failed in Docker, on image ubuntu 14.04, 14.04.5
> add explicit command to install tcl, still failed
> "RUN apt-get install -y libtcl8.6"
> Following are stack trace of the error message. Similar error found in TS-4521
> 
> Making check in proxy/hdrs
> make[1]: Entering directory `/proxy/hdrs'
> make  test_mime
> make[2]: Entering directory `/proxy/hdrs'
>   CXX  test_mime.o
>   CXXLDtest_mime
> /usr/bin/ld: ./libhdrs.a(HttpCompat.o): undefined reference to symbol 
> 'Tcl_NextHashEntry'
> //usr/lib/x86_64-linux-gnu/libtcl8.6.so: error adding symbols: DSO missing 
> from command line
> collect2: error: ld returned 1 exit status
> make[2]: *** [test_mime] Error 1
> make[2]: Leaving directory `/proxy/hdrs'
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory `/proxy/hdrs'
> make: *** [check-recursive] Error 1
> The command '/bin/sh -c make check' returned a non-zero code: 2



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

[GitHub] trafficserver issue #1112: RFC: Prefer nullptr to NULL.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1112
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1017/ 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-4858) Global session ticket key block leaks.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1024
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1018/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30680)
Time Spent: 3h 40m  (was: 3.5h)

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1018/ 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-4858) Global session ticket key block leaks.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30679)
Time Spent: 3.5h  (was: 3h 20m)

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/910/ 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-4909) Throttling based on resident memory usage

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1063#discussion_r83498036
  
--- Diff: proxy/Main.cc ---
@@ -346,6 +346,54 @@ class DiagsLogContinuation : public Continuation
   }
 };
 
+class MemoryLimit : public Continuation
+{
+public:
+  MemoryLimit() : Continuation(new_ProxyMutex()), _memory_limit(0) { 
SET_HANDLER(::periodic); }
+  ~MemoryLimit() { mutex = NULL; }
+  int
+  periodic(int event, Event *e)
+  {
+if (event == EVENT_IMMEDIATE) {
+  // rescheduled from periodic to immediate event
+  // this is the indication to terminate
+  delete this;
+  return EVENT_DONE;
+}
+if (_memory_limit == 0) {
+  // first time it has been run
+  _memory_limit = 
REC_ConfigReadInteger("proxy.config.memory.max_usage");
--- End diff --

I don't have an event scheduled if it is not configured.  I thought it 
would be nice to not have an event scheduled every 1 second if someone doesn't 
have it configured.


Issue Time Tracking
---

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

> Throttling based on resident memory usage
> -
>
> Key: TS-4909
> URL: https://issues.apache.org/jira/browse/TS-4909
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Add a feature to stop accepting connections if the resident memory is over a 
> certain limit.



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

[GitHub] trafficserver pull request #1063: TS-4909: Throttling based on resident memo...

[bryancall]

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

https://github.com/apache/trafficserver/pull/1063#discussion_r83498036
  
--- Diff: proxy/Main.cc ---
@@ -346,6 +346,54 @@ class DiagsLogContinuation : public Continuation
   }
 };
 
+class MemoryLimit : public Continuation
+{
+public:
+  MemoryLimit() : Continuation(new_ProxyMutex()), _memory_limit(0) { 
SET_HANDLER(::periodic); }
+  ~MemoryLimit() { mutex = NULL; }
+  int
+  periodic(int event, Event *e)
+  {
+if (event == EVENT_IMMEDIATE) {
+  // rescheduled from periodic to immediate event
+  // this is the indication to terminate
+  delete this;
+  return EVENT_DONE;
+}
+if (_memory_limit == 0) {
+  // first time it has been run
+  _memory_limit = 
REC_ConfigReadInteger("proxy.config.memory.max_usage");
--- End diff --

I don't have an event scheduled if it is not configured.  I thought it 
would be nice to not have an event scheduled every 1 second if someone doesn't 
have it configured.


---
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-4858) Global session ticket key block leaks.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1024
  
[approve ci]


Issue Time Tracking
---

Worklog Id: (was: 30677)
Time Spent: 3h 20m  (was: 3h 10m)

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
[approve ci]


---
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 #1112: RFC: Prefer nullptr to NULL.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1112
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/909/ 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-4973) ubuntu 14.04 ATS 6.2.0 proxy/hdrs undefined reference to symbol 'Tcl_NextHashEntry'

[Huaping Gu (JIRA)]

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

Huaping Gu updated TS-4973:
---
Description: 
build failed in Docker, on image ubuntu 14.04, 14.04.5

add explicit command to install tcl, still failed
"RUN apt-get install -y libtcl8.6"

Following are stack trace of the error message. Similar error found in TS-4521

Making check in proxy/hdrs
make[1]: Entering directory `/proxy/hdrs'
make  test_mime
make[2]: Entering directory `/proxy/hdrs'
  CXX  test_mime.o
  CXXLDtest_mime
/usr/bin/ld: ./libhdrs.a(HttpCompat.o): undefined reference to symbol 
'Tcl_NextHashEntry'
//usr/lib/x86_64-linux-gnu/libtcl8.6.so: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
make[2]: *** [test_mime] Error 1
make[2]: Leaving directory `/proxy/hdrs'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/proxy/hdrs'
make: *** [check-recursive] Error 1
The command '/bin/sh -c make check' returned a non-zero code: 2

  was:
build failed in Docker, on image ubuntu 14.04, 14.04.5

add explicit command to install tcl, still failed
"RUN apt-get install -y libtcl8.6"

Following are stack trace of the error message
===
Making check in proxy/hdrs
make[1]: Entering directory `/proxy/hdrs'
make  test_mime
make[2]: Entering directory `/proxy/hdrs'
  CXX  test_mime.o
  CXXLDtest_mime
/usr/bin/ld: ./libhdrs.a(HttpCompat.o): undefined reference to symbol 
'Tcl_NextHashEntry'
//usr/lib/x86_64-linux-gnu/libtcl8.6.so: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
make[2]: *** [test_mime] Error 1
make[2]: Leaving directory `/proxy/hdrs'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/proxy/hdrs'
make: *** [check-recursive] Error 1
The command '/bin/sh -c make check' returned a non-zero code: 2


> ubuntu 14.04 ATS 6.2.0 proxy/hdrs undefined reference to symbol 
> 'Tcl_NextHashEntry'
> ---
>
> Key: TS-4973
> URL: https://issues.apache.org/jira/browse/TS-4973
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Huaping Gu
>
> build failed in Docker, on image ubuntu 14.04, 14.04.5
> add explicit command to install tcl, still failed
> "RUN apt-get install -y libtcl8.6"
> Following are stack trace of the error message. Similar error found in TS-4521
> 
> Making check in proxy/hdrs
> make[1]: Entering directory `/proxy/hdrs'
> make  test_mime
> make[2]: Entering directory `/proxy/hdrs'
>   CXX  test_mime.o
>   CXXLDtest_mime
> /usr/bin/ld: ./libhdrs.a(HttpCompat.o): undefined reference to symbol 
> 'Tcl_NextHashEntry'
> //usr/lib/x86_64-linux-gnu/libtcl8.6.so: error adding symbols: DSO missing 
> from command line
> collect2: error: ld returned 1 exit status
> make[2]: *** [test_mime] Error 1
> make[2]: Leaving directory `/proxy/hdrs'
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory `/proxy/hdrs'
> make: *** [check-recursive] Error 1
> The command '/bin/sh -c make check' returned a non-zero code: 2



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

[jira] [Updated] (TS-4973) ubuntu 14.04 ATS 6.2.0 proxy/hdrs undefined reference to symbol 'Tcl_NextHashEntry'

[Huaping Gu (JIRA)]

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

Huaping Gu updated TS-4973:
---
Description: 
build failed in Docker, on image ubuntu 14.04, 14.04.5

add explicit command to install tcl, still failed
"RUN apt-get install -y libtcl8.6"

Following are stack trace of the error message
===
Making check in proxy/hdrs
make[1]: Entering directory `/proxy/hdrs'
make  test_mime
make[2]: Entering directory `/proxy/hdrs'
  CXX  test_mime.o
  CXXLDtest_mime
/usr/bin/ld: ./libhdrs.a(HttpCompat.o): undefined reference to symbol 
'Tcl_NextHashEntry'
//usr/lib/x86_64-linux-gnu/libtcl8.6.so: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
make[2]: *** [test_mime] Error 1
make[2]: Leaving directory `/proxy/hdrs'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/proxy/hdrs'
make: *** [check-recursive] Error 1
The command '/bin/sh -c make check' returned a non-zero code: 2

  was:
Making check in proxy/hdrs
make[1]: Entering directory `/proxy/hdrs'
make  test_mime
make[2]: Entering directory `/proxy/hdrs'
  CXX  test_mime.o
  CXXLDtest_mime
/usr/bin/ld: ./libhdrs.a(HttpCompat.o): undefined reference to symbol 
'Tcl_NextHashEntry'
//usr/lib/x86_64-linux-gnu/libtcl8.6.so: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
make[2]: *** [test_mime] Error 1
make[2]: Leaving directory `/proxy/hdrs'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/proxy/hdrs'
make: *** [check-recursive] Error 1
The command '/bin/sh -c make check' returned a non-zero code: 2


> ubuntu 14.04 ATS 6.2.0 proxy/hdrs undefined reference to symbol 
> 'Tcl_NextHashEntry'
> ---
>
> Key: TS-4973
> URL: https://issues.apache.org/jira/browse/TS-4973
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Huaping Gu
>
> build failed in Docker, on image ubuntu 14.04, 14.04.5
> add explicit command to install tcl, still failed
> "RUN apt-get install -y libtcl8.6"
> Following are stack trace of the error message
> ===
> Making check in proxy/hdrs
> make[1]: Entering directory `/proxy/hdrs'
> make  test_mime
> make[2]: Entering directory `/proxy/hdrs'
>   CXX  test_mime.o
>   CXXLDtest_mime
> /usr/bin/ld: ./libhdrs.a(HttpCompat.o): undefined reference to symbol 
> 'Tcl_NextHashEntry'
> //usr/lib/x86_64-linux-gnu/libtcl8.6.so: error adding symbols: DSO missing 
> from command line
> collect2: error: ld returned 1 exit status
> make[2]: *** [test_mime] Error 1
> make[2]: Leaving directory `/proxy/hdrs'
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory `/proxy/hdrs'
> make: *** [check-recursive] Error 1
> The command '/bin/sh -c make check' returned a non-zero code: 2



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

[jira] [Work logged] (TS-4858) Global session ticket key block leaks.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1024
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1016/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30676)
Time Spent: 3h 10m  (was: 3h)

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1016/ 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-4858) Global session ticket key block leaks.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30675)
Time Spent: 3h  (was: 2h 50m)

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/908/ 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-4858) Global session ticket key block leaks.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1024
  
[approve ci]


Issue Time Tracking
---

Worklog Id: (was: 30674)
Time Spent: 2h 50m  (was: 2h 40m)

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
[approve ci]


---
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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver issue #1110: TS-4971: Change TSPluginRegistration to be const.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/907/ 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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver issue #1110: TS-4971: Change TSPluginRegistration to be const.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1015/ 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-4972) Allow collapsed_forwarding plugin to be configured global or per remap

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30671)
Time Spent: 1h 40m  (was: 1.5h)

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

[GitHub] trafficserver issue #1111: TS-4972: Configure collapsed_forwarding plugin as...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/906/ 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-4972) Allow collapsed_forwarding plugin to be configured global or per remap

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> 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
>  Time Spent: 1.5h
>  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)

[GitHub] trafficserver issue #1111: TS-4972: Configure collapsed_forwarding plugin as...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1014/ 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-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1109
  
Would it be easier to just back port the fix from TS-4590?  I'm a bit 
concerned about the proposed fix in this PR.  I don't think is correctly using 
the m_deleted/m_deletable parameters?


Issue Time Tracking
---

Worklog Id: (was: 30669)
Time Spent: 3h  (was: 2h 50m)

> 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
>  Time Spent: 3h
>  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...

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
Would it be easier to just back port the fix from TS-4590?  I'm a bit 
concerned about the proposed fix in this PR.  I don't think is correctly using 
the m_deleted/m_deletable parameters?


---
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()

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4970:


Would it be easier to just back port the fix from TS-4590?  I'm a bit concerned 
about the proposed fix in the PR.  I don't think is correctly using the 
m_deleted/m_deletable parameters?

> 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
>  Time Spent: 2h 50m
>  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] [Work logged] (TS-4974) Bad debug assert in HttpSM::handle_server_setup_error

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

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

[GitHub] trafficserver issue #1113: TS-4974: Bad debug assert in HttpSM::handle_serve...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1113
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/905/ 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-4974) Bad debug assert in HttpSM::handle_server_setup_error

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> 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
>  Time Spent: 20m
>  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)

[GitHub] trafficserver issue #1113: TS-4974: Bad debug assert in HttpSM::handle_serve...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1113
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1013/ 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 #1110: TS-4971: Change TSPluginRegistration to be const.

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/1110
  
I'll fix the `const` thing and do the plugin updates in a new PR. I tested 
the build and the plugins built fine, as expected.


---
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-4972) Allow collapsed_forwarding plugin to be configured global or per remap

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/#discussion_r83489086
  
--- Diff: plugins/experimental/collapsed_forwarding/collapsed_forwarding.cc 
---
@@ -265,49 +307,69 @@ collapsed_cont(TSCont contp, TSEvent event, void 
*edata)
   return TS_SUCCESS;
 }
 
-TSReturnCode
-TSRemapInit(TSRemapInterface * /* api_info */, char * /* errbuf */, int /* 
errbuf_size */)
-{
-  TSDebug(DEBUG_TAG, "plugin is succesfully initialized");
-  return TS_SUCCESS;
-}
-
-TSReturnCode
-TSRemapNewInstance(int argc, char *argv[], void ** /* ih */, char * /* 
errbuf */, int /* errbuf_size */)
+void
+process_args(int argc, const char **argv)
 {
   // basic argv processing..
-  for (int i = 2; i < argc; ++i) {
+  for (int i = 1; i < argc; ++i) {
 if (strncmp(argv[i], "--delay=", 8) == 0) {
   OPEN_WRITE_FAIL_REQ_DELAY_TIMEOUT = atoi((char *)(argv[i] + 8));
 } else if (strncmp(argv[i], "--retries=", 10) == 0) {
   OPEN_WRITE_FAIL_MAX_REQ_DELAY_RETRIES = atoi((char *)(argv[i] + 10));
 }
   }
-
-  return TS_SUCCESS;
 }
 
-TSRemapStatus
-TSRemapDoRemap(void *ih, TSHttpTxn rh, TSRemapRequestInfo *rri)
+/*
+ * Initialize globally
+ */
+void
+TSPluginInit(int argc, const char *argv[])
 {
+  TSPluginRegistrationInfo info;
+
+  info.plugin_name   = (char *)DEBUG_TAG;
+  info.vendor_name   = (char *)"Apache Software Foundation";
+  info.support_email = (char *)"d...@trafficserver.apache.org";
+
+  if (TS_SUCCESS != TSPluginRegister()) {
+TSError("[%s] Plugin registration failed.", DEBUG_TAG);
+  }
+
+  process_args(argc, argv);
+
   TSCont cont = TSContCreate(collapsed_cont, TSMutexCreate());
 
-  RequestData *req_data = new RequestData();
+  TSDebug(DEBUG_TAG, "Global Initialized");
+  // Set up the per transaction state in the READ_REQUEST event
+  TSHttpHookAdd(TS_HTTP_READ_REQUEST_HDR_HOOK, cont);
 
-  req_data->txnp = rh;
-  req_data->wl_retry = 0;
+  global_init = true;
+}
 
-  int url_len = 0;
-  char *url   = TSHttpTxnEffectiveUrlStringGet(rh, _len);
-  req_data->req_url.assign(url, url_len);
+TSReturnCode
+TSRemapInit(TSRemapInterface * /* api_info */, char * /* errbuf */, int /* 
errbuf_size */)
+{
+  if (global_init) {
+TSError("Cannot initialize %s as both global and remap plugin", 
DEBUG_TAG);
+return TS_ERROR;
+  } else {
+TSDebug(DEBUG_TAG, "plugin is succesfully initialized for remap");
+return TS_SUCCESS;
+  }
+}
 
-  TSfree(url);
-  TSContDataSet(cont, req_data);
+TSReturnCode
+TSRemapNewInstance(int argc, char *argv[], void ** /* ih */, char * /* 
errbuf */, int /* errbuf_size */)
+{
+  process_args(argc, const_cast(argv + 1));
--- End diff --

Updated new version that decrements argc appropriately.  Verified that it 
is correct in the remap case.


Issue Time Tracking
---

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

> 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
>  Time Spent: 1h 20m
>  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)

[GitHub] trafficserver pull request #1111: TS-4972: Configure collapsed_forwarding pl...

[shinrich]

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

https://github.com/apache/trafficserver/pull/#discussion_r83489086
  
--- Diff: plugins/experimental/collapsed_forwarding/collapsed_forwarding.cc 
---
@@ -265,49 +307,69 @@ collapsed_cont(TSCont contp, TSEvent event, void 
*edata)
   return TS_SUCCESS;
 }
 
-TSReturnCode
-TSRemapInit(TSRemapInterface * /* api_info */, char * /* errbuf */, int /* 
errbuf_size */)
-{
-  TSDebug(DEBUG_TAG, "plugin is succesfully initialized");
-  return TS_SUCCESS;
-}
-
-TSReturnCode
-TSRemapNewInstance(int argc, char *argv[], void ** /* ih */, char * /* 
errbuf */, int /* errbuf_size */)
+void
+process_args(int argc, const char **argv)
 {
   // basic argv processing..
-  for (int i = 2; i < argc; ++i) {
+  for (int i = 1; i < argc; ++i) {
 if (strncmp(argv[i], "--delay=", 8) == 0) {
   OPEN_WRITE_FAIL_REQ_DELAY_TIMEOUT = atoi((char *)(argv[i] + 8));
 } else if (strncmp(argv[i], "--retries=", 10) == 0) {
   OPEN_WRITE_FAIL_MAX_REQ_DELAY_RETRIES = atoi((char *)(argv[i] + 10));
 }
   }
-
-  return TS_SUCCESS;
 }
 
-TSRemapStatus
-TSRemapDoRemap(void *ih, TSHttpTxn rh, TSRemapRequestInfo *rri)
+/*
+ * Initialize globally
+ */
+void
+TSPluginInit(int argc, const char *argv[])
 {
+  TSPluginRegistrationInfo info;
+
+  info.plugin_name   = (char *)DEBUG_TAG;
+  info.vendor_name   = (char *)"Apache Software Foundation";
+  info.support_email = (char *)"d...@trafficserver.apache.org";
+
+  if (TS_SUCCESS != TSPluginRegister()) {
+TSError("[%s] Plugin registration failed.", DEBUG_TAG);
+  }
+
+  process_args(argc, argv);
+
   TSCont cont = TSContCreate(collapsed_cont, TSMutexCreate());
 
-  RequestData *req_data = new RequestData();
+  TSDebug(DEBUG_TAG, "Global Initialized");
+  // Set up the per transaction state in the READ_REQUEST event
+  TSHttpHookAdd(TS_HTTP_READ_REQUEST_HDR_HOOK, cont);
 
-  req_data->txnp = rh;
-  req_data->wl_retry = 0;
+  global_init = true;
+}
 
-  int url_len = 0;
-  char *url   = TSHttpTxnEffectiveUrlStringGet(rh, _len);
-  req_data->req_url.assign(url, url_len);
+TSReturnCode
+TSRemapInit(TSRemapInterface * /* api_info */, char * /* errbuf */, int /* 
errbuf_size */)
+{
+  if (global_init) {
+TSError("Cannot initialize %s as both global and remap plugin", 
DEBUG_TAG);
+return TS_ERROR;
+  } else {
+TSDebug(DEBUG_TAG, "plugin is succesfully initialized for remap");
+return TS_SUCCESS;
+  }
+}
 
-  TSfree(url);
-  TSContDataSet(cont, req_data);
+TSReturnCode
+TSRemapNewInstance(int argc, char *argv[], void ** /* ih */, char * /* 
errbuf */, int /* errbuf_size */)
+{
+  process_args(argc, const_cast(argv + 1));
--- End diff --

Updated new version that decrements argc appropriately.  Verified that it 
is correct in the remap case.


---
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-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1110
  
I'll fix the `const` thing and do the plugin updates in a new PR. I tested 
the build and the plugins built fine, as expected.


Issue Time Tracking
---

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

> Change TSPluginRegistration and TSPluginRegister to take const data
> ---
>
> Key: TS-4971
> URL: https://issues.apache.org/jira/browse/TS-4971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> These should be constant. The fact they are not causes problems and bad 
> programming.



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

[GitHub] trafficserver pull request #1113: TS-4974: Bad debug assert in HttpSM::handl...

[shinrich]

GitHub user shinrich opened a pull request:

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

TS-4974: Bad debug assert in HttpSM::handle_server_setup_error

See jira for description.

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

$ git pull https://github.com/shinrich/trafficserver ts-4974

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

https://github.com/apache/trafficserver/pull/1113.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 #1113


commit 9d202b713baed5b0ccdbeec8d5ca0da53a4c
Author: Susan Hinrichs 
Date:   2016-10-14T19:35:28Z

TS-4974: Bad debug assert in HttpSM::handle_server_setup_error




---
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-4974) Bad debug assert in HttpSM::handle_server_setup_error

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 14/Oct/16 19:37
Start Date: 14/Oct/16 19:37
Worklog Time Spent: 10m 
  Work Description: GitHub user shinrich opened a pull request:

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

TS-4974: Bad debug assert in HttpSM::handle_server_setup_error

See jira for description.

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

$ git pull https://github.com/shinrich/trafficserver ts-4974

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

https://github.com/apache/trafficserver/pull/1113.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 #1113


commit 9d202b713baed5b0ccdbeec8d5ca0da53a4c
Author: Susan Hinrichs 
Date:   2016-10-14T19:35:28Z

TS-4974: Bad debug assert in HttpSM::handle_server_setup_error




Issue Time Tracking
---

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

> 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
>  Time Spent: 10m
>  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)