[jira] [Commented] (TS-4482) Add API for custom log field (note)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4482:


Github user atsci commented on the issue:

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



> Add API for custom log field (note)
> ---
>
> Key: TS-4482
> URL: https://issues.apache.org/jira/browse/TS-4482
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: CPP API, Logging, TS API
>Reporter: yukihisa ishimura
>Assignee: Brian Geffon
> Fix For: 7.0.0
>
>
> Although I would like to output the processing result in my plugin to a 
> custom log, with the exception of the header, the field does not exist in 
> order to output freely.



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

[jira] [Commented] (TS-4482) Add API for custom log field (note)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4482:


Github user atsci commented on the issue:

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



> Add API for custom log field (note)
> ---
>
> Key: TS-4482
> URL: https://issues.apache.org/jira/browse/TS-4482
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: CPP API, Logging, TS API
>Reporter: yukihisa ishimura
>Assignee: Brian Geffon
> Fix For: 7.0.0
>
>
> Although I would like to output the processing result in my plugin to a 
> custom log, with the exception of the header, the field does not exist in 
> order to output freely.



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

[jira] [Commented] (TS-4482) Add API for custom log field (note)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4482:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/664
  
Testing again, this will blow up and I'm blaming @PSUdaemon [approve ci]


> Add API for custom log field (note)
> ---
>
> Key: TS-4482
> URL: https://issues.apache.org/jira/browse/TS-4482
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: CPP API, Logging, TS API
>Reporter: yukihisa ishimura
>Assignee: Brian Geffon
> Fix For: 7.0.0
>
>
> Although I would like to output the processing result in my plugin to a 
> custom log, with the exception of the header, the field does not exist in 
> order to output freely.



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

[jira] [Commented] (TS-4503) MachineFatal should shutdown without cleanup

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4503:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/694
  
Testing again, this will blow up and I'm blaming @PSUdaemon [approve ci]


> MachineFatal should shutdown without cleanup
> 
>
> Key: TS-4503
> URL: https://issues.apache.org/jira/browse/TS-4503
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> When MachineFatalClass::raise() is called, it prints a message to the log and 
> then calls exit.  exit causes memory cleanup to be called.  But if we are in 
> such bad state that MachineFatal is called, it is quite likely that memory is 
> messed up.
> We saw a crash where MachineFatal is called in thread 84.  This stack has the 
> real error.  But the stack that got reported was on thread 1 in class 
> destructor logic.  It would have been better if ATS failed immediately and 
> the stack on thread 84 was reported.



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

[jira] [Commented] (TS-4503) MachineFatal should shutdown without cleanup

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4503:


Github user atsci commented on the issue:

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



> MachineFatal should shutdown without cleanup
> 
>
> Key: TS-4503
> URL: https://issues.apache.org/jira/browse/TS-4503
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> When MachineFatalClass::raise() is called, it prints a message to the log and 
> then calls exit.  exit causes memory cleanup to be called.  But if we are in 
> such bad state that MachineFatal is called, it is quite likely that memory is 
> messed up.
> We saw a crash where MachineFatal is called in thread 84.  This stack has the 
> real error.  But the stack that got reported was on thread 1 in class 
> destructor logic.  It would have been better if ATS failed immediately and 
> the stack on thread 84 was reported.



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

[jira] [Commented] (TS-4503) MachineFatal should shutdown without cleanup

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4503:


Github user atsci commented on the issue:

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



> MachineFatal should shutdown without cleanup
> 
>
> Key: TS-4503
> URL: https://issues.apache.org/jira/browse/TS-4503
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> When MachineFatalClass::raise() is called, it prints a message to the log and 
> then calls exit.  exit causes memory cleanup to be called.  But if we are in 
> such bad state that MachineFatal is called, it is quite likely that memory is 
> messed up.
> We saw a crash where MachineFatal is called in thread 84.  This stack has the 
> real error.  But the stack that got reported was on thread 1 in class 
> destructor logic.  It would have been better if ATS failed immediately and 
> the stack on thread 84 was reported.



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

[jira] [Commented] (TS-4503) MachineFatal should shutdown without cleanup

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4503:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/694
  
Testing, this will blow up and I'm blaming @PSUdaemon  [approve ci]


> MachineFatal should shutdown without cleanup
> 
>
> Key: TS-4503
> URL: https://issues.apache.org/jira/browse/TS-4503
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> When MachineFatalClass::raise() is called, it prints a message to the log and 
> then calls exit.  exit causes memory cleanup to be called.  But if we are in 
> such bad state that MachineFatal is called, it is quite likely that memory is 
> messed up.
> We saw a crash where MachineFatal is called in thread 84.  This stack has the 
> real error.  But the stack that got reported was on thread 1 in class 
> destructor logic.  It would have been better if ATS failed immediately and 
> the stack on thread 84 was reported.



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

[jira] [Commented] (TS-4470) ASAN stack-buffer-overflow when slow log is enabled

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4470:


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

https://github.com/apache/trafficserver/pull/721#discussion_r67789890
  
--- Diff: proxy/http/HttpSM.cc ---
@@ -6890,7 +6890,8 @@ HttpSM::update_stats()
 int offset = 0;
 int skip = 0;
 
-t_state.hdr_info.client_request.url_print(url_string, sizeof 
url_string, , );
+t_state.hdr_info.client_request.url_print(url_string, 
sizeof(url_string), , );
+url_string[sizeof(url_string) - 1] = 0; // NULL terminate the string
--- End diff --

Yeah, that would be better.


> ASAN stack-buffer-overflow when slow log is enabled
> ---
>
> Key: TS-4470
> URL: https://issues.apache.org/jira/browse/TS-4470
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>
> =
> ==13159==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x2b5ec8877660 at pc 0x004fcdf1 bp 0x2b5ec8875c60 sp 0x2b5ec8875410
> READ of size 260 at 0x2b5ec8877660 thread T21 ([ET_NET 20])
> #0 0x4fcdf0 in printf_common(void*, char const*, __va_list_tag*) [clone 
> .isra.6] (/usr/local/bin/traffic_server+0x4fcdf0)
> #1 0x4fd744 in vfprintf (/usr/local/bin/traffic_server+0x4fd744)
> #2 0x2b5ec1a668ee in vprintline<1024> 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:61
> #3 0x2b5ec1a668ee in Diags::print_va(char const*, DiagsLevel, SrcLoc 
> const*, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:340
> #4 0x2b5ec1a6765f in Diags::error_va(DiagsLevel, char const*, char 
> const*, int, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:572
> #5 0x72a724 in Diags::error(DiagsLevel, char const*, char const*, int, 
> char const*, ...) const /home/bcall/dev/trafficserver/lib/ts/Diags.h:242
> #6 0x7455d6 in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6972
> #7 0x77b07f in HttpSM::kill_this() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6786
> #8 0x77d6f7 in HttpSM::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:2660
> #9 0x832d3a in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #10 0x832d3a in HttpTunnel::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpTunnel.cc:1637
> #11 0xcfdbb5 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #12 0xcfdbb5 in write_signal_and_update 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:181
> #13 0xcfdbb5 in write_signal_done 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:223
> #14 0xcfdbb5 in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:563
> #15 0xcbc4ca in NetHandler::mainNetEvent(int, Event*) 
> /home/bcall/dev/trafficserver/iocore/net/UnixNet.cc:529
> #16 0xda8ce3 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #17 0xda8ce3 in EThread::process_event(Event*, int) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #18 0xdabc8a in EThread::execute() 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #19 0xda7a58 in spawn_thread_internal 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:86
> #20 0x2b5ec2264aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #21 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> Address 0x2b5ec8877660 is located in stack of thread T21 ([ET_NET 20]) at 
> offset 736 in frame
> #0 0x7443ef in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6827
>   This frame has 6 object(s):
> [32, 36) 'offset'
> [96, 100) 'skip'
> [160, 164) 'length'
> [224, 270) 'client_ip'
> [320, 448) 'unique_id_string'
> [480, 736) 'url_string' <== Memory access at offset 736 overflows this 
> variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism or swapcontext
>   (longjmp and C++ exceptions *are* supported)
> Thread T21 ([ET_NET 20]) created by T0 ([ET_NET 0]) here:
> #0 0x4d50b4 in pthread_create (/usr/local/bin/traffic_server+0x4d50b4)
> #1 0xda85aa in ink_thread_create 
> 

Build failed in Jenkins: clang-analyzer #2432

[jenkins]

See 

--
[...truncated 5080 lines...]
reading sources... [ 52%] developer-guide/api/functions/TSMimeHdrFieldDestroy.en
reading sources... [ 52%] developer-guide/api/functions/TSMimeHdrFieldFind.en
reading sources... [ 53%] developer-guide/api/functions/TSMimeHdrFieldGet.en
reading sources... [ 53%] 
developer-guide/api/functions/TSMimeHdrFieldLengthGet.en
reading sources... [ 53%] developer-guide/api/functions/TSMimeHdrFieldNameGet.en
reading sources... [ 53%] developer-guide/api/functions/TSMimeHdrFieldNameSet.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldNext.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldNextDup.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldRemove.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueIntSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesClear.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsClear.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrLengthGet.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrParse.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeHdrPrint.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserClear.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserDestroy.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexCreate.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexDestroy.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLock.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLockTry.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexUnlock.en
reading sources... [ 60%] developer-guide/api/functions/TSNetAccept.en
reading sources... [ 60%] 
developer-guide/api/functions/TSNetAcceptNamedProtocol.en
reading sources... [ 60%] developer-guide/api/functions/TSNetConnect.en
reading sources... [ 60%] developer-guide/api/functions/TSPluginInit.en
reading sources... [ 60%] developer-guide/api/functions/TSRemap.en
reading sources... [ 61%] developer-guide/api/functions/TSSslContextFindBy.en
reading sources... [ 61%] 
developer-guide/api/functions/TSSslServerContextCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSTextLogObjectCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadCreate.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadDestroy.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadInit.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadSelf.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTrafficServerVersionGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 63%] 
developer-guide/api/functions/TSTransformOutputVConnGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTypes.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlCreate.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlDestroy.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostSet.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnAbort.en
reading sources... [ 65%] 
developer-guide/api/functions/TSVConnCacheObjectSizeGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnClose.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnClosedGet.en
reading sources... [ 66%] 

[jira] [Updated] (TS-4526) ASAN SEGV on unknown address (6.2.0)

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4526:
---
Backport to Version:   (was: 6.2.0)

> ASAN SEGV on unknown address (6.2.0)
> 
>
> Key: TS-4526
> URL: https://issues.apache.org/jira/browse/TS-4526
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>
> {code}
> ASAN:SIGSEGV
> =
> ==11217==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
> 0x sp 0x2b853414daf8 bp 0x2b853414dc00 T6)
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x4c73ca in pthread_create (/home/y/bin64/traffic_server+0x4c73ca)
> #1 0xe9ee75 in ink_thread_create 
> ../../../trafficserver/lib/ts/ink_thread.h:147
> #2 0xe9ee75 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) ../../../trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xea8389 in EventProcessor::start(int, unsigned long) 
> ../../../trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ac4b7 in main ../../trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> ==11217==ABORTING
> {code}



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

[jira] [Updated] (TS-4526) ASAN SEGV on unknown address (6.2.0)

[Bryan Call (JIRA)]

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

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

> ASAN SEGV on unknown address (6.2.0)
> 
>
> Key: TS-4526
> URL: https://issues.apache.org/jira/browse/TS-4526
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>
> {code}
> ASAN:SIGSEGV
> =
> ==11217==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
> 0x sp 0x2b853414daf8 bp 0x2b853414dc00 T6)
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x4c73ca in pthread_create (/home/y/bin64/traffic_server+0x4c73ca)
> #1 0xe9ee75 in ink_thread_create 
> ../../../trafficserver/lib/ts/ink_thread.h:147
> #2 0xe9ee75 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) ../../../trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xea8389 in EventProcessor::start(int, unsigned long) 
> ../../../trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ac4b7 in main ../../trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> ==11217==ABORTING
> {code}



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

[jira] [Assigned] (TS-4526) ASAN SEGV on unknown address (6.2.0)

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-4526:
--

Assignee: Bryan Call

> ASAN SEGV on unknown address (6.2.0)
> 
>
> Key: TS-4526
> URL: https://issues.apache.org/jira/browse/TS-4526
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>
> {code}
> ASAN:SIGSEGV
> =
> ==11217==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
> 0x sp 0x2b853414daf8 bp 0x2b853414dc00 T6)
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x4c73ca in pthread_create (/home/y/bin64/traffic_server+0x4c73ca)
> #1 0xe9ee75 in ink_thread_create 
> ../../../trafficserver/lib/ts/ink_thread.h:147
> #2 0xe9ee75 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) ../../../trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xea8389 in EventProcessor::start(int, unsigned long) 
> ../../../trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ac4b7 in main ../../trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> ==11217==ABORTING
> {code}



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

[jira] [Resolved] (TS-4526) ASAN SEGV on unknown address (6.2.0)

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4526.

Resolution: Cannot Reproduce

I haven't seen this in awhile

> ASAN SEGV on unknown address (6.2.0)
> 
>
> Key: TS-4526
> URL: https://issues.apache.org/jira/browse/TS-4526
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ASAN:SIGSEGV
> =
> ==11217==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
> 0x sp 0x2b853414daf8 bp 0x2b853414dc00 T6)
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x4c73ca in pthread_create (/home/y/bin64/traffic_server+0x4c73ca)
> #1 0xe9ee75 in ink_thread_create 
> ../../../trafficserver/lib/ts/ink_thread.h:147
> #2 0xe9ee75 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) ../../../trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xea8389 in EventProcessor::start(int, unsigned long) 
> ../../../trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ac4b7 in main ../../trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> ==11217==ABORTING
> {code}



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

[jira] [Commented] (TS-4566) Disable all clang-analyzer checks for LuaJIT

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on TS-4566:
-

Commit 71b13803b50cf0545f47af0118a9668b1e3a4c2a in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=71b1380 ]

TS-4566: Try harder to exclude LuaJIT from static analysis.


> Disable all clang-analyzer checks for LuaJIT
> 
>
> Key: TS-4566
> URL: https://issues.apache.org/jira/browse/TS-4566
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Lua
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> For now, we need to turn off the clang-analyzer checks in the LuaJIT tree. 
> This is "new" since we now (as of 7.0.0) require Lua.



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

[jira] [Commented] (TS-4566) Disable all clang-analyzer checks for LuaJIT

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on TS-4566:
-

Commit 3276feb6c9fdaab1dc5bc13628198f00223dcf53 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3276feb ]

TS-4566: Fix LUA_CFLAGS whitespacing.

If LUA_CFLAGS get set, the AC_SUBST ends up being sensitive to
whitespace. Use TS_ADDTO() which deals with this.


> Disable all clang-analyzer checks for LuaJIT
> 
>
> Key: TS-4566
> URL: https://issues.apache.org/jira/browse/TS-4566
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Lua
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> For now, we need to turn off the clang-analyzer checks in the LuaJIT tree. 
> This is "new" since we now (as of 7.0.0) require Lua.



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

[jira] [Resolved] (TS-4565) clang_format: Align assignment on the =

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-4565.
---
Resolution: Fixed

> clang_format: Align assignment on the =
> ---
>
> Key: TS-4565
> URL: https://issues.apache.org/jira/browse/TS-4565
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
>   -AlignConsecutiveAssignments: false
> +AlignConsecutiveAssignments: true



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

[jira] [Resolved] (TS-3733) 'traffic_line -c' won't clear statistics on node

[Phil Sorber (JIRA)]

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

Phil Sorber resolved TS-3733.
-
   Resolution: Duplicate
Fix Version/s: (was: 7.0.0)

> 'traffic_line -c' won't clear statistics on node
> 
>
> Key: TS-3733
> URL: https://issues.apache.org/jira/browse/TS-3733
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Philip Ye
>Assignee: John Rushford
>  Labels: regression
>
> Previously in 5.1.2 version of trafficserver, running 'traffic_line -c' in a 
> node will clear all statistics on that node. However, in 5.2.0 version of 
> trafficserver, running 'traffic_line -c' won't clear any statistics. The same 
> issue can be found in 5.3.0. 
> I believe there's no usage change for this command, as it is still documented 
> in  traffic_line's command reference guide 
> (https://docs.trafficserver.apache.org/en/latest/reference/commands/traffic_line.en.html)



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

Jenkins build is back to normal : centos_7-master » clang,centos_7,debug #1786

[jenkins]

See 

[jira] [Updated] (TS-1642) Need sum up memory used in dir index

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-1642:
--
Labels:   (was: newbie)

> Need sum up memory used in dir index
> 
>
> Key: TS-1642
> URL: https://issues.apache.org/jira/browse/TS-1642
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Zhao Yongming
> Fix For: sometime
>
>
> when we checking the memory usage in ATS, the ram and dir index usage always 
> metter. we should print out the total memory used in dir index after cache 
> init done, or add a stat for it.



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

[jira] [Updated] (TS-4562) Plugin metrics only increment on net threads

[Leif Hedstrom (JIRA)]

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

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

> Plugin metrics only increment on net threads
> 
>
> Key: TS-4562
> URL: https://issues.apache.org/jira/browse/TS-4562
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Metrics, Plugins
>Reporter: James Peach
> Fix For: sometime
>
>
> This was a surprising one to me. I have a background thread (created with 
> {{TSThreadCreate}}) doing some periodic work, and I noticed that it wasn't 
> incrementing its metrics. It turns out that metrics can only be incremented 
> on an {{Ethread}}, which is a bit surprising and inconvenient.



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

[jira] [Updated] (TS-4564) Document metrics.config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4564:
--
Fix Version/s: Docs

> Document metrics.config
> ---
>
> Key: TS-4564
> URL: https://issues.apache.org/jira/browse/TS-4564
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: James Peach
> Fix For: Docs
>
>
> Document the {{metrics.config}} format and Lua API.



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

[jira] [Updated] (TS-4561) C++ API only lets you create TS_RECORDDATATYPE_INT metrics

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4561:
--
Fix Version/s: 7.0.0

> C++ API only lets you create TS_RECORDDATATYPE_INT metrics
> --
>
> Key: TS-4561
> URL: https://issues.apache.org/jira/browse/TS-4561
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: Brian Geffon
> Fix For: 7.0.0
>
>
> In {{Stat::init}}, the metric type is hardcoded to {{TS_RECORDDATATYPE_INT}}, 
> which is supposed to be an instantaneous integral type (ie. gauge). The most 
> useful value would be counter, but really the caller should be able to 
> specify the kind of {{Stat}} to create. String metrics are also very useful, 
> though this doesn't appear to be supported by TSAPI.



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

[jira] [Updated] (TS-4544) Plugin can create cores with TSHttpSMCallback in stack

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4544:
--
Fix Version/s: 7.0.0

> Plugin can create cores with TSHttpSMCallback in stack
> --
>
> Key: TS-4544
> URL: https://issues.apache.org/jira/browse/TS-4544
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Plugins
>Reporter: Susan Hinrichs
>Assignee: Alan M. Carroll
>  Labels: 7
> Fix For: 7.0.0
>
>
> With a new plugin, we started seeing cores like the following.  The 
> TSHttpSMCallback is being called on a deleted HttpSM.  Looking at the code, 
> there is no logic to cancel the Callback when the state machine goes down.  
> {code}
> (gdb) bt
> #0  0x003bf5832625 in raise () from /lib64/libc.so.6
> #1  0x003bf5833d8d in abort () from /lib64/libc.so.6
> #2  0x2b832a17765d in ink_die_die_die () at ink_error.cc:43
> #3  0x2b832a177714 in ink_fatal_va(const char *, typedef __va_list_tag 
> __va_list_tag *) (
> fmt=0x2b832a188328 "%s:%d: failed assert `%s`", ap=0x2b8343b88a90) at 
> ink_error.cc:65
> #4  0x2b832a1777d9 in ink_fatal (message_format=0x2b832a188328 "%s:%d: 
> failed assert `%s`")
> at ink_error.cc:73
> #5  0x2b832a174ee6 in _ink_assert (expression=0x7db71e "magic == 
> HTTP_SM_MAGIC_ALIVE", 
> file=0x7db114 "HttpSM.cc", line=1385) at ink_assert.cc:37
> #6  0x005ee921 in HttpSM::state_api_callback (this=0x2b870ac2fb90, 
> event=60001, data=0x0)
> at HttpSM.cc:1385
> #7  0x005408dd in TSHttpSMCallback::event_handler 
> (this=0x2b8380065ab0) at InkAPI.cc:5618
> #8  0x00515330 in Continuation::handleEvent (this=0x2b8380065ab0, 
> event=1, data=0x2b8598013180)
> at ../iocore/eventsystem/I_Continuation.h:150
> #9  0x007a587e in EThread::process_event (this=0x2b83377ca010, 
> e=0x2b8598013180, calling_code=1)
> at UnixEThread.cc:145
> #10 0x007a5c1d in EThread::execute_regular (this=0x2b83377ca010) at 
> UnixEThread.cc:212
> #11 0x007a5ff4 in EThread::execute (this=0x2b83377ca010) at 
> UnixEThread.cc:304
> #12 0x007a4bad in spawn_thread_internal (a=0x2a99f80) at Thread.cc:85
> #13 0x2b832a3d3aa1 in start_thread () from /lib64/libpthread.so.0
> #14 0x003bf58e893d in clone () from /lib64/libc.so.6
> {code}



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

Build failed in Jenkins: centos_7-master » clang,centos_7,debug #1785

[jenkins]

See 


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

[jira] [Commented] (TS-4271) metrics fail to clear

[Hong Ye (JIRA)]

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

Hong Ye commented on TS-4271:
-

Does 6.1.1 have the fix? 

> metrics fail to clear
> -
>
> Key: TS-4271
> URL: https://issues.apache.org/jira/browse/TS-4271
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API, Metrics
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{traffic_ctl metrics clear}} fails to clear metrics.



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

[jira] [Commented] (TS-4271) metrics fail to clear

[Hong Ye (JIRA)]

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

Hong Ye commented on TS-4271:
-

Phil and Leif:

We just finished testing the "latest stable" release. It will be great if we 
can have the fix or we will have to downgrade to the running product version 
ATS/4.0.1, which is many years old.

Thanks

Hong

> metrics fail to clear
> -
>
> Key: TS-4271
> URL: https://issues.apache.org/jira/browse/TS-4271
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API, Metrics
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{traffic_ctl metrics clear}} fails to clear metrics.



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

[jira] [Comment Edited] (TS-4271) metrics fail to clear

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-4271 at 6/20/16 6:17 PM:


[~psudaemon] Does this need to get back ported to 5.3.x ? Marking it for back 
port for now, please remove if not desirable.


was (Author: zwoop):
[~psudaemon] Does this need to get back ported to 5.3.x ?

> metrics fail to clear
> -
>
> Key: TS-4271
> URL: https://issues.apache.org/jira/browse/TS-4271
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API, Metrics
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{traffic_ctl metrics clear}} fails to clear metrics.



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

[jira] [Updated] (TS-4271) metrics fail to clear

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4271:
--
Backport to Version: 5.3.3

> metrics fail to clear
> -
>
> Key: TS-4271
> URL: https://issues.apache.org/jira/browse/TS-4271
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API, Metrics
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{traffic_ctl metrics clear}} fails to clear metrics.



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

[jira] [Commented] (TS-4271) metrics fail to clear

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4271:
---

[~psudaemon] Does this need to get back ported to 5.3.x ?

> metrics fail to clear
> -
>
> Key: TS-4271
> URL: https://issues.apache.org/jira/browse/TS-4271
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API, Metrics
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{traffic_ctl metrics clear}} fails to clear metrics.



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

[jira] [Resolved] (TS-4567) ATS5.3 does not reset stats?

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-4567.
---
Resolution: Duplicate

> ATS5.3 does not reset stats?
> 
>
> Key: TS-4567
> URL: https://issues.apache.org/jira/browse/TS-4567
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Hong Ye
>
> Hi guys,
> Stats won't reset on my ATS5.3 box. Does anyone have any idea what could be 
> wrong or missed?
> It worked fine in ATS4.
> -- Current count:
> [root@denv-urlrw03 ~]# /usr/bin/curl -s localhost/_stats | grep 
> completed_requests
> "proxy.process.http.completed_requests": "7017174",
> -- Try to reset:
> [root@denv-urlrw03 ~]# /usr/bin/traffic_line -c
> -- Not working?
> [root@denv-urlrw03 ~]# /usr/bin/curl -s localhost/_stats | grep 
> completed_requests
> "proxy.process.http.completed_requests": "7017205”,
> -- Try to reset more:
> [root@denv-urlrw03 ~]# /usr/bin/traffic_line -c
> [root@denv-urlrw03 ~]# /usr/bin/traffic_line -c
> [root@denv-urlrw03 ~]# /usr/bin/curl -s localhost/_stats | grep 
> completed_requests
> "proxy.process.http.completed_requests": "7017437",
> -- No luck :-(



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

[jira] [Commented] (TS-4271) metrics fail to clear

[Hong Ye (JIRA)]

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

Hong Ye commented on TS-4271:
-

Is there a work around in 5.3? 

> metrics fail to clear
> -
>
> Key: TS-4271
> URL: https://issues.apache.org/jira/browse/TS-4271
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API, Metrics
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{traffic_ctl metrics clear}} fails to clear metrics.



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

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

[jenkins]

See 

[jira] [Created] (TS-4567) ATS5.3 does not reset stats?

[Hong Ye (JIRA)]

Hong Ye created TS-4567:
---

 Summary: ATS5.3 does not reset stats?
 Key: TS-4567
 URL: https://issues.apache.org/jira/browse/TS-4567
 Project: Traffic Server
  Issue Type: Bug
Reporter: Hong Ye


Hi guys,

Stats won't reset on my ATS5.3 box. Does anyone have any idea what could be 
wrong or missed?
It worked fine in ATS4.

-- Current count:
[root@denv-urlrw03 ~]# /usr/bin/curl -s localhost/_stats | grep 
completed_requests
"proxy.process.http.completed_requests": "7017174",

-- Try to reset:
[root@denv-urlrw03 ~]# /usr/bin/traffic_line -c

-- Not working?

[root@denv-urlrw03 ~]# /usr/bin/curl -s localhost/_stats | grep 
completed_requests
"proxy.process.http.completed_requests": "7017205”,

-- Try to reset more:

[root@denv-urlrw03 ~]# /usr/bin/traffic_line -c
[root@denv-urlrw03 ~]# /usr/bin/traffic_line -c
[root@denv-urlrw03 ~]# /usr/bin/curl -s localhost/_stats | grep 
completed_requests
"proxy.process.http.completed_requests": "7017437",

-- No luck :-(




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

[jira] [Commented] (TS-4566) Disable all clang-analyzer checks for LuaJIT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4566:


Github user atsci commented on the issue:

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



> Disable all clang-analyzer checks for LuaJIT
> 
>
> Key: TS-4566
> URL: https://issues.apache.org/jira/browse/TS-4566
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Lua
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> For now, we need to turn off the clang-analyzer checks in the LuaJIT tree. 
> This is "new" since we now (as of 7.0.0) require Lua.



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

[jira] [Commented] (TS-4566) Disable all clang-analyzer checks for LuaJIT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4566:


Github user atsci commented on the issue:

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



> Disable all clang-analyzer checks for LuaJIT
> 
>
> Key: TS-4566
> URL: https://issues.apache.org/jira/browse/TS-4566
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Lua
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> For now, we need to turn off the clang-analyzer checks in the LuaJIT tree. 
> This is "new" since we now (as of 7.0.0) require Lua.



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

[jira] [Commented] (TS-4566) Disable all clang-analyzer checks for LuaJIT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4566:


Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/723
  
 


> Disable all clang-analyzer checks for LuaJIT
> 
>
> Key: TS-4566
> URL: https://issues.apache.org/jira/browse/TS-4566
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Lua
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> For now, we need to turn off the clang-analyzer checks in the LuaJIT tree. 
> This is "new" since we now (as of 7.0.0) require Lua.



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

[jira] [Commented] (TS-4470) ASAN stack-buffer-overflow when slow log is enabled

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4470:


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

https://github.com/apache/trafficserver/pull/721#discussion_r67730748
  
--- Diff: proxy/http/HttpSM.cc ---
@@ -6890,7 +6890,8 @@ HttpSM::update_stats()
 int offset = 0;
 int skip = 0;
 
-t_state.hdr_info.client_request.url_print(url_string, sizeof 
url_string, , );
+t_state.hdr_info.client_request.url_print(url_string, 
sizeof(url_string), , );
+url_string[sizeof(url_string) - 1] = 0; // NULL terminate the string
--- End diff --

Shouldn't this be `url_string[offset] = 0;`?


> ASAN stack-buffer-overflow when slow log is enabled
> ---
>
> Key: TS-4470
> URL: https://issues.apache.org/jira/browse/TS-4470
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>
> =
> ==13159==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x2b5ec8877660 at pc 0x004fcdf1 bp 0x2b5ec8875c60 sp 0x2b5ec8875410
> READ of size 260 at 0x2b5ec8877660 thread T21 ([ET_NET 20])
> #0 0x4fcdf0 in printf_common(void*, char const*, __va_list_tag*) [clone 
> .isra.6] (/usr/local/bin/traffic_server+0x4fcdf0)
> #1 0x4fd744 in vfprintf (/usr/local/bin/traffic_server+0x4fd744)
> #2 0x2b5ec1a668ee in vprintline<1024> 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:61
> #3 0x2b5ec1a668ee in Diags::print_va(char const*, DiagsLevel, SrcLoc 
> const*, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:340
> #4 0x2b5ec1a6765f in Diags::error_va(DiagsLevel, char const*, char 
> const*, int, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:572
> #5 0x72a724 in Diags::error(DiagsLevel, char const*, char const*, int, 
> char const*, ...) const /home/bcall/dev/trafficserver/lib/ts/Diags.h:242
> #6 0x7455d6 in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6972
> #7 0x77b07f in HttpSM::kill_this() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6786
> #8 0x77d6f7 in HttpSM::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:2660
> #9 0x832d3a in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #10 0x832d3a in HttpTunnel::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpTunnel.cc:1637
> #11 0xcfdbb5 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #12 0xcfdbb5 in write_signal_and_update 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:181
> #13 0xcfdbb5 in write_signal_done 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:223
> #14 0xcfdbb5 in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:563
> #15 0xcbc4ca in NetHandler::mainNetEvent(int, Event*) 
> /home/bcall/dev/trafficserver/iocore/net/UnixNet.cc:529
> #16 0xda8ce3 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #17 0xda8ce3 in EThread::process_event(Event*, int) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #18 0xdabc8a in EThread::execute() 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #19 0xda7a58 in spawn_thread_internal 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:86
> #20 0x2b5ec2264aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #21 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> Address 0x2b5ec8877660 is located in stack of thread T21 ([ET_NET 20]) at 
> offset 736 in frame
> #0 0x7443ef in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6827
>   This frame has 6 object(s):
> [32, 36) 'offset'
> [96, 100) 'skip'
> [160, 164) 'length'
> [224, 270) 'client_ip'
> [320, 448) 'unique_id_string'
> [480, 736) 'url_string' <== Memory access at offset 736 overflows this 
> variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism or swapcontext
>   (longjmp and C++ exceptions *are* supported)
> Thread T21 ([ET_NET 20]) created by T0 ([ET_NET 0]) here:
> #0 0x4d50b4 in pthread_create (/usr/local/bin/traffic_server+0x4d50b4)
> #1 0xda85aa in ink_thread_create 
> 

[jira] [Commented] (TS-4566) Disable all clang-analyzer checks for LuaJIT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4566:


GitHub user zwoop opened a pull request:

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

TS-4566 Disabled clang-analyzer on LuaJIT

This basically adds the clang flag  -analyzer-disable-all-checks to 
lua_cflags when we build with clang. It also fixes / cleans up the actual build 
script, such that it uses these flags properly.

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

$ git pull https://github.com/zwoop/trafficserver TS-4566

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

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


commit 9a3d48485e7652be2a7472fdfa6933ba71a0c139
Author: Leif Hedstrom 
Date:   2016-06-20T17:25:02Z

TS-4566 Disabled clang-analyzer on LuaJIT




> Disable all clang-analyzer checks for LuaJIT
> 
>
> Key: TS-4566
> URL: https://issues.apache.org/jira/browse/TS-4566
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Lua
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> For now, we need to turn off the clang-analyzer checks in the LuaJIT tree. 
> This is "new" since we now (as of 7.0.0) require Lua.



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

Jenkins build is back to normal : ubuntu_12_04-master » gcc,ubuntu_12_04,release #1999

[jenkins]

See 

[jira] [Assigned] (TS-4566) Disable all clang-analyzer checks for LuaJIT

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reassigned TS-4566:
-

Assignee: Leif Hedstrom

> Disable all clang-analyzer checks for LuaJIT
> 
>
> Key: TS-4566
> URL: https://issues.apache.org/jira/browse/TS-4566
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Lua
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> For now, we need to turn off the clang-analyzer checks in the LuaJIT tree. 
> This is "new" since we now (as of 7.0.0) require Lua.



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

[jira] [Updated] (TS-4566) Disable all clang-analyzer checks for LuaJIT

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4566:
--
Fix Version/s: 7.0.0

> Disable all clang-analyzer checks for LuaJIT
> 
>
> Key: TS-4566
> URL: https://issues.apache.org/jira/browse/TS-4566
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Lua
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> For now, we need to turn off the clang-analyzer checks in the LuaJIT tree. 
> This is "new" since we now (as of 7.0.0) require Lua.



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

[jira] [Created] (TS-4566) Disable all clang-analyzer checks for LuaJIT

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4566:
-

 Summary: Disable all clang-analyzer checks for LuaJIT
 Key: TS-4566
 URL: https://issues.apache.org/jira/browse/TS-4566
 Project: Traffic Server
  Issue Type: Bug
  Components: Build, Lua
Reporter: Leif Hedstrom


For now, we need to turn off the clang-analyzer checks in the LuaJIT tree. This 
is "new" since we now (as of 7.0.0) require Lua.



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

[jira] [Commented] (TS-3371) Should create a global session ticket disable

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3371:
---

Well, you still have to lookup on the 16-byte identifier to deal with 
"versioning", right ? But regardless, we should do something, cause what we 
have now doesn't work unless you put either IPs or a '*' into multicert.config, 
i.e. SNI based lookups never work.

> Should create a global session ticket disable
> -
>
> Key: TS-3371
> URL: https://issues.apache.org/jira/browse/TS-3371
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> The current implementation requires the user to set the ssl_ticket_enabled=0 
> for every entry in ssl_multiserver.config to turn off the ssl ticket session 
> support.
> It would be better to have a global switch.  It seems highly unlikely that 
> someone will want to deploy ssl tickets for some destinations but not others.
> Would also be good to have a switch to disable ATS from offering session 
> tickets when communicating with origin servers.



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

[jira] [Commented] (TS-3371) Should create a global session ticket disable

[James Peach (JIRA)]

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

James Peach commented on TS-3371:
-

One obvious approach is to do what this code originally did and stash the 
session ticket data on the {{SSL_CTX}}. Then there's no lookup to be done.

> Should create a global session ticket disable
> -
>
> Key: TS-3371
> URL: https://issues.apache.org/jira/browse/TS-3371
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> The current implementation requires the user to set the ssl_ticket_enabled=0 
> for every entry in ssl_multiserver.config to turn off the ssl ticket session 
> support.
> It would be better to have a global switch.  It seems highly unlikely that 
> someone will want to deploy ssl tickets for some destinations but not others.
> Would also be good to have a switch to disable ATS from offering session 
> tickets when communicating with origin servers.



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

Build failed in Jenkins: clang-analyzer #2426

[jenkins]

See 

Changes:

[Bryan Call] TS-4470: ASAN stack-buffer-overflow when slow log is enabled

--
[...truncated 3059 lines...]
reading sources... [ 52%] developer-guide/api/functions/TSMimeHdrFieldDestroy.en
reading sources... [ 52%] developer-guide/api/functions/TSMimeHdrFieldFind.en
reading sources... [ 53%] developer-guide/api/functions/TSMimeHdrFieldGet.en
reading sources... [ 53%] 
developer-guide/api/functions/TSMimeHdrFieldLengthGet.en
reading sources... [ 53%] developer-guide/api/functions/TSMimeHdrFieldNameGet.en
reading sources... [ 53%] developer-guide/api/functions/TSMimeHdrFieldNameSet.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldNext.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldNextDup.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldRemove.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueIntSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesClear.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsClear.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrLengthGet.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrParse.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeHdrPrint.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserClear.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserDestroy.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexCreate.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexDestroy.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLock.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLockTry.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexUnlock.en
reading sources... [ 60%] developer-guide/api/functions/TSNetAccept.en
reading sources... [ 60%] 
developer-guide/api/functions/TSNetAcceptNamedProtocol.en
reading sources... [ 60%] developer-guide/api/functions/TSNetConnect.en
reading sources... [ 60%] developer-guide/api/functions/TSPluginInit.en
reading sources... [ 60%] developer-guide/api/functions/TSRemap.en
reading sources... [ 61%] developer-guide/api/functions/TSSslContextFindBy.en
reading sources... [ 61%] 
developer-guide/api/functions/TSSslServerContextCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSTextLogObjectCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadCreate.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadDestroy.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadInit.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadSelf.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTrafficServerVersionGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 63%] 
developer-guide/api/functions/TSTransformOutputVConnGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTypes.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlCreate.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlDestroy.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostSet.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnAbort.en
reading sources... [ 65%] 
developer-guide/api/functions/TSVConnCacheObjectSizeGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnClose.en
reading sources... [ 66%] 

[jira] [Commented] (TS-3371) Should create a global session ticket disable

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3371:
---

I think we have to take  a step back here, and decide how we want these session 
ticket configs to be handles. It's quite a mess now, with the current 
implementation using the IP instead of the 16-byte identifier string. One 
option is to just have a global (records.config) ticket secret, and then having 
this as a global records.config setting also seems like it'd be required.

> Should create a global session ticket disable
> -
>
> Key: TS-3371
> URL: https://issues.apache.org/jira/browse/TS-3371
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> The current implementation requires the user to set the ssl_ticket_enabled=0 
> for every entry in ssl_multiserver.config to turn off the ssl ticket session 
> support.
> It would be better to have a global switch.  It seems highly unlikely that 
> someone will want to deploy ssl tickets for some destinations but not others.
> Would also be good to have a switch to disable ATS from offering session 
> tickets when communicating with origin servers.



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

Build failed in Jenkins: ubuntu_12_04-master » gcc,ubuntu_12_04,release #1998

[jenkins]

See 


--
[...truncated 17824 lines...]
0|0|96.36.6.0|96.36.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4399754033265211263|0|0|1|0
0|0|177.220.13.0|177.220.13.0|per_ip| |F|0|0|1970/01/01 
00:00:00|16875767461899985215|0|0|1|0
0|0|51.88.12.0|51.88.12.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4061969290583226943|0|0|1|0
0|0|14.60.0.0|14.60.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|239415512081474687|0|0|1|0
0|0|102.92.6.0|102.92.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|1137332129227578751|0|0|1|0
0|0|60.13.3.0|60.13.3.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14197390378702809023|0|0|1|0
0|0|203.51.8.0|203.51.8.0|per_ip| |F|0|0|1970/01/01 
00:00:00|13615035985041572415|0|0|1|0
0|0|55.111.15.0|55.111.15.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8432989278542744703|0|0|1|0
0|0|150.46.8.0|150.46.8.0|per_ip| |F|0|0|1970/01/01 
00:00:00|13328697346056062847|0|0|1|0
0|0|21.63.0.0|21.63.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|6952614330233815423|0|0|1|0
0|0|244.107.1.0|244.107.1.0|per_ip| |F|0|0|1970/01/01 
00:00:00|12483119336099556159|0|0|1|0
0|0|17.27.9.0|17.27.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8404669866067743999|0|0|1|0
0|0|228.205.2.0|228.205.2.0|per_ip| |F|0|0|1970/01/01 
00:00:00|2895386713077538495|0|0|1|0
0|0|70.174.5.0|70.174.5.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4529860252146780415|0|0|1|0
0|0|225.210.0.0|225.210.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|11678389739593155327|0|0|1|0
0|0|214.17.4.0|214.17.4.0|per_ip| |F|0|0|1970/01/01 
00:00:00|2883867808774114623|0|0|1|0
0|0|83.100.11.0|83.100.11.0|per_ip| |F|0|0|1970/01/01 
00:00:00|2537790405278217983|0|0|1|0
0|0|173.104.15.0|173.104.15.0|per_ip| |F|0|0|1970/01/01 
00:00:00|911394549535940799|0|0|1|0
0|0|80.78.2.0|80.78.2.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14462494887552707071|0|0|1|0
0|0|17.111.2.0|17.111.2.0|per_ip| |F|0|0|1970/01/01 
00:00:00|7267807459263132863|0|0|1|0
0|0|3.40.11.0|3.40.11.0|per_ip| |F|0|0|1970/01/01 
00:00:00|11579072041960787903|0|0|1|0
0|0|128.101.6.0|128.101.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|7709350586869578111|0|0|1|0
0|0|182.198.13.0|182.198.13.0|per_ip| |F|0|0|1970/01/01 
00:00:00|13551071601454609279|0|0|1|0
0|0|31.169.9.0|31.169.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|10107774636954373631|0|0|1|0
0|0|79.109.1.0|79.109.1.0|per_ip| |F|0|0|1970/01/01 
00:00:00|2563204556911855615|0|0|1|0
0|0|166.147.15.0|166.147.15.0|per_ip| |F|0|0|1970/01/01 
00:00:00|16690438423652680191|0|0|1|0
0|0|125.174.12.0|125.174.12.0|per_ip| |F|0|0|1970/01/01 
00:00:00|15615066061444725759|0|0|1|0
0|0|141.164.10.0|141.164.10.0|per_ip| |F|0|0|1970/01/01 
00:00:00|11615299697242551807|0|0|1|0
0|0|69.248.5.0|69.248.5.0|per_ip| |F|0|0|1970/01/01 
00:00:00|6084256814888038399|0|0|1|0
0|0|116.85.3.0|116.85.3.0|per_ip| |F|0|0|1970/01/01 
00:00:00|7242195152836692351|0|0|1|0
0|0|143.218.0.0|143.218.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|6521020107008611135|0|0|1|0
0|0|80.50.15.0|80.50.15.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4147214773346524415|0|0|1|0
0|0|57.94.10.0|57.94.10.0|per_ip| |F|0|0|1970/01/01 
00:00:00|5026071791723911167|0|0|1|0
0|0|29.85.2.0|29.85.2.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14621794615183880575|0|0|1|0
0|0|194.121.12.0|194.121.12.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14117829214976018943|0|0|1|0
0|0|213.51.8.0|213.51.8.0|per_ip| |F|0|0|1970/01/01 
00:00:00|5260504740229391231|0|0|1|0
0|0|230.18.4.0|230.18.4.0|per_ip| |F|0|0|1970/01/01 
00:00:00|10768572095690624319|0|0|1|0
0|0|164.219.5.0|164.219.5.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3105496754250598207|0|0|1|0
0|0|52.184.6.0|52.184.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|1021934490480831|0|0|1|0
0|0|240.45.0.0|240.45.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|17270606309438257599|0|0|1|0
0|0|215.142.5.0|215.142.5.0|per_ip| |F|0|0|1970/01/01 
00:00:00|2638784259838792511|0|0|1|0
0|0|164.65.4.0|164.65.4.0|per_ip| |F|0|0|1970/01/01 
00:00:00|12219986955307756607|0|0|1|0
0|0|46.140.3.0|46.140.3.0|per_ip| |F|0|0|1970/01/01 
00:00:00|18065683639601501439|0|0|1|0
0|0|117.181.7.0|117.181.7.0|per_ip| |F|0|0|1970/01/01 
00:00:00|24547227623807|0|0|1|0
0|0|228.128.0.0|228.128.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4063706092132838015|0|0|1|0
0|0|116.215.11.0|116.215.11.0|per_ip| |F|0|0|1970/01/01 
00:00:00|9266402555104158591|0|0|1|0
0|0|22.185.4.0|22.185.4.0|per_ip| |F|0|0|1970/01/01 
00:00:00|13022231484020723007|0|0|1|0
0|0|147.225.15.0|147.225.15.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4887674450441148287|0|0|1|0
0|0|5.124.14.0|5.124.14.0|per_ip| |F|0|0|1970/01/01 
00:00:00|627245539450020031|0|0|1|0
0|0|177.153.14.0|177.153.14.0|per_ip| |F|0|0|1970/01/01 
00:00:00|5668871752088226687|0|0|1|0
0|0|246.106.0.0|246.106.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|11899907850820445439|0|0|1|0
0|0|109.13.6.0|109.13.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14117134646447333119|0|0|1|0
0|0|215.99.5.0|215.99.5.0|per_ip| |F|0|0|1970/01/01 

Jenkins build is back to normal : debian_7-master » gcc,debian_7,debug #2010

[jenkins]

See 

[jira] [Comment Edited] (TS-2403) Segfault when HostDB full

[John Rushford (JIRA)]

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

John Rushford edited comment on TS-2403 at 6/20/16 3:57 PM:


Got a segfault  on two of our caches today that look very similar to the above 
stack traces.  our caches are running ATS 5.3.2.  Here is the BT:

{noformat}
#0  ats_ip_addr_cmp (lhs=0x7fff5a0733d8, rhs=0x8) at ../../lib/ts/ink_inet.h:795
#1  ats_ip_addr_eq (lhs=0x7fff5a0733d8, rhs=0x8) at ../../lib/ts/ink_inet.h:850
#2  0x006887e9 in restore_info (this=, 
event=, e=) at HostDB.cc:1349
#3  HostDBContinuation::dnsEvent (this=, event=, e=) at HostDB.cc:1575
#4  0x006a3db4 in handleEvent (this=0x2b0cd8044200) at 
../../iocore/eventsystem/I_Continuation.h:145
#5  DNSEntry::postEvent (this=0x2b0cd8044200) at DNS.cc:1267
#6  0x006a5695 in dns_result (h=0x45c42e0, e=0x2b0cd8044200, 
ent=0x5ef6000, retry=) at DNS.cc:1219
#7  0x006a6e80 in dns_process (this=0x45c42e0) at DNS.cc:1585
#8  DNSHandler::recv_dns (this=0x45c42e0) at DNS.cc:785
#9  0x006a7f62 in DNSHandler::mainEvent (this=0x45c42e0, event=, e=) at DNS.cc:797
#10 0x00759f65 in handleEvent (this=0x2b0cbfc1b010, e=0x2b0d6c025040, 
calling_code=5) at I_Continuation.h:145
#11 EThread::process_event (this=0x2b0cbfc1b010, e=0x2b0d6c025040, 
calling_code=5) at UnixEThread.cc:128
#12 0x0075a8a9 in EThread::execute (this=0x2b0cbfc1b010) at 
UnixEThread.cc:252
#13 0x004deb84 in main (argv=) at Main.cc:1849
{noformat}

Config settings:

{noformat}
CONFIG proxy.config.hostdb.size INT 12
CONFIG proxy.config.hostdb.storage_size INT 33554432
CONFIG proxy.config.hostdb.ttl_mode INT 0
CONFIG proxy.config.hostdb.timeout INT 1440
CONFIG proxy.config.hostdb.strict_round_robin INT 0
{noformat}


was (Author: jrushford):
Got a segfault  on two of our caches today that look very similar to the above 
stack traces.  our caches are running ATS 5.3.2.  Here is the BT:

{noformat}
#0  ats_ip_addr_cmp (lhs=0x7fff5a0733d8, rhs=0x8) at ../../lib/ts/ink_inet.h:795
#1  ats_ip_addr_eq (lhs=0x7fff5a0733d8, rhs=0x8) at ../../lib/ts/ink_inet.h:850
#2  0x006887e9 in restore_info (this=, 
event=, e=) at HostDB.cc:1349
#3  HostDBContinuation::dnsEvent (this=, event=, e=) at HostDB.cc:1575
#4  0x006a3db4 in handleEvent (this=0x2b0cd8044200) at 
../../iocore/eventsystem/I_Continuation.h:145
#5  DNSEntry::postEvent (this=0x2b0cd8044200) at DNS.cc:1267
#6  0x006a5695 in dns_result (h=0x45c42e0, e=0x2b0cd8044200, 
ent=0x5ef6000, retry=) at DNS.cc:1219
#7  0x006a6e80 in dns_process (this=0x45c42e0) at DNS.cc:1585
#8  DNSHandler::recv_dns (this=0x45c42e0) at DNS.cc:785
#9  0x006a7f62 in DNSHandler::mainEvent (this=0x45c42e0, event=, e=) at DNS.cc:797
#10 0x00759f65 in handleEvent (this=0x2b0cbfc1b010, e=0x2b0d6c025040, 
calling_code=5) at I_Continuation.h:145
#11 EThread::process_event (this=0x2b0cbfc1b010, e=0x2b0d6c025040, 
calling_code=5) at UnixEThread.cc:128
#12 0x0075a8a9 in EThread::execute (this=0x2b0cbfc1b010) at 
UnixEThread.cc:252
#13 0x004deb84 in main (argv=) at Main.cc:1849
{noformat}

> Segfault when HostDB full
> -
>
> Key: TS-2403
> URL: https://issues.apache.org/jira/browse/TS-2403
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 4.0.1
>Reporter: David Carlin
>Assignee: Thomas Jackson
>  Labels: Crash
> Fix For: sometime
>
>
> diags.log leading up to crash:
> {noformat}
> [Nov 25 10:50:23.346] Server {0x2b06c4302700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.379] Server {0x2b06c4100700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.449] Server {0x2b06c4a09700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.462] Server {0x2b06c4403700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.494] Server {0x2b06bed1f540} WARNING: out of room in hostdb 
> for reverse DNS data
> [Nov 25 10:54:46.919] {0x2baa2d65b540} STATUS: opened 
> /home/y/logs/trafficserver/diags.log
> [Nov 25 10:54:46.927] {0x2baa2d65b540} NOTE: updated diags config
> [Nov 25 10:54:46.961] Server {0x2baa2d65b540} NOTE: cache clustering disabled
> [Nov 25 10:54:46.995] Server {0x2baa2d65b540} NOTE: ip_allow.config updated, 
> reloading
> [Nov 25 10:54:47.059] Server {0x2baa2d65b540} NOTE: cache clustering disabled
> [Nov 25 10:54:47.072] Server {0x2baa2d65b540} NOTE: logging initialized[15], 
> logging_mode = 3
> [Nov 25 10:54:47.103] Server {0x2baa2d65b540} NOTE: loading plugin 
> '/home/y/libexec64/trafficserver/quick_filter.so'
> [Nov 25 10:54:47.326] Server {0x2baa2d65b540} NOTE: loading plugin 
> 

[jira] [Comment Edited] (TS-2403) Segfault when HostDB full

[John Rushford (JIRA)]

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

John Rushford edited comment on TS-2403 at 6/20/16 3:55 PM:


Got a segfault  on two of our caches today that look very similar to the above 
stack traces.  our caches are running ATS 5.3.2.  Here is the BT:

{noformat}
#0  ats_ip_addr_cmp (lhs=0x7fff5a0733d8, rhs=0x8) at ../../lib/ts/ink_inet.h:795
#1  ats_ip_addr_eq (lhs=0x7fff5a0733d8, rhs=0x8) at ../../lib/ts/ink_inet.h:850
#2  0x006887e9 in restore_info (this=, 
event=, e=) at HostDB.cc:1349
#3  HostDBContinuation::dnsEvent (this=, event=, e=) at HostDB.cc:1575
#4  0x006a3db4 in handleEvent (this=0x2b0cd8044200) at 
../../iocore/eventsystem/I_Continuation.h:145
#5  DNSEntry::postEvent (this=0x2b0cd8044200) at DNS.cc:1267
#6  0x006a5695 in dns_result (h=0x45c42e0, e=0x2b0cd8044200, 
ent=0x5ef6000, retry=) at DNS.cc:1219
#7  0x006a6e80 in dns_process (this=0x45c42e0) at DNS.cc:1585
#8  DNSHandler::recv_dns (this=0x45c42e0) at DNS.cc:785
#9  0x006a7f62 in DNSHandler::mainEvent (this=0x45c42e0, event=, e=) at DNS.cc:797
#10 0x00759f65 in handleEvent (this=0x2b0cbfc1b010, e=0x2b0d6c025040, 
calling_code=5) at I_Continuation.h:145
#11 EThread::process_event (this=0x2b0cbfc1b010, e=0x2b0d6c025040, 
calling_code=5) at UnixEThread.cc:128
#12 0x0075a8a9 in EThread::execute (this=0x2b0cbfc1b010) at 
UnixEThread.cc:252
#13 0x004deb84 in main (argv=) at Main.cc:1849
{noformat}


was (Author: jrushford):
Got a segfault  on two of our caches today that look very similar to the above 
stack traces.  our caches are running ATS 5.3.2.  Here is the BT:

#0  ats_ip_addr_cmp (lhs=0x7fff5a0733d8, rhs=0x8) at ../../lib/ts/ink_inet.h:795
#1  ats_ip_addr_eq (lhs=0x7fff5a0733d8, rhs=0x8) at ../../lib/ts/ink_inet.h:850
#2  0x006887e9 in restore_info (this=, 
event=, e=) at HostDB.cc:1349
#3  HostDBContinuation::dnsEvent (this=, event=, e=) at HostDB.cc:1575
#4  0x006a3db4 in handleEvent (this=0x2b0cd8044200) at 
../../iocore/eventsystem/I_Continuation.h:145
#5  DNSEntry::postEvent (this=0x2b0cd8044200) at DNS.cc:1267
#6  0x006a5695 in dns_result (h=0x45c42e0, e=0x2b0cd8044200, 
ent=0x5ef6000, retry=) at DNS.cc:1219
#7  0x006a6e80 in dns_process (this=0x45c42e0) at DNS.cc:1585
#8  DNSHandler::recv_dns (this=0x45c42e0) at DNS.cc:785
#9  0x006a7f62 in DNSHandler::mainEvent (this=0x45c42e0, event=, e=) at DNS.cc:797
#10 0x00759f65 in handleEvent (this=0x2b0cbfc1b010, e=0x2b0d6c025040, 
calling_code=5) at I_Continuation.h:145
#11 EThread::process_event (this=0x2b0cbfc1b010, e=0x2b0d6c025040, 
calling_code=5) at UnixEThread.cc:128
#12 0x0075a8a9 in EThread::execute (this=0x2b0cbfc1b010) at 
UnixEThread.cc:252
#13 0x004deb84 in main (argv=) at Main.cc:1849

> Segfault when HostDB full
> -
>
> Key: TS-2403
> URL: https://issues.apache.org/jira/browse/TS-2403
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 4.0.1
>Reporter: David Carlin
>Assignee: Thomas Jackson
>  Labels: Crash
> Fix For: sometime
>
>
> diags.log leading up to crash:
> {noformat}
> [Nov 25 10:50:23.346] Server {0x2b06c4302700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.379] Server {0x2b06c4100700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.449] Server {0x2b06c4a09700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.462] Server {0x2b06c4403700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.494] Server {0x2b06bed1f540} WARNING: out of room in hostdb 
> for reverse DNS data
> [Nov 25 10:54:46.919] {0x2baa2d65b540} STATUS: opened 
> /home/y/logs/trafficserver/diags.log
> [Nov 25 10:54:46.927] {0x2baa2d65b540} NOTE: updated diags config
> [Nov 25 10:54:46.961] Server {0x2baa2d65b540} NOTE: cache clustering disabled
> [Nov 25 10:54:46.995] Server {0x2baa2d65b540} NOTE: ip_allow.config updated, 
> reloading
> [Nov 25 10:54:47.059] Server {0x2baa2d65b540} NOTE: cache clustering disabled
> [Nov 25 10:54:47.072] Server {0x2baa2d65b540} NOTE: logging initialized[15], 
> logging_mode = 3
> [Nov 25 10:54:47.103] Server {0x2baa2d65b540} NOTE: loading plugin 
> '/home/y/libexec64/trafficserver/quick_filter.so'
> [Nov 25 10:54:47.326] Server {0x2baa2d65b540} NOTE: loading plugin 
> '/home/y/libexec64/trafficserver/header_filter.so'
> [Nov 25 10:54:49.395] Server {0x2baa2d65b540} NOTE: traffic server running
> {noformat}
> From traffic.out:
> {noformat}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> 

[jira] [Resolved] (TS-4470) ASAN stack-buffer-overflow when slow log is enabled

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4470.

Resolution: Fixed

> ASAN stack-buffer-overflow when slow log is enabled
> ---
>
> Key: TS-4470
> URL: https://issues.apache.org/jira/browse/TS-4470
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>
> =
> ==13159==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x2b5ec8877660 at pc 0x004fcdf1 bp 0x2b5ec8875c60 sp 0x2b5ec8875410
> READ of size 260 at 0x2b5ec8877660 thread T21 ([ET_NET 20])
> #0 0x4fcdf0 in printf_common(void*, char const*, __va_list_tag*) [clone 
> .isra.6] (/usr/local/bin/traffic_server+0x4fcdf0)
> #1 0x4fd744 in vfprintf (/usr/local/bin/traffic_server+0x4fd744)
> #2 0x2b5ec1a668ee in vprintline<1024> 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:61
> #3 0x2b5ec1a668ee in Diags::print_va(char const*, DiagsLevel, SrcLoc 
> const*, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:340
> #4 0x2b5ec1a6765f in Diags::error_va(DiagsLevel, char const*, char 
> const*, int, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:572
> #5 0x72a724 in Diags::error(DiagsLevel, char const*, char const*, int, 
> char const*, ...) const /home/bcall/dev/trafficserver/lib/ts/Diags.h:242
> #6 0x7455d6 in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6972
> #7 0x77b07f in HttpSM::kill_this() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6786
> #8 0x77d6f7 in HttpSM::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:2660
> #9 0x832d3a in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #10 0x832d3a in HttpTunnel::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpTunnel.cc:1637
> #11 0xcfdbb5 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #12 0xcfdbb5 in write_signal_and_update 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:181
> #13 0xcfdbb5 in write_signal_done 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:223
> #14 0xcfdbb5 in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:563
> #15 0xcbc4ca in NetHandler::mainNetEvent(int, Event*) 
> /home/bcall/dev/trafficserver/iocore/net/UnixNet.cc:529
> #16 0xda8ce3 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #17 0xda8ce3 in EThread::process_event(Event*, int) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #18 0xdabc8a in EThread::execute() 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #19 0xda7a58 in spawn_thread_internal 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:86
> #20 0x2b5ec2264aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #21 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> Address 0x2b5ec8877660 is located in stack of thread T21 ([ET_NET 20]) at 
> offset 736 in frame
> #0 0x7443ef in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6827
>   This frame has 6 object(s):
> [32, 36) 'offset'
> [96, 100) 'skip'
> [160, 164) 'length'
> [224, 270) 'client_ip'
> [320, 448) 'unique_id_string'
> [480, 736) 'url_string' <== Memory access at offset 736 overflows this 
> variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism or swapcontext
>   (longjmp and C++ exceptions *are* supported)
> Thread T21 ([ET_NET 20]) created by T0 ([ET_NET 0]) here:
> #0 0x4d50b4 in pthread_create (/usr/local/bin/traffic_server+0x4d50b4)
> #1 0xda85aa in ink_thread_create 
> /home/bcall/dev/trafficserver/lib/ts/ink_thread.h:147
> #2 0xda85aa in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xdafff2 in EventProcessor::start(int, unsigned long) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ab7ed in main /home/bcall/dev/trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 printf_common(void*, 
> char const*, __va_list_tag*) [clone .isra.6]
> Shadow bytes around 

[jira] [Updated] (TS-4470) ASAN stack-buffer-overflow when slow log is enabled

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4470:
---
Backport to Version: 6.2.0  (was: 6.2.1)

> ASAN stack-buffer-overflow when slow log is enabled
> ---
>
> Key: TS-4470
> URL: https://issues.apache.org/jira/browse/TS-4470
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>
> =
> ==13159==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x2b5ec8877660 at pc 0x004fcdf1 bp 0x2b5ec8875c60 sp 0x2b5ec8875410
> READ of size 260 at 0x2b5ec8877660 thread T21 ([ET_NET 20])
> #0 0x4fcdf0 in printf_common(void*, char const*, __va_list_tag*) [clone 
> .isra.6] (/usr/local/bin/traffic_server+0x4fcdf0)
> #1 0x4fd744 in vfprintf (/usr/local/bin/traffic_server+0x4fd744)
> #2 0x2b5ec1a668ee in vprintline<1024> 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:61
> #3 0x2b5ec1a668ee in Diags::print_va(char const*, DiagsLevel, SrcLoc 
> const*, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:340
> #4 0x2b5ec1a6765f in Diags::error_va(DiagsLevel, char const*, char 
> const*, int, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:572
> #5 0x72a724 in Diags::error(DiagsLevel, char const*, char const*, int, 
> char const*, ...) const /home/bcall/dev/trafficserver/lib/ts/Diags.h:242
> #6 0x7455d6 in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6972
> #7 0x77b07f in HttpSM::kill_this() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6786
> #8 0x77d6f7 in HttpSM::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:2660
> #9 0x832d3a in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #10 0x832d3a in HttpTunnel::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpTunnel.cc:1637
> #11 0xcfdbb5 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #12 0xcfdbb5 in write_signal_and_update 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:181
> #13 0xcfdbb5 in write_signal_done 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:223
> #14 0xcfdbb5 in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:563
> #15 0xcbc4ca in NetHandler::mainNetEvent(int, Event*) 
> /home/bcall/dev/trafficserver/iocore/net/UnixNet.cc:529
> #16 0xda8ce3 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #17 0xda8ce3 in EThread::process_event(Event*, int) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #18 0xdabc8a in EThread::execute() 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #19 0xda7a58 in spawn_thread_internal 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:86
> #20 0x2b5ec2264aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #21 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> Address 0x2b5ec8877660 is located in stack of thread T21 ([ET_NET 20]) at 
> offset 736 in frame
> #0 0x7443ef in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6827
>   This frame has 6 object(s):
> [32, 36) 'offset'
> [96, 100) 'skip'
> [160, 164) 'length'
> [224, 270) 'client_ip'
> [320, 448) 'unique_id_string'
> [480, 736) 'url_string' <== Memory access at offset 736 overflows this 
> variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism or swapcontext
>   (longjmp and C++ exceptions *are* supported)
> Thread T21 ([ET_NET 20]) created by T0 ([ET_NET 0]) here:
> #0 0x4d50b4 in pthread_create (/usr/local/bin/traffic_server+0x4d50b4)
> #1 0xda85aa in ink_thread_create 
> /home/bcall/dev/trafficserver/lib/ts/ink_thread.h:147
> #2 0xda85aa in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xdafff2 in EventProcessor::start(int, unsigned long) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ab7ed in main /home/bcall/dev/trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 printf_common(void*, 
> char const*, __va_list_tag*) [clone .isra.6]
> 

[jira] [Commented] (TS-4470) ASAN stack-buffer-overflow when slow log is enabled

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4470:


Github user bryancall closed the pull request at:

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


> ASAN stack-buffer-overflow when slow log is enabled
> ---
>
> Key: TS-4470
> URL: https://issues.apache.org/jira/browse/TS-4470
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>
> =
> ==13159==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x2b5ec8877660 at pc 0x004fcdf1 bp 0x2b5ec8875c60 sp 0x2b5ec8875410
> READ of size 260 at 0x2b5ec8877660 thread T21 ([ET_NET 20])
> #0 0x4fcdf0 in printf_common(void*, char const*, __va_list_tag*) [clone 
> .isra.6] (/usr/local/bin/traffic_server+0x4fcdf0)
> #1 0x4fd744 in vfprintf (/usr/local/bin/traffic_server+0x4fd744)
> #2 0x2b5ec1a668ee in vprintline<1024> 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:61
> #3 0x2b5ec1a668ee in Diags::print_va(char const*, DiagsLevel, SrcLoc 
> const*, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:340
> #4 0x2b5ec1a6765f in Diags::error_va(DiagsLevel, char const*, char 
> const*, int, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:572
> #5 0x72a724 in Diags::error(DiagsLevel, char const*, char const*, int, 
> char const*, ...) const /home/bcall/dev/trafficserver/lib/ts/Diags.h:242
> #6 0x7455d6 in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6972
> #7 0x77b07f in HttpSM::kill_this() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6786
> #8 0x77d6f7 in HttpSM::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:2660
> #9 0x832d3a in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #10 0x832d3a in HttpTunnel::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpTunnel.cc:1637
> #11 0xcfdbb5 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #12 0xcfdbb5 in write_signal_and_update 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:181
> #13 0xcfdbb5 in write_signal_done 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:223
> #14 0xcfdbb5 in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:563
> #15 0xcbc4ca in NetHandler::mainNetEvent(int, Event*) 
> /home/bcall/dev/trafficserver/iocore/net/UnixNet.cc:529
> #16 0xda8ce3 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #17 0xda8ce3 in EThread::process_event(Event*, int) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #18 0xdabc8a in EThread::execute() 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #19 0xda7a58 in spawn_thread_internal 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:86
> #20 0x2b5ec2264aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #21 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> Address 0x2b5ec8877660 is located in stack of thread T21 ([ET_NET 20]) at 
> offset 736 in frame
> #0 0x7443ef in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6827
>   This frame has 6 object(s):
> [32, 36) 'offset'
> [96, 100) 'skip'
> [160, 164) 'length'
> [224, 270) 'client_ip'
> [320, 448) 'unique_id_string'
> [480, 736) 'url_string' <== Memory access at offset 736 overflows this 
> variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism or swapcontext
>   (longjmp and C++ exceptions *are* supported)
> Thread T21 ([ET_NET 20]) created by T0 ([ET_NET 0]) here:
> #0 0x4d50b4 in pthread_create (/usr/local/bin/traffic_server+0x4d50b4)
> #1 0xda85aa in ink_thread_create 
> /home/bcall/dev/trafficserver/lib/ts/ink_thread.h:147
> #2 0xda85aa in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xdafff2 in EventProcessor::start(int, unsigned long) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ab7ed in main /home/bcall/dev/trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> SUMMARY: 

[jira] [Commented] (TS-4470) ASAN stack-buffer-overflow when slow log is enabled

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on TS-4470:
-

Commit ceec590f76bca2b38f3e3f0cad47a6ee077223e0 in trafficserver's branch 
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ceec590 ]

Merge pull request #721 from bryancall/TS-4470

TS-4470: ASAN stack-buffer-overflow when slow log is enabled

> ASAN stack-buffer-overflow when slow log is enabled
> ---
>
> Key: TS-4470
> URL: https://issues.apache.org/jira/browse/TS-4470
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>
> =
> ==13159==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x2b5ec8877660 at pc 0x004fcdf1 bp 0x2b5ec8875c60 sp 0x2b5ec8875410
> READ of size 260 at 0x2b5ec8877660 thread T21 ([ET_NET 20])
> #0 0x4fcdf0 in printf_common(void*, char const*, __va_list_tag*) [clone 
> .isra.6] (/usr/local/bin/traffic_server+0x4fcdf0)
> #1 0x4fd744 in vfprintf (/usr/local/bin/traffic_server+0x4fd744)
> #2 0x2b5ec1a668ee in vprintline<1024> 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:61
> #3 0x2b5ec1a668ee in Diags::print_va(char const*, DiagsLevel, SrcLoc 
> const*, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:340
> #4 0x2b5ec1a6765f in Diags::error_va(DiagsLevel, char const*, char 
> const*, int, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:572
> #5 0x72a724 in Diags::error(DiagsLevel, char const*, char const*, int, 
> char const*, ...) const /home/bcall/dev/trafficserver/lib/ts/Diags.h:242
> #6 0x7455d6 in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6972
> #7 0x77b07f in HttpSM::kill_this() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6786
> #8 0x77d6f7 in HttpSM::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:2660
> #9 0x832d3a in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #10 0x832d3a in HttpTunnel::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpTunnel.cc:1637
> #11 0xcfdbb5 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #12 0xcfdbb5 in write_signal_and_update 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:181
> #13 0xcfdbb5 in write_signal_done 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:223
> #14 0xcfdbb5 in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:563
> #15 0xcbc4ca in NetHandler::mainNetEvent(int, Event*) 
> /home/bcall/dev/trafficserver/iocore/net/UnixNet.cc:529
> #16 0xda8ce3 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #17 0xda8ce3 in EThread::process_event(Event*, int) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #18 0xdabc8a in EThread::execute() 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #19 0xda7a58 in spawn_thread_internal 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:86
> #20 0x2b5ec2264aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #21 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> Address 0x2b5ec8877660 is located in stack of thread T21 ([ET_NET 20]) at 
> offset 736 in frame
> #0 0x7443ef in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6827
>   This frame has 6 object(s):
> [32, 36) 'offset'
> [96, 100) 'skip'
> [160, 164) 'length'
> [224, 270) 'client_ip'
> [320, 448) 'unique_id_string'
> [480, 736) 'url_string' <== Memory access at offset 736 overflows this 
> variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism or swapcontext
>   (longjmp and C++ exceptions *are* supported)
> Thread T21 ([ET_NET 20]) created by T0 ([ET_NET 0]) here:
> #0 0x4d50b4 in pthread_create (/usr/local/bin/traffic_server+0x4d50b4)
> #1 0xda85aa in ink_thread_create 
> /home/bcall/dev/trafficserver/lib/ts/ink_thread.h:147
> #2 0xda85aa in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xdafff2 in EventProcessor::start(int, unsigned long) 
> 

[jira] [Commented] (TS-4470) ASAN stack-buffer-overflow when slow log is enabled

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on TS-4470:
-

Commit 91542118bf17b9b07941998dcce748eaf39b6958 in trafficserver's branch 
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9154211 ]

TS-4470: ASAN stack-buffer-overflow when slow log is enabled


> ASAN stack-buffer-overflow when slow log is enabled
> ---
>
> Key: TS-4470
> URL: https://issues.apache.org/jira/browse/TS-4470
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>
> =
> ==13159==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x2b5ec8877660 at pc 0x004fcdf1 bp 0x2b5ec8875c60 sp 0x2b5ec8875410
> READ of size 260 at 0x2b5ec8877660 thread T21 ([ET_NET 20])
> #0 0x4fcdf0 in printf_common(void*, char const*, __va_list_tag*) [clone 
> .isra.6] (/usr/local/bin/traffic_server+0x4fcdf0)
> #1 0x4fd744 in vfprintf (/usr/local/bin/traffic_server+0x4fd744)
> #2 0x2b5ec1a668ee in vprintline<1024> 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:61
> #3 0x2b5ec1a668ee in Diags::print_va(char const*, DiagsLevel, SrcLoc 
> const*, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:340
> #4 0x2b5ec1a6765f in Diags::error_va(DiagsLevel, char const*, char 
> const*, int, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:572
> #5 0x72a724 in Diags::error(DiagsLevel, char const*, char const*, int, 
> char const*, ...) const /home/bcall/dev/trafficserver/lib/ts/Diags.h:242
> #6 0x7455d6 in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6972
> #7 0x77b07f in HttpSM::kill_this() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6786
> #8 0x77d6f7 in HttpSM::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:2660
> #9 0x832d3a in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #10 0x832d3a in HttpTunnel::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpTunnel.cc:1637
> #11 0xcfdbb5 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #12 0xcfdbb5 in write_signal_and_update 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:181
> #13 0xcfdbb5 in write_signal_done 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:223
> #14 0xcfdbb5 in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:563
> #15 0xcbc4ca in NetHandler::mainNetEvent(int, Event*) 
> /home/bcall/dev/trafficserver/iocore/net/UnixNet.cc:529
> #16 0xda8ce3 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #17 0xda8ce3 in EThread::process_event(Event*, int) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #18 0xdabc8a in EThread::execute() 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #19 0xda7a58 in spawn_thread_internal 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:86
> #20 0x2b5ec2264aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #21 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> Address 0x2b5ec8877660 is located in stack of thread T21 ([ET_NET 20]) at 
> offset 736 in frame
> #0 0x7443ef in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6827
>   This frame has 6 object(s):
> [32, 36) 'offset'
> [96, 100) 'skip'
> [160, 164) 'length'
> [224, 270) 'client_ip'
> [320, 448) 'unique_id_string'
> [480, 736) 'url_string' <== Memory access at offset 736 overflows this 
> variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism or swapcontext
>   (longjmp and C++ exceptions *are* supported)
> Thread T21 ([ET_NET 20]) created by T0 ([ET_NET 0]) here:
> #0 0x4d50b4 in pthread_create (/usr/local/bin/traffic_server+0x4d50b4)
> #1 0xda85aa in ink_thread_create 
> /home/bcall/dev/trafficserver/lib/ts/ink_thread.h:147
> #2 0xda85aa in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xdafff2 in EventProcessor::start(int, unsigned long) 
> 

[jira] [Commented] (TS-4470) ASAN stack-buffer-overflow when slow log is enabled

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on TS-4470:
-

Commit ceec590f76bca2b38f3e3f0cad47a6ee077223e0 in trafficserver's branch 
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ceec590 ]

Merge pull request #721 from bryancall/TS-4470

TS-4470: ASAN stack-buffer-overflow when slow log is enabled

> ASAN stack-buffer-overflow when slow log is enabled
> ---
>
> Key: TS-4470
> URL: https://issues.apache.org/jira/browse/TS-4470
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>
> =
> ==13159==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x2b5ec8877660 at pc 0x004fcdf1 bp 0x2b5ec8875c60 sp 0x2b5ec8875410
> READ of size 260 at 0x2b5ec8877660 thread T21 ([ET_NET 20])
> #0 0x4fcdf0 in printf_common(void*, char const*, __va_list_tag*) [clone 
> .isra.6] (/usr/local/bin/traffic_server+0x4fcdf0)
> #1 0x4fd744 in vfprintf (/usr/local/bin/traffic_server+0x4fd744)
> #2 0x2b5ec1a668ee in vprintline<1024> 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:61
> #3 0x2b5ec1a668ee in Diags::print_va(char const*, DiagsLevel, SrcLoc 
> const*, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:340
> #4 0x2b5ec1a6765f in Diags::error_va(DiagsLevel, char const*, char 
> const*, int, char const*, __va_list_tag*) const 
> /home/bcall/dev/trafficserver/lib/ts/Diags.cc:572
> #5 0x72a724 in Diags::error(DiagsLevel, char const*, char const*, int, 
> char const*, ...) const /home/bcall/dev/trafficserver/lib/ts/Diags.h:242
> #6 0x7455d6 in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6972
> #7 0x77b07f in HttpSM::kill_this() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6786
> #8 0x77d6f7 in HttpSM::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:2660
> #9 0x832d3a in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #10 0x832d3a in HttpTunnel::main_handler(int, void*) 
> /home/bcall/dev/trafficserver/proxy/http/HttpTunnel.cc:1637
> #11 0xcfdbb5 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #12 0xcfdbb5 in write_signal_and_update 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:181
> #13 0xcfdbb5 in write_signal_done 
> /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:223
> #14 0xcfdbb5 in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /home/bcall/dev/trafficserver/iocore/net/UnixNetVConnection.cc:563
> #15 0xcbc4ca in NetHandler::mainNetEvent(int, Event*) 
> /home/bcall/dev/trafficserver/iocore/net/UnixNet.cc:529
> #16 0xda8ce3 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #17 0xda8ce3 in EThread::process_event(Event*, int) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #18 0xdabc8a in EThread::execute() 
> /home/bcall/dev/trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #19 0xda7a58 in spawn_thread_internal 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:86
> #20 0x2b5ec2264aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #21 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> Address 0x2b5ec8877660 is located in stack of thread T21 ([ET_NET 20]) at 
> offset 736 in frame
> #0 0x7443ef in HttpSM::update_stats() 
> /home/bcall/dev/trafficserver/proxy/http/HttpSM.cc:6827
>   This frame has 6 object(s):
> [32, 36) 'offset'
> [96, 100) 'skip'
> [160, 164) 'length'
> [224, 270) 'client_ip'
> [320, 448) 'unique_id_string'
> [480, 736) 'url_string' <== Memory access at offset 736 overflows this 
> variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism or swapcontext
>   (longjmp and C++ exceptions *are* supported)
> Thread T21 ([ET_NET 20]) created by T0 ([ET_NET 0]) here:
> #0 0x4d50b4 in pthread_create (/usr/local/bin/traffic_server+0x4d50b4)
> #1 0xda85aa in ink_thread_create 
> /home/bcall/dev/trafficserver/lib/ts/ink_thread.h:147
> #2 0xda85aa in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /home/bcall/dev/trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xdafff2 in EventProcessor::start(int, unsigned long) 
> 

[jira] [Commented] (TS-2403) Segfault when HostDB full

[John Rushford (JIRA)]

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

John Rushford commented on TS-2403:
---

Got a segfault  on two of our caches today that look very similar to the above 
stack traces.  our caches are running ATS 5.3.2.  Here is the BT:

#0  ats_ip_addr_cmp (lhs=0x7fff5a0733d8, rhs=0x8) at ../../lib/ts/ink_inet.h:795
#1  ats_ip_addr_eq (lhs=0x7fff5a0733d8, rhs=0x8) at ../../lib/ts/ink_inet.h:850
#2  0x006887e9 in restore_info (this=, 
event=, e=) at HostDB.cc:1349
#3  HostDBContinuation::dnsEvent (this=, event=, e=) at HostDB.cc:1575
#4  0x006a3db4 in handleEvent (this=0x2b0cd8044200) at 
../../iocore/eventsystem/I_Continuation.h:145
#5  DNSEntry::postEvent (this=0x2b0cd8044200) at DNS.cc:1267
#6  0x006a5695 in dns_result (h=0x45c42e0, e=0x2b0cd8044200, 
ent=0x5ef6000, retry=) at DNS.cc:1219
#7  0x006a6e80 in dns_process (this=0x45c42e0) at DNS.cc:1585
#8  DNSHandler::recv_dns (this=0x45c42e0) at DNS.cc:785
#9  0x006a7f62 in DNSHandler::mainEvent (this=0x45c42e0, event=, e=) at DNS.cc:797
#10 0x00759f65 in handleEvent (this=0x2b0cbfc1b010, e=0x2b0d6c025040, 
calling_code=5) at I_Continuation.h:145
#11 EThread::process_event (this=0x2b0cbfc1b010, e=0x2b0d6c025040, 
calling_code=5) at UnixEThread.cc:128
#12 0x0075a8a9 in EThread::execute (this=0x2b0cbfc1b010) at 
UnixEThread.cc:252
#13 0x004deb84 in main (argv=) at Main.cc:1849

> Segfault when HostDB full
> -
>
> Key: TS-2403
> URL: https://issues.apache.org/jira/browse/TS-2403
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 4.0.1
>Reporter: David Carlin
>Assignee: Thomas Jackson
>  Labels: Crash
> Fix For: sometime
>
>
> diags.log leading up to crash:
> {noformat}
> [Nov 25 10:50:23.346] Server {0x2b06c4302700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.379] Server {0x2b06c4100700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.449] Server {0x2b06c4a09700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.462] Server {0x2b06c4403700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.494] Server {0x2b06bed1f540} WARNING: out of room in hostdb 
> for reverse DNS data
> [Nov 25 10:54:46.919] {0x2baa2d65b540} STATUS: opened 
> /home/y/logs/trafficserver/diags.log
> [Nov 25 10:54:46.927] {0x2baa2d65b540} NOTE: updated diags config
> [Nov 25 10:54:46.961] Server {0x2baa2d65b540} NOTE: cache clustering disabled
> [Nov 25 10:54:46.995] Server {0x2baa2d65b540} NOTE: ip_allow.config updated, 
> reloading
> [Nov 25 10:54:47.059] Server {0x2baa2d65b540} NOTE: cache clustering disabled
> [Nov 25 10:54:47.072] Server {0x2baa2d65b540} NOTE: logging initialized[15], 
> logging_mode = 3
> [Nov 25 10:54:47.103] Server {0x2baa2d65b540} NOTE: loading plugin 
> '/home/y/libexec64/trafficserver/quick_filter.so'
> [Nov 25 10:54:47.326] Server {0x2baa2d65b540} NOTE: loading plugin 
> '/home/y/libexec64/trafficserver/header_filter.so'
> [Nov 25 10:54:49.395] Server {0x2baa2d65b540} NOTE: traffic server running
> {noformat}
> From traffic.out:
> {noformat}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x3d07c0f500)[0x2b06be27a500]
> /home/y/bin/traffic_server(_Z14ats_ip_addr_eqPK8sockaddrS1_+0x3)[0x5e0323]
> /home/y/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x2389)[0x5df3b9]
> /home/y/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5f9cd4]
> /home/y/bin/traffic_server[0x5fbd17]
> /home/y/bin/traffic_server(_ZN10DNSHandler8recv_dnsEiP5Event+0x8d0)[0x5fd5c0]
> /home/y/bin/traffic_server(_ZN10DNSHandler9mainEventEiP5Event+0x12)[0x5fe642]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a321f]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4a3)[0x6a3c03]
> /home/y/bin/traffic_server(main+0xb14)[0x4c5314]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3d0781ecdd]
> /home/y/bin/traffic_server[0x485a19]
> {noformat}
> Backtrace:
> {noformat}
> #0  ats_ip_addr_cmp (lhs=0x7fffdf15e778, rhs=0x8) at 
> ../../lib/ts/ink_inet.h:669
> #1  ats_ip_addr_eq (lhs=0x7fffdf15e778, rhs=0x8) at 
> ../../lib/ts/ink_inet.h:721
> #2  0x005df3b9 in restore_info (this=, 
> event=, e=) at HostDB.cc:1375
> #3  HostDBContinuation::dnsEvent (this=, event= optimized out>, e=) at HostDB.cc:1604
> #4  0x005f9cd4 in handleEvent (this=0x2b06f40a2120) at 
> ../../iocore/eventsystem/I_Continuation.h:146
> #5  DNSEntry::postEvent (this=0x2b06f40a2120) at DNS.cc:1278
> #6  0x005fbd17 in dns_result (h=0x1778380, e=0x2b06f40a2120, 
> ent=0x1913820, retry=) at DNS.cc:1230
> 

[jira] [Updated] (TS-3371) Should create a global session ticket disable

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-3371:
---
Assignee: Syeda Persia Aziz  (was: Susan Hinrichs)

> Should create a global session ticket disable
> -
>
> Key: TS-3371
> URL: https://issues.apache.org/jira/browse/TS-3371
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> The current implementation requires the user to set the ssl_ticket_enabled=0 
> for every entry in ssl_multiserver.config to turn off the ssl ticket session 
> support.
> It would be better to have a global switch.  It seems highly unlikely that 
> someone will want to deploy ssl tickets for some destinations but not others.
> Would also be good to have a switch to disable ATS from offering session 
> tickets when communicating with origin servers.



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

[jira] [Commented] (TS-4480) Wildcards in certificates should only match one level

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4480:


Yes, doing full and subdomain explicit hash searches sound like a good idea.  
That would simplify the logic considerably.  We currently don't support partial 
wildcards, e.g. b*z.example.net.  If we really need to do that, it would 
probably be better to do that as a separate case (off the faster path).

> Wildcards in certificates should only match one level
> -
>
> Key: TS-4480
> URL: https://issues.apache.org/jira/browse/TS-4480
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Michael Sokolnicki
> Fix For: 7.0.0
>
> Attachments: current_patch.diff
>
>
> According to RFC 6125 section 6.4.3:
> {quote}
> If the wildcard character is the only character of the left-most label in the 
> presented identifier, the client SHOULD NOT compare against anything but the 
> left-most label of the reference identifier (e.g., *.example.com would match 
> foo.example.com but not bar.foo.example.com or example.com).
> {quote}
> In the current implementation, certificates are searched for in a trie, and 
> the longest match is returned, but there is no check if that match complies 
> with the above rule. This causes invalid certs to be returned and SLL errors 
> in the browser (in Firefox, we get SSL_ERROR_BAD_CERT_DOMAIN).



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

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



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

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



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

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



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

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



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

Build failed in Jenkins: clang-analyzer #2425

[jenkins]

See 

--
[...truncated 3054 lines...]
reading sources... [ 52%] developer-guide/api/functions/TSMimeHdrFieldDestroy.en
reading sources... [ 52%] developer-guide/api/functions/TSMimeHdrFieldFind.en
reading sources... [ 53%] developer-guide/api/functions/TSMimeHdrFieldGet.en
reading sources... [ 53%] 
developer-guide/api/functions/TSMimeHdrFieldLengthGet.en
reading sources... [ 53%] developer-guide/api/functions/TSMimeHdrFieldNameGet.en
reading sources... [ 53%] developer-guide/api/functions/TSMimeHdrFieldNameSet.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldNext.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldNextDup.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldRemove.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueIntSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesClear.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsClear.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrLengthGet.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrParse.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeHdrPrint.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserClear.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserDestroy.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexCreate.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexDestroy.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLock.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLockTry.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexUnlock.en
reading sources... [ 60%] developer-guide/api/functions/TSNetAccept.en
reading sources... [ 60%] 
developer-guide/api/functions/TSNetAcceptNamedProtocol.en
reading sources... [ 60%] developer-guide/api/functions/TSNetConnect.en
reading sources... [ 60%] developer-guide/api/functions/TSPluginInit.en
reading sources... [ 60%] developer-guide/api/functions/TSRemap.en
reading sources... [ 61%] developer-guide/api/functions/TSSslContextFindBy.en
reading sources... [ 61%] 
developer-guide/api/functions/TSSslServerContextCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSTextLogObjectCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadCreate.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadDestroy.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadInit.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadSelf.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTrafficServerVersionGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 63%] 
developer-guide/api/functions/TSTransformOutputVConnGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTypes.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlCreate.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlDestroy.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostSet.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnAbort.en
reading sources... [ 65%] 
developer-guide/api/functions/TSVConnCacheObjectSizeGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnClose.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnClosedGet.en
reading sources... [ 66%]