[jira] [Work logged] (TS-4939) Diags doesn't print the tag name anymore

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Diags doesn't print the tag name anymore
> 
>
> Key: TS-4939
> URL: https://issues.apache.org/jira/browse/TS-4939
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Diags used to print the tag name in the output before.  It looks like it was 
> broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[jira] [Work logged] (TS-4939) Diags doesn't print the tag name anymore

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Diags doesn't print the tag name anymore
> 
>
> Key: TS-4939
> URL: https://issues.apache.org/jira/browse/TS-4939
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Diags used to print the tag name in the output before.  It looks like it was 
> broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[GitHub] trafficserver issue #1082: TS-4939: Print the debug tag in diagnostic messag...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1082
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/834/ 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 #1082: TS-4939: Print the debug tag in diagnostic messag...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1082
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/942/ 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-4939) Diags doesn't print the tag name anymore

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4939: Print the debug tag in diagnostic messages.



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

$ git pull https://github.com/jpeach/trafficserver fix/4939

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

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

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

This closes #1082


commit 4a555f42d1e519afa4bb3f4374ef2c99c0919f91
Author: James Peach 
Date:   2016-10-06T04:17:16Z

TS-4939: Print the debug tag in diagnostic messages.




Issue Time Tracking
---

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

> Diags doesn't print the tag name anymore
> 
>
> Key: TS-4939
> URL: https://issues.apache.org/jira/browse/TS-4939
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Diags used to print the tag name in the output before.  It looks like it was 
> broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[GitHub] trafficserver pull request #1082: TS-4939: Print the debug tag in diagnostic...

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4939: Print the debug tag in diagnostic messages.



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

$ git pull https://github.com/jpeach/trafficserver fix/4939

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

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

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

This closes #1082


commit 4a555f42d1e519afa4bb3f4374ef2c99c0919f91
Author: James Peach 
Date:   2016-10-06T04:17:16Z

TS-4939: Print the debug tag in diagnostic messages.




---
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: centos_7-master » gcc,centos_7,release #2042

[jenkins]

See 


--
[...truncated 20122 lines...]
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 
content..done
RPRINT Congestion_HashTable: removing data..done
RPRINT Congestion_HashTable: 524287 data entries are removed
RPRINT Congestion_HashTable: verify the content 
again..done
RPRINT Congestion_HashTable: use iterator to list all the elements and delete 
half of themdone
RPRINT Congestion_HashTable: verify the content once again...done
RPRINT Congestion_HashTable: remove everything using iterator...done
REGRESSION_RESULT Congestion_HashTable: PASSED
REGRESSION TEST SDK_API_TSHttpConnectServerIntercept started
== parsing

 real request (length=123)

GET http://www.padding.com:80/ HTTP/1.0
X-1: blah1
X-3:   blah3
X-5: blah5
X-7:   blah7
X-9: blah9



[GET http://www.padding.com:80/ HTTP/1.0
X-1: blah1
X-3:   blah3
X-5: blah5
X-7: blah7
X-9: blah9

]


 real response (length=163)

HTTP/1.0 200 OK
MIME-Version: 1.0
Server: WebSTAR/2.1 ID/30013
Content-Type: text/html
Content-Length: 939
Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT



[HTTP/1.0 200 OK
MIME-Version: 1.0
Server: WebSTAR/2.1 ID/30013
Content-Type: text/html
Content-Length: 939
Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT

]

{HTTP/1.0 200 OK\15\12MIME-Version: 1.0\15\12Server: WebSTAR/2.1 
ID/30013\15\12Content-Type: text/html\15\12Content-Length: 

Build failed in Jenkins: clang-analyzer #2686

[jenkins]

See 

Changes:

[Masaori Koshiba] TS-4934: Remove invalid assert

[James Peach] Make local_event_callbacks variable static.

--
[...truncated 5414 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%] 

[jira] [Work logged] (TS-3204) Crash when body_factory file is empty

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1081
  
In load_from_file(). If the file length is 0, it allocates a buffer with 
size 1 for the terminating NULL, and returns that with length 0.


Issue Time Tracking
---

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

> Crash when body_factory file is empty
> -
>
> Key: TS-3204
> URL: https://issues.apache.org/jira/browse/TS-3204
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Thomas Jackson
>Assignee: Jari Alhonen
> Fix For: sometime
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Reproducible on 5.0.x
> If you have a body factory page that is completely empty, after some time I 
> start getting very obscure crashes all over the place (ssl, remap, etc.). If 
> I add a single whitespace it works fine, seems that something in there 
> doesn't like empty files.



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

[GitHub] trafficserver issue #1081: TS-3204: Crash when body_factory file is empty

[alhonen]

Github user alhonen commented on the issue:

https://github.com/apache/trafficserver/pull/1081
  
In load_from_file(). If the file length is 0, it allocates a buffer with 
size 1 for the terminating NULL, and returns that with length 0.


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

Jenkins build is back to normal : centos_7-master » gcc,centos_7,debug #2042

[jenkins]

See 

Build failed in Jenkins: ubuntu_14_04-master » gcc,ubuntu_14_04,release #2269

[jenkins]

See 


--
[...truncated 1720 lines...]
/bin/bash ../../../libtool  --tag=CXX   --mode=link ccache c++ 
-Wno-unused-variable -std=c++11 -g -pipe -Wall -Wextra -Wno-ignored-qualifiers 
-Wno-unused-parameter -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing 
-Werror -Wno-invalid-offsetof -mcx16 -module -shared -avoid-version 
-export-symbols-regex 
'^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$'
  -o CustomErrorRemapPlugin.la -rpath 

 custom_error_remap_plugin/CustomErrorRemapPlugin.lo 
../../../lib/atscppapi/src/libatscppapi.la -lcap -lpcre -lz -lcrypt -lpthread 
-ldl 
/bin/bash ../../../libtool  --tag=CXX   --mode=link ccache c++ 
-Wno-unused-variable -std=c++11 -g -pipe -Wall -Wextra -Wno-ignored-qualifiers 
-Wno-unused-parameter -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing 
-Werror -Wno-invalid-offsetof -mcx16 -module -shared -avoid-version 
-export-symbols-regex 
'^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$'
  -o CustomResponse.la -rpath 

 customresponse/CustomResponse.lo ../../../lib/atscppapi/src/libatscppapi.la 
-lcap -lpcre -lz -lcrypt -lpthread -ldl 
libtool: link: ( cd ".libs" && rm -f "ClientRedirect.la" && ln -s 
"../ClientRedirect.la" "ClientRedirect.la" )
/bin/bash ../../../libtool  --tag=CXX   --mode=link ccache c++ 
-Wno-unused-variable -std=c++11 -g -pipe -Wall -Wextra -Wno-ignored-qualifiers 
-Wno-unused-parameter -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing 
-Werror -Wno-invalid-offsetof -mcx16 -module -shared -avoid-version 
-export-symbols-regex 
'^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$'
  -o GlobalHookPlugin.la -rpath 

 globalhook/GlobalHookPlugin.lo ../../../lib/atscppapi/src/libatscppapi.la 
-lcap -lpcre -lz -lcrypt -lpthread -ldl 
libtool: link: /usr/bin/nm -B  clientrequest/.libs/ClientRequest.o   | sed -n 
-e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | /bin/sed 
's/.* //' | sort | uniq > .libs/ClientRequest.exp
libtool: link: /bin/grep -E -e 
"^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$"
 ".libs/ClientRequest.exp" > ".libs/ClientRequest.expT"
libtool: link: mv -f ".libs/ClientRequest.expT" ".libs/ClientRequest.exp"
libtool: link: /usr/bin/nm -B  customresponse/.libs/CustomResponse.o   | sed -n 
-e 's/^.*[   ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | /bin/sed 
's/.* //' | sort | uniq > .libs/CustomResponse.exp
libtool: link: c++  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o  
clientrequest/.libs/ClientRequest.o   -Wl,-rpath 
-Wl,
 -Wl,-rpath 
-Wl,
 ../../../lib/atscppapi/src/.libs/libatscppapi.so -lcap -lpcre -lz -lcrypt 
-lpthread -ldl -L/usr/lib/gcc/x86_64-linux-gnu/4.8 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. -lstdc++ -lm -lc -lgcc_s 
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o  -O3 -mcx16  
 -Wl,-soname -Wl,ClientRequest.so -Wl,-retain-symbols-file 
-Wl,.libs/ClientRequest.exp -o .libs/ClientRequest.so
libtool: link: /usr/bin/nm -B  
custom_error_remap_plugin/.libs/CustomErrorRemapPlugin.o   | sed -n -e 's/^.*[  
  ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | /bin/sed 
's/.* //' | sort | uniq > .libs/CustomErrorRemapPlugin.exp
libtool: link: /bin/grep -E -e 
"^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$"
 ".libs/CustomResponse.exp" > 

Build failed in Jenkins: clang-analyzer #2685

[jenkins]

See 

Changes:

[Masaori Koshiba] TS-4905: Set parent NULL after destroy() is called

--
[...truncated 5414 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

Build failed in Jenkins: centos_7-master » gcc,centos_7,debug #2041

[jenkins]

See 


--
[...truncated 19113 lines...]
0|0|144.237.10.0|144.237.10.0|per_ip| |F|0|0|1970/01/01 
00:00:00|12905853032977407679|0|0|1|0
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 

[jira] [Work logged] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 01:41
Start Date: 06/Oct/16 01:41
Worklog Time Spent: 10m 
  Work Description: Github user masaori335 closed the pull request at:

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


Issue Time Tracking
---

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

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) at 
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[jira] [Resolved] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba resolved TS-4934.
-
Resolution: Fixed

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) at 
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[jira] [Work logged] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) at 
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[GitHub] trafficserver pull request #1080: TS-4934: Remove invalid assert

[masaori335]

Github user masaori335 closed the pull request at:

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


---
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 #1080: TS-4934: Remove invalid assert

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1080
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/941/ 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 #1080: TS-4934: Remove invalid assert

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1080
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/833/ 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-4934) Assert in Http2Stream::do_io_close() when active timeout

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) at 
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[jira] [Updated] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4934:

Backport to Version: 6.2.1, 7.0.0  (was: 7.0.0)

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) at 
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[jira] [Commented] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba commented on TS-4934:
-

We need to backport to 6.2.x too.
https://github.com/apache/trafficserver/blob/6.2.x/proxy/http2/Http2Stream.cc#L272-L273

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) at 
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[jira] [Resolved] (TS-4905) Crash when slow logging is enabled.

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba resolved TS-4905.
-
Resolution: Fixed

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: Masaori Koshiba
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Work logged] (TS-3204) Crash when body_factory file is empty

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash when body_factory file is empty
> -
>
> Key: TS-3204
> URL: https://issues.apache.org/jira/browse/TS-3204
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Thomas Jackson
>Assignee: Jari Alhonen
> Fix For: sometime
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Reproducible on 5.0.x
> If you have a body factory page that is completely empty, after some time I 
> start getting very obscure crashes all over the place (ssl, remap, etc.). If 
> I add a single whitespace it works fine, seems that something in there 
> doesn't like empty files.



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

[GitHub] trafficserver issue #1081: TS-3204: Crash when body_factory file is empty

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1081
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/832/ 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-4905) Crash when slow logging is enabled.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 01:27
Start Date: 06/Oct/16 01:27
Worklog Time Spent: 10m 
  Work Description: Github user masaori335 closed the pull request at:

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


Issue Time Tracking
---

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

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: Masaori Koshiba
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Work logged] (TS-3204) Crash when body_factory file is empty

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash when body_factory file is empty
> -
>
> Key: TS-3204
> URL: https://issues.apache.org/jira/browse/TS-3204
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Thomas Jackson
>Assignee: Jari Alhonen
> Fix For: sometime
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Reproducible on 5.0.x
> If you have a body factory page that is completely empty, after some time I 
> start getting very obscure crashes all over the place (ssl, remap, etc.). If 
> I add a single whitespace it works fine, seems that something in there 
> doesn't like empty files.



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

[GitHub] trafficserver issue #1081: TS-3204: Crash when body_factory file is empty

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1081
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/940/ 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-3204) Crash when body_factory file is empty

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-3204: Crash when body_factory file is empty

Set internal buffer to null for empty files to not follow the
crash-prone execution path.

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

$ git pull https://github.com/alhonen/trafficserver TS-3204

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

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

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

This closes #1081


commit 49f1d8f011eeb69dcb8ecf45232c68d13ae32aef
Author: Jari Alhonen 
Date:   2016-10-04T01:18:05Z

TS-3204: Crash when body_factory file is empty

Set internal buffer to null for empty files to not follow the
crash-prone execution path.




Issue Time Tracking
---

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

> Crash when body_factory file is empty
> -
>
> Key: TS-3204
> URL: https://issues.apache.org/jira/browse/TS-3204
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Thomas Jackson
>Assignee: Jari Alhonen
> Fix For: sometime
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Reproducible on 5.0.x
> If you have a body factory page that is completely empty, after some time I 
> start getting very obscure crashes all over the place (ssl, remap, etc.). If 
> I add a single whitespace it works fine, seems that something in there 
> doesn't like empty files.



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

[GitHub] trafficserver pull request #1081: TS-3204: Crash when body_factory file is e...

[alhonen]

GitHub user alhonen opened a pull request:

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

TS-3204: Crash when body_factory file is empty

Set internal buffer to null for empty files to not follow the
crash-prone execution path.

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

$ git pull https://github.com/alhonen/trafficserver TS-3204

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

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

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

This closes #1081


commit 49f1d8f011eeb69dcb8ecf45232c68d13ae32aef
Author: Jari Alhonen 
Date:   2016-10-04T01:18:05Z

TS-3204: Crash when body_factory file is empty

Set internal buffer to null for empty files to not follow the
crash-prone execution path.




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

[jenkins]

See 

Changes:

[James Peach] Add newlines between functions.

[James Peach] TS-4925: Manager pollMgmtProcessServer stuck with EBADF.

--
[...truncated 5414 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... [ 

[jira] [Updated] (TS-4908) HTTP2Stream tries to close a continuation twice when a transaction is done

[Bryan Call (JIRA)]

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

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

> HTTP2Stream tries to close a continuation twice when a transaction is done
> --
>
> Key: TS-4908
> URL: https://issues.apache.org/jira/browse/TS-4908
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: David Calavera
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> This causes an assertion error when ATS is built in debug mode. Pull Request 
> coming.



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

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

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4813.

Resolution: Fixed

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



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

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

[Bryan Call (JIRA)]

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

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

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



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

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

[Bryan Call (JIRA)]

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

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

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



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

[GitHub] trafficserver issue #1062: [TS-4908] Remove duplicated cancelling action.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1062
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/831/ 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-4908) HTTP2Stream tries to close a continuation twice when a transaction is done

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> HTTP2Stream tries to close a continuation twice when a transaction is done
> --
>
> Key: TS-4908
> URL: https://issues.apache.org/jira/browse/TS-4908
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: David Calavera
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> This causes an assertion error when ATS is built in debug mode. Pull Request 
> coming.



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

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

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4813:
---
Assignee: Susan Hinrichs

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



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

[jira] [Work logged] (TS-4908) HTTP2Stream tries to close a continuation twice when a transaction is done

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> HTTP2Stream tries to close a continuation twice when a transaction is done
> --
>
> Key: TS-4908
> URL: https://issues.apache.org/jira/browse/TS-4908
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: David Calavera
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> This causes an assertion error when ATS is built in debug mode. Pull Request 
> coming.



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

[GitHub] trafficserver issue #1062: [TS-4908] Remove duplicated cancelling action.

[atsci]

Github user atsci commented on the issue:

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



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

[jira] [Updated] (TS-4939) Diags doesn't print the tag name anymore

[James Peach (JIRA)]

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

James Peach updated TS-4939:

 Assignee: James Peach
Fix Version/s: 7.1.0

> Diags doesn't print the tag name anymore
> 
>
> Key: TS-4939
> URL: https://issues.apache.org/jira/browse/TS-4939
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: James Peach
> Fix For: 7.1.0
>
>
> Diags used to print the tag name in the output before.  It looks like it was 
> broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[jira] [Updated] (TS-4939) Diags doesn't print the tag name anymore

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4939:
---
  Affects Version/s: 7.0.0
Backport to Version: 7.0.0
   Priority: Blocker  (was: Major)

> Diags doesn't print the tag name anymore
> 
>
> Key: TS-4939
> URL: https://issues.apache.org/jira/browse/TS-4939
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.1.0
>
>
> Diags used to print the tag name in the output before.  It looks like it was 
> broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[jira] [Created] (TS-4939) Diags doesn't print the tag name anymore

[Bryan Call (JIRA)]

Bryan Call created TS-4939:
--

 Summary: Diags doesn't print the tag name anymore
 Key: TS-4939
 URL: https://issues.apache.org/jira/browse/TS-4939
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Bryan Call


Diags used to print the tag name in the output before.  It looks like it was 
broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[jira] [Work logged] (TS-4908) HTTP2Stream tries to close a continuation twice when a transaction is done

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> HTTP2Stream tries to close a continuation twice when a transaction is done
> --
>
> Key: TS-4908
> URL: https://issues.apache.org/jira/browse/TS-4908
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: David Calavera
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> This causes an assertion error when ATS is built in debug mode. Pull Request 
> coming.



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

[GitHub] trafficserver issue #1062: [TS-4908] Remove duplicated cancelling action.

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1062
  
[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] [Updated] (TS-4925) Manager puking EBADF everywhere

[James Peach (JIRA)]

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

James Peach updated TS-4925:

Backport to Version: 7.0.0

> Manager puking EBADF everywhere
> ---
>
> Key: TS-4925
> URL: https://issues.apache.org/jira/browse/TS-4925
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {noformat}
> [Oct  3 20:19:53.824] Manager {0x7f7b699a2800} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (9)
> ...
> {noformat}



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

[jira] [Resolved] (TS-4925) Manager puking EBADF everywhere

[James Peach (JIRA)]

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

James Peach resolved TS-4925.
-
Resolution: Fixed

> Manager puking EBADF everywhere
> ---
>
> Key: TS-4925
> URL: https://issues.apache.org/jira/browse/TS-4925
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {noformat}
> [Oct  3 20:19:53.824] Manager {0x7f7b699a2800} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (9)
> ...
> {noformat}



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

[jira] [Work logged] (TS-4925) Manager puking EBADF everywhere

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Manager puking EBADF everywhere
> ---
>
> Key: TS-4925
> URL: https://issues.apache.org/jira/browse/TS-4925
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {noformat}
> [Oct  3 20:19:53.824] Manager {0x7f7b699a2800} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (9)
> ...
> {noformat}



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

[GitHub] trafficserver pull request #1074: TS-4925: Manager pollMgmtProcessServer stu...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4937) Evaluate HostLookup code for SSL certificate matching.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4937:
---

Evaluate as in, test for performance ? Or functionality / correctness ?

> Evaluate HostLookup code for SSL certificate matching.
> --
>
> Key: TS-4937
> URL: https://issues.apache.org/jira/browse/TS-4937
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
> Fix For: sometime
>
>




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

[jira] [Updated] (TS-4935) Adding same element twice in a row damages DLL's structure silently

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4935:
--
Assignee: Gancho Tenev

> Adding same element twice in a row damages DLL's structure silently
> ---
>
> Key: TS-4935
> URL: https://issues.apache.org/jira/browse/TS-4935
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>
> If the DLL list (lib/ts/List.h)  is used improperly its internal structure 
> gets damaged silently without any indication to the caller (no assert or 
> return code).
> If the the same element is added twice in a row the element's “next” would 
> start pointing to the element itself and all the existing list content would 
> be lost. All further additions will be OK but the next list traversal will be 
> infinite.
> Also noticed that when a new element is added to the list the element’s 
> “prev” is not initialized (not a problem in the most common case but should 
> to be fixed).



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

[jira] [Updated] (TS-4938) Crash due to null client_vc

[Leif Hedstrom (JIRA)]

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

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

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[jira] [Commented] (TS-4938) Crash due to null client_vc

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4938:
---

This is a backport candidate for 7.0.0 and/or 6.2.1 ?

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[jira] [Updated] (TS-4937) Evaluate HostLookup code for SSL certificate matching.

[Leif Hedstrom (JIRA)]

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

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

> Evaluate HostLookup code for SSL certificate matching.
> --
>
> Key: TS-4937
> URL: https://issues.apache.org/jira/browse/TS-4937
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
> Fix For: sometime
>
>




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

[jira] [Assigned] (TS-4936) Add test coverage to CI.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reassigned TS-4936:
-

Assignee: Leif Hedstrom

> Add test coverage to CI.
> 
>
> Key: TS-4936
> URL: https://issues.apache.org/jira/browse/TS-4936
> Project: Traffic Server
>  Issue Type: Test
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: Infrastructure
>
>
> Add the {{ci/coverage}} script (or something equivalent) to CI so we can 
> generate current test code coverage data.



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

[jira] [Commented] (TS-4936) Add test coverage to CI.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4936:
---

This would be adequate to run say nightly? Like we do for Coverity.

> Add test coverage to CI.
> 
>
> Key: TS-4936
> URL: https://issues.apache.org/jira/browse/TS-4936
> Project: Traffic Server
>  Issue Type: Test
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: Infrastructure
>
>
> Add the {{ci/coverage}} script (or something equivalent) to CI so we can 
> generate current test code coverage data.



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

[jira] [Updated] (TS-4936) Add test coverage to CI.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4936:
--
Fix Version/s: (was: sometime)
   Infrastructure

> Add test coverage to CI.
> 
>
> Key: TS-4936
> URL: https://issues.apache.org/jira/browse/TS-4936
> Project: Traffic Server
>  Issue Type: Test
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: Infrastructure
>
>
> Add the {{ci/coverage}} script (or something equivalent) to CI so we can 
> generate current test code coverage data.



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

[jira] [Updated] (TS-4932) HTTP/2 tests.

[Leif Hedstrom (JIRA)]

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

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

> HTTP/2 tests.
> -
>
> Key: TS-4932
> URL: https://issues.apache.org/jira/browse/TS-4932
> Project: Traffic Server
>  Issue Type: Test
>Reporter: James Peach
> Fix For: sometime
>
>
> We need both integration tests and unit tests to verify HTTP/2 functionality. 
> There are a couple of unit tests, but nowhere near enough. There are no 
> integration tests in CI or that are easy for developers to run.



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

[jira] [Updated] (TS-4933) Test connection reuse

[Leif Hedstrom (JIRA)]

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

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

> Test connection reuse
> -
>
> Key: TS-4933
> URL: https://issues.apache.org/jira/browse/TS-4933
> Project: Traffic Server
>  Issue Type: Test
>Reporter: James Peach
> Fix For: 7.1.0
>
>
> Following on from TS-3959, [~nickm] wrote an integration test for reusing 
> keep alive connections that have been closed by the origin. Let's get this 
> into a test harness and make sure the same scenario works for parent proxy 
> scenarios.
> https://github.com/GUI/TS-3959



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

[jira] [Updated] (TS-4928) transactions should not destroy sessions

[Leif Hedstrom (JIRA)]

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

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

> transactions should not destroy sessions
> 
>
> Key: TS-4928
> URL: https://issues.apache.org/jira/browse/TS-4928
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: James Peach
> Fix For: 7.1.0
>
>
> In {{Http1ClientSession}} we find the following code:
> {noformat}
> void
> Http1ClientTransaction::transaction_done()
> {
>   current_reader = NULL;
>   // If the parent session is not in the closed state, the destroy will not 
> occur.
>   if (parent) {
> parent->destroy();
>   }
> }
> {noformat}
> the model, as I understand it, is that sessions own transactions, so it is 
> quite unexpected for the transaction to reach up an kill its parent. It is a 
> very surprising side-effect of {{transaction_done}} and means that this can 
> only be reliably used in the specific context of the calling code.
> Additionally, why isn't the parent cleared in {{destroy()}}? If it must be 
> NULL, we should have an assertion.



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

[jira] [Updated] (TS-4936) Add test coverage to CI.

[Leif Hedstrom (JIRA)]

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

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

> Add test coverage to CI.
> 
>
> Key: TS-4936
> URL: https://issues.apache.org/jira/browse/TS-4936
> Project: Traffic Server
>  Issue Type: Test
>Reporter: James Peach
> Fix For: sometime
>
>
> Add the {{ci/coverage}} script (or something equivalent) to CI so we can 
> generate current test code coverage data.



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

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

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4916:
--
Backport to Version: 6.2.1, 7.0.0

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



--
This message was sent by Atlassian 

[jira] [Updated] (TS-4935) Adding same element twice in a row damages DLL's structure silently

[Leif Hedstrom (JIRA)]

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

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

> Adding same element twice in a row damages DLL's structure silently
> ---
>
> Key: TS-4935
> URL: https://issues.apache.org/jira/browse/TS-4935
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>
> If the DLL list (lib/ts/List.h)  is used improperly its internal structure 
> gets damaged silently without any indication to the caller (no assert or 
> return code).
> If the the same element is added twice in a row the element's “next” would 
> start pointing to the element itself and all the existing list content would 
> be lost. All further additions will be OK but the next list traversal will be 
> infinite.
> Also noticed that when a new element is added to the list the element’s 
> “prev” is not initialized (not a problem in the most common case but should 
> to be fixed).



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

[jira] [Updated] (TS-4935) Adding same element twice in a row damages DLL's structure silently

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4935:
--
Backport to Version: 6.2.1, 7.0.0

> Adding same element twice in a row damages DLL's structure silently
> ---
>
> Key: TS-4935
> URL: https://issues.apache.org/jira/browse/TS-4935
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>
> If the DLL list (lib/ts/List.h)  is used improperly its internal structure 
> gets damaged silently without any indication to the caller (no assert or 
> return code).
> If the the same element is added twice in a row the element's “next” would 
> start pointing to the element itself and all the existing list content would 
> be lost. All further additions will be OK but the next list traversal will be 
> infinite.
> Also noticed that when a new element is added to the list the element’s 
> “prev” is not initialized (not a problem in the most common case but should 
> to be fixed).



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

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

[jpeach]

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

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

Can you re-read this on each check so that it is a dynamic configuration?


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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

What units are we working with here? ``ru_maxrss`` is in KB, but one would 
think that ``proxy.config.memory.max_usage`` is in bytes? 
``proxy.config.memory.max_usage`` as bytes makes sense because then you can do 
``proxy.config.memory.max_usage=100GB``.


Issue Time Tracking
---

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

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



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

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

[jpeach]

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

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

Add a metric for this case?


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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

s/baxed/based/


Issue Time Tracking
---

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

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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

Can you re-read this on each check so that it is a dynamic configuration?


Issue Time Tracking
---

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

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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

Add a metric for this case?


Issue Time Tracking
---

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

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



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

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

[jpeach]

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

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

What units are we working with here? ``ru_maxrss`` is in KB, but one would 
think that ``proxy.config.memory.max_usage`` is in bytes? 
``proxy.config.memory.max_usage`` as bytes makes sense because then you can do 
``proxy.config.memory.max_usage=100GB``.


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

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

[jpeach]

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

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

s/baxed/based/


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

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

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82054996
  
--- Diff: iocore/net/SSLCertLookup.cc ---
@@ -160,7 +160,40 @@ ticket_block_alloc(unsigned count)
 
   return ptr;
 }
+ssl_ticket_key_block *
+ssl_create_ticket_key_block_buffer(char *ticket_key_data, int 
ticket_key_len)
+{
+  ssl_ticket_key_block *keyblock = NULL;
+  int num_ticket_keys= ticket_key_len / 
sizeof(ssl_ticket_key_t);
+  if (num_ticket_keys == 0) {
+Error("SSL session ticket key is too short (>= 48 bytes are 
required)");
+goto fail;
+  }
+
+  // Increase the stats.
+  if (ssl_rsb != NULL) { // ssl_rsb is not initialized during the first 
run.
+SSL_INCREMENT_DYN_STAT(ssl_total_ticket_keys_renewed_stat);
+  }
--- End diff --

Sure


Issue Time Tracking
---

Worklog Id: (was: 30198)
Time Spent: 2h  (was: 1h 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: 2h
>  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 pull request #1024: TS-4858: fix memory leak of global_default...

[persiaAziz]

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82054996
  
--- Diff: iocore/net/SSLCertLookup.cc ---
@@ -160,7 +160,40 @@ ticket_block_alloc(unsigned count)
 
   return ptr;
 }
+ssl_ticket_key_block *
+ssl_create_ticket_key_block_buffer(char *ticket_key_data, int 
ticket_key_len)
+{
+  ssl_ticket_key_block *keyblock = NULL;
+  int num_ticket_keys= ticket_key_len / 
sizeof(ssl_ticket_key_t);
+  if (num_ticket_keys == 0) {
+Error("SSL session ticket key is too short (>= 48 bytes are 
required)");
+goto fail;
+  }
+
+  // Increase the stats.
+  if (ssl_rsb != NULL) { // ssl_rsb is not initialized during the first 
run.
+SSL_INCREMENT_DYN_STAT(ssl_total_ticket_keys_renewed_stat);
+  }
--- End diff --

Sure


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

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

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

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



Issue Time Tracking
---

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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82046421
  
--- Diff: iocore/net/SSLConfig.cc ---
@@ -243,6 +245,21 @@ SSLConfigParams::initialize()
   ats_free(ssl_server_ca_cert_filename);
   ats_free(CACertRelativePath);
 
+  REC_ReadConfigStringAlloc(ticket_key_filename, 
"proxy.config.ssl.server.ticket_key.filename");
--- End diff --

Add a newline to separate logically distinct code.


Issue Time Tracking
---

Worklog Id: (was: 30194)
Time Spent: 1.5h  (was: 1h 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: 1.5h
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

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

[atsci]

Github user atsci commented on the issue:

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

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

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82049092
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -2159,7 +2123,7 @@ ssl_callback_session_ticket(SSL *ssl, unsigned char 
*keyname, unsigned char *iv,
   ssl_ticket_key_block *keyblock = NULL;
   if (cc == NULL || cc->keyblock == NULL) {
 // Try the default
-keyblock = global_default_keyblock;
+keyblock = params->default_global_keyblock;
--- End diff --

OK, so as long as ``ssl_callback_session_ticket`` is called just once 
before the SSL config is destroyed we are OK. I'd feel more comfortable if 
there was a way to remove the keyblock from the SSL context after use so that 
we have less chance of a dangling pointer.


Issue Time Tracking
---

Worklog Id: (was: 30193)
Time Spent: 1.5h  (was: 1h 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: 1.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)

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82047142
  
--- Diff: iocore/net/SSLCertLookup.cc ---
@@ -160,7 +160,40 @@ ticket_block_alloc(unsigned count)
 
   return ptr;
 }
+ssl_ticket_key_block *
+ssl_create_ticket_key_block_buffer(char *ticket_key_data, int 
ticket_key_len)
+{
+  ssl_ticket_key_block *keyblock = NULL;
+  int num_ticket_keys= ticket_key_len / 
sizeof(ssl_ticket_key_t);
+  if (num_ticket_keys == 0) {
+Error("SSL session ticket key is too short (>= 48 bytes are 
required)");
+goto fail;
+  }
+
+  // Increase the stats.
+  if (ssl_rsb != NULL) { // ssl_rsb is not initialized during the first 
run.
+SSL_INCREMENT_DYN_STAT(ssl_total_ticket_keys_renewed_stat);
+  }
--- End diff --

Loading a ticket key should not have any side-effects on metrics. Since 
this was existing code, please file a new Jira to clean this up.


Issue Time Tracking
---

Worklog Id: (was: 30195)
Time Spent: 1.5h  (was: 1h 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: 1.5h
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

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

[atsci]

Github user atsci commented on the issue:

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

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

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82046288
  
--- Diff: iocore/net/SSLConfig.cc ---
@@ -243,6 +245,21 @@ SSLConfigParams::initialize()
   ats_free(ssl_server_ca_cert_filename);
   ats_free(CACertRelativePath);
 
+  REC_ReadConfigStringAlloc(ticket_key_filename, 
"proxy.config.ssl.server.ticket_key.filename");
+  int ticket_key_len;
+  ats_scoped_str 
ticket_key_path(Layout::relative_to(this->serverCertPathOnly, 
this->ticket_key_filename));
+  ats_scoped_str ticket_key_data;
+  if (ticket_key_filename != NULL) {
+ticket_key_data = readIntoBuffer(ticket_key_path, __func__, 
_key_len);
+  } else {
+// Generate a random ticket key
+ticket_key_len  = 48;
+ticket_key_data = (char *)ats_malloc(ticket_key_len);
+char *tmp_ptr   = ticket_key_data;
+RAND_bytes(reinterpret_cast(tmp_ptr), ticket_key_len);
+  }
--- End diff --

Simplify to this:
```C
if (ticket_key_filename) {
  int len;
  ats_scoped_str path(Layout::relative_to(this->serverCertPathOnly, 
this->ticket_key_filename));
  ats_scoped_str data = readIntoBuffer(path, __func__, );

  // XXX error checking?

  default_global_keyblock = ticket_block_XXX(data, len);
} else {
ssl_ticket_key_t key;
RAND_bytes(, sizeof(key));

   default_global_keyblock = ticket_block_XXX(, sizeof(key));
}

```

*or*

Add additional ticket block APIs:
```C
 ssl_ticket_key_block *ticket_block_alloc_random(unsigned count);
 ssl_ticket_key_block *ticket_block_read(const char *path);
```


Issue Time Tracking
---

Worklog Id: (was: 30192)
Time Spent: 1.5h  (was: 1h 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: 1.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)

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82044347
  
--- Diff: iocore/net/P_SSLCertLookup.h ---
@@ -110,5 +109,5 @@ struct SSLCertLookup : public ConfigInfo {
 
 void ticket_block_free(void *ptr);
 ssl_ticket_key_block *ticket_block_alloc(unsigned count);
-
+ssl_ticket_key_block *ssl_create_ticket_key_block_buffer(char 
*ticket_key_data, int ticket_key_len);
--- End diff --

Please use a consistent naming convention. We have``ticket_block_free()``, 
``ticket_block_alloc()``,  so consider ``ticket_block_create()`` or something.


Issue Time Tracking
---

Worklog Id: (was: 30191)
Time Spent: 1.5h  (was: 1h 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: 1.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)

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82048013
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -2149,6 +2112,7 @@ ssl_callback_session_ticket(SSL *ssl, unsigned char 
*keyname, unsigned char *iv,
 int enc)
 {
   SSLCertificateConfig::scoped_config lookup;
+  SSLConfig::scoped_config params;
--- End diff --

Move this inside keyblock check so that we don't try to acquire the config 
unless we need it.


Issue Time Tracking
---

Worklog Id: (was: 30190)
Time Spent: 1.5h  (was: 1h 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: 1.5h
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

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

[jpeach]

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82046421
  
--- Diff: iocore/net/SSLConfig.cc ---
@@ -243,6 +245,21 @@ SSLConfigParams::initialize()
   ats_free(ssl_server_ca_cert_filename);
   ats_free(CACertRelativePath);
 
+  REC_ReadConfigStringAlloc(ticket_key_filename, 
"proxy.config.ssl.server.ticket_key.filename");
--- End diff --

Add a newline to separate logically distinct code.


---
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 #1024: TS-4858: fix memory leak of global_default...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82047142
  
--- Diff: iocore/net/SSLCertLookup.cc ---
@@ -160,7 +160,40 @@ ticket_block_alloc(unsigned count)
 
   return ptr;
 }
+ssl_ticket_key_block *
+ssl_create_ticket_key_block_buffer(char *ticket_key_data, int 
ticket_key_len)
+{
+  ssl_ticket_key_block *keyblock = NULL;
+  int num_ticket_keys= ticket_key_len / 
sizeof(ssl_ticket_key_t);
+  if (num_ticket_keys == 0) {
+Error("SSL session ticket key is too short (>= 48 bytes are 
required)");
+goto fail;
+  }
+
+  // Increase the stats.
+  if (ssl_rsb != NULL) { // ssl_rsb is not initialized during the first 
run.
+SSL_INCREMENT_DYN_STAT(ssl_total_ticket_keys_renewed_stat);
+  }
--- End diff --

Loading a ticket key should not have any side-effects on metrics. Since 
this was existing code, please file a new Jira to clean this up.


---
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 #1024: TS-4858: fix memory leak of global_default...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82049092
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -2159,7 +2123,7 @@ ssl_callback_session_ticket(SSL *ssl, unsigned char 
*keyname, unsigned char *iv,
   ssl_ticket_key_block *keyblock = NULL;
   if (cc == NULL || cc->keyblock == NULL) {
 // Try the default
-keyblock = global_default_keyblock;
+keyblock = params->default_global_keyblock;
--- End diff --

OK, so as long as ``ssl_callback_session_ticket`` is called just once 
before the SSL config is destroyed we are OK. I'd feel more comfortable if 
there was a way to remove the keyblock from the SSL context after use so that 
we have less chance of a dangling pointer.


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

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

[jpeach]

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82044347
  
--- Diff: iocore/net/P_SSLCertLookup.h ---
@@ -110,5 +109,5 @@ struct SSLCertLookup : public ConfigInfo {
 
 void ticket_block_free(void *ptr);
 ssl_ticket_key_block *ticket_block_alloc(unsigned count);
-
+ssl_ticket_key_block *ssl_create_ticket_key_block_buffer(char 
*ticket_key_data, int ticket_key_len);
--- End diff --

Please use a consistent naming convention. We have``ticket_block_free()``, 
``ticket_block_alloc()``,  so consider ``ticket_block_create()`` or something.


---
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 #1024: TS-4858: fix memory leak of global_default...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1024#discussion_r82046288
  
--- Diff: iocore/net/SSLConfig.cc ---
@@ -243,6 +245,21 @@ SSLConfigParams::initialize()
   ats_free(ssl_server_ca_cert_filename);
   ats_free(CACertRelativePath);
 
+  REC_ReadConfigStringAlloc(ticket_key_filename, 
"proxy.config.ssl.server.ticket_key.filename");
+  int ticket_key_len;
+  ats_scoped_str 
ticket_key_path(Layout::relative_to(this->serverCertPathOnly, 
this->ticket_key_filename));
+  ats_scoped_str ticket_key_data;
+  if (ticket_key_filename != NULL) {
+ticket_key_data = readIntoBuffer(ticket_key_path, __func__, 
_key_len);
+  } else {
+// Generate a random ticket key
+ticket_key_len  = 48;
+ticket_key_data = (char *)ats_malloc(ticket_key_len);
+char *tmp_ptr   = ticket_key_data;
+RAND_bytes(reinterpret_cast(tmp_ptr), ticket_key_len);
+  }
--- End diff --

Simplify to this:
```C
if (ticket_key_filename) {
  int len;
  ats_scoped_str path(Layout::relative_to(this->serverCertPathOnly, 
this->ticket_key_filename));
  ats_scoped_str data = readIntoBuffer(path, __func__, );

  // XXX error checking?

  default_global_keyblock = ticket_block_XXX(data, len);
} else {
ssl_ticket_key_t key;
RAND_bytes(, sizeof(key));

   default_global_keyblock = ticket_block_XXX(, sizeof(key));
}

```

*or*

Add additional ticket block APIs:
```C
 ssl_ticket_key_block *ticket_block_alloc_random(unsigned count);
 ssl_ticket_key_block *ticket_block_read(const char *path);
```


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

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

Author: ASF GitHub Bot
Created on: 05/Oct/16 19:15
Start Date: 05/Oct/16 19:15
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: 30189)
Time Spent: 1h 20m  (was: 1h 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: 1h 20m
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

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

[shinrich]

Github user shinrich commented on the issue:

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


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver pull request #1052: TS-4813: Fix lingering stream.

[shinrich]

Github user shinrich closed the pull request at:

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


---
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 #1052: TS-4813: Fix lingering stream.

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
@zwoop says docs has been running with this fix for 24 hours.  I ran in 
production for a few hours.  Had crashes due to TS-4915 and a new one due to 
TS-4938, but nothing related to this issue.


---
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-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1052
  
@zwoop says docs has been running with this fix for 24 hours.  I ran in 
production for a few hours.  Had crashes due to TS-4915 and a new one due to 
TS-4938, but nothing related to this issue.


Issue Time Tracking
---

Worklog Id: (was: 30187)
Time Spent: 5h  (was: 4h 50m)

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



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

[jira] [Assigned] (TS-4938) Crash due to null client_vc

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs reassigned TS-4938:
--

Assignee: Susan Hinrichs

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[jira] [Created] (TS-4938) Crash due to null client_vc

[Susan Hinrichs (JIRA)]

Susan Hinrichs created TS-4938:
--

 Summary: Crash due to null client_vc
 Key: TS-4938
 URL: https://issues.apache.org/jira/browse/TS-4938
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Susan Hinrichs


Saw this crash while testing fix for TS-4813.  Have a fix that checks 
get_netvc() returns a non-NULL.  Should make a more comprehensive review on the 
use of get_netvc() in HttpTransact.cc/HttpSM.cc

{code}
#0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
../iocore/net/P_NetVConnection.h:60
#1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
../iocore/net/P_NetVConnection.h:82
#2  0x00627844 in HttpTransact::initialize_state_variables_from_request 
(s=0x2b65700d4a98, obsolete_incoming_request=0x2b65700d51b8)
at HttpTransact.cc:5709
#3  0x00632bd1 in HttpTransact::build_error_response (s=0x2b65700d4a98, 
status_code=HTTP_STATUS_BAD_GATEWAY, 
reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
"connect#hangup", format=0x0) at HttpTransact.cc:8141
#4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
at HttpTransact.cc:7789
#5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
(s=0x2b65700d4a98) at HttpTransact.cc:3991
#6  0x0061fd43 in HttpTransact::handle_response_from_server 
(s=0x2b65700d4a98) at HttpTransact.cc:3824
#7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
HttpTransact.cc:3401
#8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
(this=0x2b65700d4a20, 
f=0x61cf9a ) at 
HttpSM.cc:7116
#9  0x005f6902 in HttpSM::handle_server_setup_error 
(this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
#10 0x005e88a4 in HttpSM::state_send_server_request_header 
(this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
#11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, event=104, 
data=0x2aabd00372d8) at HttpSM.cc:2655
#12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
#13 0x0079906f in write_signal_and_update (event=104, 
vc=0x2aabd0037140) at UnixNetVConnection.cc:174
#14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
vc=0x2aabd0037140) at UnixNetVConnection.cc:216
#15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
#16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
#17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
event=5, e=0x1646ac0) at UnixNet.cc:515
#18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
#19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
#20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
UnixEThread.cc:270
#21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
#22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
#23 0x0032310e893d in clone () from /lib64/libc.so.6
{code}



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

[jira] [Work logged] (TS-4866) Remove traffic_cop health checking

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1035
  
+1 on metric for this :)


Issue Time Tracking
---

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

> Remove traffic_cop health checking
> --
>
> Key: TS-4866
> URL: https://issues.apache.org/jira/browse/TS-4866
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Cop
>Affects Versions: 7.0.0
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> There is a school of thought that {{traffic_cop}} health checking causes more 
> problems that in solves. Consider whether we should eliminate health checking 
> from {{traffic_cop}}.



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

[GitHub] trafficserver issue #1035: TS-4866: Makes traffic_cop killing optional

[jacksontj]

Github user jacksontj commented on the issue:

https://github.com/apache/trafficserver/pull/1035
  
+1 on metric for this :)


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