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

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/1114#discussion_r83742164
  
--- Diff: plugins/experimental/mysql_remap/mysql_remap.cc ---
@@ -232,7 +232,7 @@ TSPluginInit(int argc, const char *argv[])
 return;
   }
 
-  data->query = (char *)TSmalloc(QSIZE * sizeof(char)); // TODO: malloc 
smarter sizes
+  data->query = TSmalloc(QSIZE * sizeof(char)); // TODO: malloc smarter 
sizes
--- End diff --

Ah, that's not being compiled for me due to lack of mySQL packages.


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1114#discussion_r83742164
  
--- Diff: plugins/experimental/mysql_remap/mysql_remap.cc ---
@@ -232,7 +232,7 @@ TSPluginInit(int argc, const char *argv[])
 return;
   }
 
-  data->query = (char *)TSmalloc(QSIZE * sizeof(char)); // TODO: malloc 
smarter sizes
+  data->query = TSmalloc(QSIZE * sizeof(char)); // TODO: malloc smarter 
sizes
--- End diff --

Ah, that's not being compiled for me due to lack of mySQL packages.


Issue Time Tracking
---

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

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



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

Build failed in Jenkins: clang-analyzer #2711

[jenkins]

See 

Changes:

[shinrich] TS-4858: fix memory leak problem of global_default_keyblock

--
[...truncated 5404 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIOMutexGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 71%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 71%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 72%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 73%] developer-guide/api/index.en
reading sources... [ 73%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 74%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 75%] developer-guide/api/types/TSHttpType.en
reading sources... [ 75%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 76%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 78%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 79%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 80%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 80%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 81%] developer-guide/architecture/data-structures.en
reading sources... [ 81%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 82%] developer-guide/config-vars.en
reading sources... [ 82%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 83%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading sources... [ 83%] developer-guide/debugging/profiling.en
reading sources... [ 84%] developer-guide/debugging/using-tsassert.en

[GitHub] trafficserver pull request #1024: TS-4858: fix memory leak of global_default...

[shinrich]

Github user shinrich closed the pull request at:

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


---
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=30790=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30790
 ]

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

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

https://github.com/apache/trafficserver/pull/1024
  
Looks good.  Persia addressed Leif and James' comments.


Issue Time Tracking
---

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

Jenkins build is back to normal : centos_7-master » clang,centos_7,release #2067

[jenkins]

See 

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

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
Looks good.  Persia addressed Leif and James' comments.


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1114
  
Clang format


Issue Time Tracking
---

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

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



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

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

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1114
  
Clang format


---
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=30795=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30795
 ]

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

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

https://github.com/apache/trafficserver/pull/1109
  
Is this a duplicate PR?


Issue Time Tracking
---

Worklog Id: (was: 30795)
Time Spent: 4.5h  (was: 4h 20m)

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



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

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

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
Is this a duplicate PR?


---
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-4942) Simple retry is not working correctly

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4942:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> Simple retry is not working correctly
> -
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



--
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=30755=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30755
 ]

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

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

https://github.com/apache/trafficserver/pull/1024
  
Please review @shinrich 


Issue Time Tracking
---

Worklog Id: (was: 30755)
Time Spent: 3h 50m  (was: 3h 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: 3h 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...

[persiaAziz]

Github user persiaAziz commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
Please review @shinrich 


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

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4971:


Only backporting the changes for pull results 1110 (hash 
16fe7bd28630d01f96b29efdd97cbaf1a0ac3e6f) into the 7.0.x branch.

[~amc] said pull request 1114 is for a different issue.

> 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: 4h
>  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)

[jira] [Updated] (TS-4072) Diagnostic log rolling races

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4072:
---
Backport to Version: 6.2.1  (was: 6.2.1, 7.0.0)

> Diagnostic log rolling races
> 
>
> Key: TS-4072
> URL: https://issues.apache.org/jira/browse/TS-4072
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> When diagnostic logs are rolled, {{Diags::diags_log}} is deleted and replaced 
> with a new log object. Since the global {{diags}} points to a a single 
> {{Diags}} object there is nothing to prevent a different thread logging 
> through this object at the time it is deleted.



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

[jira] [Updated] (TS-4072) Diagnostic log rolling races

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4072:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> Diagnostic log rolling races
> 
>
> Key: TS-4072
> URL: https://issues.apache.org/jira/browse/TS-4072
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> When diagnostic logs are rolled, {{Diags::diags_log}} is deleted and replaced 
> with a new log object. Since the global {{diags}} points to a a single 
> {{Diags}} object there is nothing to prevent a different thread logging 
> through this object at the time it is deleted.



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

[jira] [Updated] (TS-4959) Remove an old remnant of MSIE UA detection

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4959:
---
Backport to Version:   (was: 7.0.0)

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

[jira] [Updated] (TS-4942) Simple retry is not working correctly

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4942:
---
Backport to Version: 6.2.1  (was: 6.2.1, 7.0.0)

> Simple retry is not working correctly
> -
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[jira] [Updated] (TS-4959) Remove an old remnant of MSIE UA detection

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4959:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1114#discussion_r83743000
  
--- Diff: plugins/experimental/ats_pagespeed/gzip/misc.cc ---
@@ -157,7 +157,7 @@ register_plugin()
 const char *
 load_dictionary(const char *preload_file)
 {
-  char *dict   = (char *)malloc(80);
+  char *dict   = malloc(80);
--- End diff --

That's outside the scope of this fix :-)


Issue Time Tracking
---

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

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



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

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

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/1114#discussion_r83743000
  
--- Diff: plugins/experimental/ats_pagespeed/gzip/misc.cc ---
@@ -157,7 +157,7 @@ register_plugin()
 const char *
 load_dictionary(const char *preload_file)
 {
-  char *dict   = (char *)malloc(80);
+  char *dict   = malloc(80);
--- End diff --

That's outside the scope of this 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.
---

Build failed in Jenkins: clang-analyzer #2710

[jenkins]

See 

Changes:

[Leif Hedstrom] Add a prune option to the mirror script

--
[...truncated 5404 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIOMutexGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 71%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 71%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 72%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 73%] developer-guide/api/index.en
reading sources... [ 73%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 74%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 75%] developer-guide/api/types/TSHttpType.en
reading sources... [ 75%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 76%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 78%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 79%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 80%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 80%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 81%] developer-guide/architecture/data-structures.en
reading sources... [ 81%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 82%] developer-guide/config-vars.en
reading sources... [ 82%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 83%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading sources... [ 83%] developer-guide/debugging/profiling.en
reading sources... [ 84%] developer-guide/debugging/using-tsassert.en
reading 

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

[James Peach (JIRA)]

James Peach created TS-4977:
---

 Summary: Adopt nullptr
 Key: TS-4977
 URL: https://issues.apache.org/jira/browse/TS-4977
 Project: Traffic Server
  Issue Type: Bug
  Components: Cleanup, Core
Reporter: James Peach


Adopt {{nullptr}} to replace {{NULL}} in all C++ files.



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

Build failed in Jenkins: centos_7-master » clang,centos_7,release #2066

[jenkins]

See 


--
[...truncated 19114 lines...]
0|0|103.150.5.0|103.150.5.0|per_ip| |F|0|0|1970/01/01 
00:00:00|16572297681063508287|0|0|1|0
0|0|250.74.6.0|250.74.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3435544084056601407|0|0|1|0
0|0|33.228.1.0|33.228.1.0|per_ip| |F|0|0|1970/01/01 
00:00:00|7054485740756729087|0|0|1|0
0|0|5.119.12.0|5.119.12.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14495321938049529599|0|0|1|0
0|0|176.81.0.0|176.81.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|11377479059831779583|0|0|1|0
0|0|156.11.6.0|156.11.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8234706063569537663|0|0|1|0
0|0|109.134.9.0|109.134.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14050053816847377407|0|0|1|0
0|0|140.42.10.0|140.42.10.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8162434488007175487|0|0|1|0
0|0|114.61.13.0|114.61.13.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3945992723180975743|0|0|1|0
0|0|33.100.6.0|33.100.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|6825087806830268671|0|0|1|0
0|0|83.94.9.0|83.94.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3346846807966173951|0|0|1|0
0|0|145.111.0.0|145.111.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4310273191177806975|0|0|1|0
RPRINT Congestion_CongestionDB: There are 1048576 records in the db
RPRINT Congestion_CongestionDB: After test [1] there are 1024 records in the db
RPRINT Congestion_CongestionDB: After test [2] there are 2816 records in the db
RPRINT Congestion_CongestionDB: After test [3] there are 1048576 records in the 
db
REGRESSION_RESULT Congestion_CongestionDB:  PASSED
REGRESSION TEST Congestion_FailHistory started
RPRINT Congestion_FailHistory: Verify the result
RPRINT Congestion_FailHistory: Content of history
RPRINT Congestion_FailHistory: bucket 0 => events 2612 , sum = 2612
RPRINT Congestion_FailHistory: bucket 1 => events 3974 , sum = 6586
RPRINT Congestion_FailHistory: bucket 2 => events 4015 , sum = 10601
RPRINT Congestion_FailHistory: bucket 3 => events 3855 , sum = 14456
RPRINT Congestion_FailHistory: bucket 4 => events 4029 , sum = 18485
RPRINT Congestion_FailHistory: bucket 5 => events 4023 , sum = 22508
RPRINT Congestion_FailHistory: bucket 6 => events 3828 , sum = 26336
RPRINT Congestion_FailHistory: bucket 7 => events 3855 , sum = 30191
RPRINT Congestion_FailHistory: bucket 8 => events 3914 , sum = 34105
RPRINT Congestion_FailHistory: bucket 9 => events 3864 , sum = 37969
RPRINT Congestion_FailHistory: bucket 10 => events 3926 , sum = 41895
RPRINT Congestion_FailHistory: bucket 11 => events 4018 , sum = 45913
RPRINT Congestion_FailHistory: bucket 12 => events 3957 , sum = 49870
RPRINT Congestion_FailHistory: bucket 13 => events 3935 , sum = 53805
RPRINT Congestion_FailHistory: bucket 14 => events 3959 , sum = 57764
RPRINT Congestion_FailHistory: bucket 15 => events 3869 , sum = 61633
RPRINT Congestion_FailHistory: bucket 16 => events 3903 , sum = 65536
Events: 65536, CurIndex: 0, LastEvent: 299, HistLen: 306, BinLen: 18, Start: 0
RPRINT Congestion_FailHistory: 233|0|dummy_host| |per_ip| |F|0|0|1970/01/01 
00:03:53|0|299|65536|1|0
RPRINT Congestion_FailHistory: Verify the result
RPRINT Congestion_FailHistory: Content of history
RPRINT Congestion_FailHistory: bucket 0 => events 961 , sum = 961
RPRINT Congestion_FailHistory: bucket 1 => events 978 , sum = 1939
RPRINT Congestion_FailHistory: bucket 2 => events 602 , sum = 2541
RPRINT Congestion_FailHistory: bucket 3 => events 1011 , sum = 3552
RPRINT Congestion_FailHistory: bucket 4 => events 956 , sum = 4508
RPRINT Congestion_FailHistory: bucket 5 => events 1019 , sum = 5527
RPRINT Congestion_FailHistory: bucket 6 => events 992 , sum = 6519
RPRINT Congestion_FailHistory: bucket 7 => events 969 , sum = 7488
RPRINT Congestion_FailHistory: bucket 8 => events 1009 , sum = 8497
RPRINT Congestion_FailHistory: bucket 9 => events 950 , sum = 9447
RPRINT Congestion_FailHistory: bucket 10 => events 976 , sum = 10423
RPRINT Congestion_FailHistory: bucket 11 => events 974 , sum = 11397
RPRINT Congestion_FailHistory: bucket 12 => events 1007 , sum = 12404
RPRINT Congestion_FailHistory: bucket 13 => events 955 , sum = 13359
RPRINT Congestion_FailHistory: bucket 14 => events 998 , sum = 14357
RPRINT Congestion_FailHistory: bucket 15 => events 983 , sum = 15340
RPRINT Congestion_FailHistory: bucket 16 => events 1044 , sum = 16384
Events: 16384, CurIndex: 2, LastEvent: 2999, HistLen: 306, BinLen: 18, Start: 
2700
RPRINT Congestion_FailHistory: 2997|0|dummy_host| |per_ip| |F|0|0|1970/01/01 
00:49:57|0|2999|16384|1|0
REGRESSION_RESULT Congestion_FailHistory:   PASSED
REGRESSION TEST Congestion_HashTable started
RPRINT Congestion_HashTable: adding data into the hash table 
...done
RPRINT Congestion_HashTable: 1048576 data added into the hash table
RPRINT Congestion_HashTable: verifying the 

[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 I did look a bit more into the other backport-- and it seems that 
the outcome would be quite similar-- as the `handle_event` method is still 
using this `m_deleted` flag to determine if the struct was deleted, so it ends 
up being a superset of 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.
---

[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=30751=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30751
 ]

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

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

https://github.com/apache/trafficserver/pull/1109
  
@shinrich I did look a bit more into the other backport-- and it seems that 
the outcome would be quite similar-- as the `handle_event` method is still 
using this `m_deleted` flag to determine if the struct was deleted, so it ends 
up being a superset of this change.


Issue Time Tracking
---

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

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



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

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

[jpeach]

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

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

Since you are changing all these, what do you think about standardizing on:
```C
info.plugin_name   = PLUGIN_NAME;
info.vendor_name   = "Apache Software Foundation";
info.support_email = "d...@trafficserver.apache.org";
```


---
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=30747=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30747
 ]

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

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

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

Since you are changing all these, what do you think about standardizing on:
```C
info.plugin_name   = PLUGIN_NAME;
info.vendor_name   = "Apache Software Foundation";
info.support_email = "d...@trafficserver.apache.org";
```


Issue Time Tracking
---

Worklog Id: (was: 30747)
Time Spent: 4h  (was: 3h 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: 4h
>  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)

[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=30748=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30748
 ]

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

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

https://github.com/apache/trafficserver/pull/1114#discussion_r83665565
  
--- Diff: plugins/experimental/ats_pagespeed/gzip/misc.cc ---
@@ -157,7 +157,7 @@ register_plugin()
 const char *
 load_dictionary(const char *preload_file)
 {
-  char *dict   = (char *)malloc(80);
+  char *dict   = malloc(80);
--- End diff --

This hard-coded size seems a bit optimistic.


Issue Time Tracking
---

Worklog Id: (was: 30748)
Time Spent: 4h  (was: 3h 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: 4h
>  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)

[jira] [Work logged] (TS-4977) Adopt nullptr

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 17/Oct/16 15:24
Start Date: 17/Oct/16 15:24
Worklog Time Spent: 10m 
  Work Description: 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/1032/ for details.
 



Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #1112: TS-4977: 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/1032/ 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 #1114: TS-4971: Remove useless casts from plugins...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1114#discussion_r83667891
  
--- Diff: plugins/experimental/mysql_remap/mysql_remap.cc ---
@@ -232,7 +232,7 @@ TSPluginInit(int argc, const char *argv[])
 return;
   }
 
-  data->query = (char *)TSmalloc(QSIZE * sizeof(char)); // TODO: malloc 
smarter sizes
+  data->query = TSmalloc(QSIZE * sizeof(char)); // TODO: malloc smarter 
sizes
--- End diff --

Why no ``static_cast`` here?


---
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 #1114: TS-4971: Remove useless casts from plugins...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1114#discussion_r83665565
  
--- Diff: plugins/experimental/ats_pagespeed/gzip/misc.cc ---
@@ -157,7 +157,7 @@ register_plugin()
 const char *
 load_dictionary(const char *preload_file)
 {
-  char *dict   = (char *)malloc(80);
+  char *dict   = malloc(80);
--- End diff --

This hard-coded size seems a bit optimistic.


---
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: TS-4977: Prefer nullptr to NULL.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1112
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/924/ 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-4977) Adopt nullptr

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

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



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

[jira] [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=30746=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30746
 ]

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

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

https://github.com/apache/trafficserver/pull/1114#discussion_r83667891
  
--- Diff: plugins/experimental/mysql_remap/mysql_remap.cc ---
@@ -232,7 +232,7 @@ TSPluginInit(int argc, const char *argv[])
 return;
   }
 
-  data->query = (char *)TSmalloc(QSIZE * sizeof(char)); // TODO: malloc 
smarter sizes
+  data->query = TSmalloc(QSIZE * sizeof(char)); // TODO: malloc smarter 
sizes
--- End diff --

Why no ``static_cast`` here?


Issue Time Tracking
---

Worklog Id: (was: 30746)
Time Spent: 4h  (was: 3h 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: 4h
>  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)

[jira] [Commented] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4966:


I had problems cherry picking the commit above into 7.0.x.  If you would like 
to get this in for 7.0.x please make a pull request for the 7.0.x branch.


> Debug asserts fail when trying to schedule a continuation from a lifecycle 
> plugin message hook
> --
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The plugin message callback for the lifecycle hook is called from a special 
> core thread which is not an {{EThread}}. Because of this debug assertions 
> fail in {{TSContSchedule}} (and other API calls) because mutex operations 
> fail due to the lack of {{EThread}}.



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

[jira] [Comment Edited] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-4966 at 10/17/16 4:48 PM:
--

I had problems cherry picking this into the 7.0.x branch (hash 
837d838b096f9ec6d1a663dac136f294c73cda66). If you would like to get this into 
the 7.0.0 release please make a github pull request for the 7.0.x branch.


was (Author: bcall):
I had problems cherry picking the commit above into 7.0.x.  If you would like 
to get this in for 7.0.x please make a pull request for the 7.0.x branch.


> Debug asserts fail when trying to schedule a continuation from a lifecycle 
> plugin message hook
> --
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The plugin message callback for the lifecycle hook is called from a special 
> core thread which is not an {{EThread}}. Because of this debug assertions 
> fail in {{TSContSchedule}} (and other API calls) because mutex operations 
> fail due to the lack of {{EThread}}.



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

[jira] [Commented] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4879:


I had problems cherry picking this into the 7.0.x branch (hash 
cd3f83af040f9505a3224a41ce7de294899c760e).  If you would like to get this into 
the 7.0.0 release please make a github pull request for the 7.0.x branch.

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[jira] [Commented] (TS-4875) Hoist SSL index creation into library initialization.

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4875:


I had problems cherry picking this into the 7.0.x branch (hash 
bdc959056ac59bf0e4b1f210c87d8d072dcfd61b and 
db27c4a0b21c21c14997fdd4e310dbd8ec9ddd04).  If you would like to get this into 
the 7.0.0 release please make a github pull request for the 7.0.x branch.

> Hoist SSL index creation into library initialization.
> -
>
> Key: TS-4875
> URL: https://issues.apache.org/jira/browse/TS-4875
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> The SSL index used for server certificate validation can only be created 
> once, so we need to do it in the library initialization, not the client 
> context initialization. In principle, we can initialize client contexts 
> multiple times.



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

[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
  
After doing some more looking, the `m_deleted` flag is just marking the 
VConn as "we should delete this" and that combined with `m_deletable` lets it 
reschedule the delete in the future when it can. The fundamental problem I'm 
seeing is it is double freed under some conditions-- since all events trigger a 
delete. This is fixed in 7.x with  TS-4590 -- so I've updated this PR to 
workaround the issue in a simpler mechanism that more closely mirrors what is 
happening on 7.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-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1109
  
After doing some more looking, the `m_deleted` flag is just marking the 
VConn as "we should delete this" and that combined with `m_deletable` lets it 
reschedule the delete in the future when it can. The fundamental problem I'm 
seeing is it is double freed under some conditions-- since all events trigger a 
delete. This is fixed in 7.x with  TS-4590 -- so I've updated this PR to 
workaround the issue in a simpler mechanism that more closely mirrors what is 
happening on 7.x


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #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 *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1034/ 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 #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 *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/926/ 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=30765=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30765
 ]

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30765)
Time Spent: 4h 10m  (was: 4h)

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

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1035/ 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=30767=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30767
 ]

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30767)
Time Spent: 3h 50m  (was: 3h 40m)

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

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

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/927/ 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=30766=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30766
 ]

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

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

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



Issue Time Tracking
---

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

[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=30768=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30768
 ]

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30768)
Time Spent: 4h  (was: 3h 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: 4h
>  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-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30769)
Time Spent: 4h 10m  (was: 4h)

> 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: 4h 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 issue #1108: TS-4970: Crash in INKVConnInternal when handle_ev...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1108
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/928/ 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 #1108: TS-4970: Crash in INKVConnInternal when handle_ev...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1108
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1036/ 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=30770=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30770
 ]

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

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

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



Issue Time Tracking
---

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

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

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4909:
---
Backport to Version: 7.0.0

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

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

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-4909:
--

Assignee: Bryan Call

> 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
>Assignee: Bryan Call
> Fix For: 7.1.0
>
>  Time Spent: 2h 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)

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

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

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



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

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

[atsci]

Github user atsci commented on the issue:

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

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



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

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

[atsci]

Github user atsci commented on the issue:

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

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 17/Oct/16 20:04
Start Date: 17/Oct/16 20:04
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: 30762)
Time Spent: 4h  (was: 3h 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: 4h
>  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)

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

[Thomas Jackson (JIRA)]

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

Thomas Jackson commented on TS-4970:


after spending some time looking at it-- [~shinrich] is correct, I am mis-using 
the m_deleted field. Taking a step back, my primary issue with this bug is that 
we are double-freeing something. From looking at the diff of TS-4590 I see that 
the mechanism for doing this is by ussing the `m_free_magic` member, but that 
is a bit broken in 5.2 and 6.2. So, instead of the current patch I have I am 
changing to use the mutex pointer as the "are we deleted" flag to avoid double 
freeing. I've updated the PRs, and will ping back once I've finished rolling 
out the change on our infra.

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



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

[jira] [Updated] (TS-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4971:
---
Assignee: Alan M. Carroll

> 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
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 4h
>  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)

[jira] [Updated] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4879:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[jira] [Updated] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4879:
---
Backport to Version:   (was: 7.0.0)

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[jira] [Commented] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4879:


The change was minimal after the cherry pick, so I got it done.

The hash for the commit on the 7.0.x branch: 
85ca5b7c2895cd6115dacbcc8a061fb96cce3bc7

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

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

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4909:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> 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
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>  Time Spent: 2h 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)

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

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4909:
---
Backport to Version: 7.1.0  (was: 7.0.0)

> 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
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>  Time Spent: 2h 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)

[jira] [Updated] (TS-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4971:
---
Backport to Version:   (was: 7.0.0)

> 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
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 4h
>  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)

[jira] [Updated] (TS-4971) Change TSPluginRegistration and TSPluginRegister to take const data

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4971:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> 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
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 4h
>  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)

[jira] [Comment Edited] (TS-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-4883 at 10/17/16 9:11 PM:
--

I cherry picked only the pull request 1037 (hash 
a545a809ab5eae205ac8bab0c23fe01c4fca2fdd).


was (Author: bcall):
I cherry picked only the pull requst 1037 (hash 
a545a809ab5eae205ac8bab0c23fe01c4fca2fdd).

> Argument mismatch of the Thread::start call in EventProcessor::start
> 
>
> Key: TS-4883
> URL: https://issues.apache.org/jira/browse/TS-4883
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Masato Gosui
>Assignee: Phil Sorber
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> EventProcessor::start() calls Thread::start(), which takes 5 arguments: 
> # name
> # stacksize
> # f(function pointer to be executed by the thread)
> # a(argument for f)
> # stack(pointer to stack used by the thread)
> However the call to Thread::start() takes the pointer to stack as 4th 
> argument.



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

[jira] [Commented] (TS-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4883:


I cherry picked only the pull requst 1037 (hash 
a545a809ab5eae205ac8bab0c23fe01c4fca2fdd).

> Argument mismatch of the Thread::start call in EventProcessor::start
> 
>
> Key: TS-4883
> URL: https://issues.apache.org/jira/browse/TS-4883
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Masato Gosui
>Assignee: Phil Sorber
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> EventProcessor::start() calls Thread::start(), which takes 5 arguments: 
> # name
> # stacksize
> # f(function pointer to be executed by the thread)
> # a(argument for f)
> # stack(pointer to stack used by the thread)
> However the call to Thread::start() takes the pointer to stack as 4th 
> argument.



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

[jira] [Updated] (TS-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4883:
---
Backport to Version:   (was: 7.0.0)

> Argument mismatch of the Thread::start call in EventProcessor::start
> 
>
> Key: TS-4883
> URL: https://issues.apache.org/jira/browse/TS-4883
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Masato Gosui
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> EventProcessor::start() calls Thread::start(), which takes 5 arguments: 
> # name
> # stacksize
> # f(function pointer to be executed by the thread)
> # a(argument for f)
> # stack(pointer to stack used by the thread)
> However the call to Thread::start() takes the pointer to stack as 4th 
> argument.



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

[jira] [Updated] (TS-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4883:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> Argument mismatch of the Thread::start call in EventProcessor::start
> 
>
> Key: TS-4883
> URL: https://issues.apache.org/jira/browse/TS-4883
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Masato Gosui
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> EventProcessor::start() calls Thread::start(), which takes 5 arguments: 
> # name
> # stacksize
> # f(function pointer to be executed by the thread)
> # a(argument for f)
> # stack(pointer to stack used by the thread)
> However the call to Thread::start() takes the pointer to stack as 4th 
> argument.



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