[jira] [Commented] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[James Peach (JIRA)]

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

James Peach commented on TS-4716:
-

I'll look into this next week (hopefully). Marking as back port for 6.2.1 on 
the assumption that this is a regression.

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



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

[jira] [Updated] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[James Peach (JIRA)]

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

James Peach updated TS-4716:

Backport to Version: 6.2.1

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



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

[jira] [Assigned] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[James Peach (JIRA)]

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

James Peach reassigned TS-4716:
---

Assignee: James Peach

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



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

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

[jenkins]

See 


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

Build failed in Jenkins: clang-analyzer #2527

[jenkins]

See 

Changes:

[shinrich] TS-4671: Allow for multicert line with action specified but not

[Thomas Jackson] Fix typo in the docs

[James Peach] Spell "pseudo" correctly.

--
[...truncated 4952 lines...]
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... [ 54%] 
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... [ 55%] 
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... [ 56%] 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... [ 57%] 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... [ 58%] 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... [ 59%] 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... [ 60%] 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... [ 61%] 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... [ 62%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 62%] 
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... [ 63%] 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... [ 64%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSUuidCreate.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%] developer-guide/api/functions/TSVConnFdCreate.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnIsSsl.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnRead.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnReadVIOGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReenable.en
reading 

Build failed in Jenkins: osx-master » clang,osx,debug #1059

[jenkins]

See 


Changes:

[Thomas Jackson] Fix typo in the docs

[James Peach] Spell "pseudo" correctly.

--
[...truncated 14339 lines...]
If-Modified-Since: Wednesday, 26-Feb-97 06:58:17 GMT; length=842
Referer: http://people.netscape.com/jwz/index.html
Proxy-Connection: Keep-Alive
User-Agent:  Mozilla/3.01 (X11; I; Linux 2.0.28 i586)
Pragma: no-cache
Host: people.netscape.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
X-1: blah
X-2: blah
X-3: blah
X-4: blah
X-5: blah
X-6: blah
X-7: blah
X-8: blah
X-9: blah
Pragma: no-cache
X-X-1: blah
X-X-2: blah
X-X-3: blah
X-X-4: blah
X-X-5: blah
X-X-6: blah
X-X-7: blah
X-X-8: blah
X-X-9: blah



[GET http://people.netscape.com/jwz/hacks-1.gif HTTP/1.0
If-Modified-Since: Wednesday, 26-Feb-97 06:58:17 GMT; length=842
Referer: http://people.netscape.com/jwz/index.html
Proxy-Connection: Keep-Alive
User-Agent:  Mozilla/3.01 (X11; I; Linux 2.0.28 i586)
Pragma: no-cache
Host: people.netscape.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
X-1: blah
X-2: blah
X-3: blah
X-4: blah
X-5: blah
X-6: blah
X-7: blah
X-8: blah
X-9: blah
Pragma: no-cache
X-X-1: blah
X-X-2: blah
X-X-3: blah
X-X-4: blah
X-X-5: blah
X-X-6: blah
X-X-7: blah
X-X-8: blah
X-X-9: blah

]


 real response (length=163)

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



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

]

{HTTP/1.0 200 OK\15\12MIME-Version: 1.0\15\12Server: WebSTAR/2.1 
ID/30013\15\12Content-Type: text/html\15\12Content-Length: 
939\15\12Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT\15\12\15\12}   <<< 
MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

 real request (length=123)

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



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

]


 real response (length=163)

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



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

]

{HTTP/1.0 200 OK\15\12MIME-Version: 1.0\15\12Server: WebSTAR/2.1 
ID/30013\15\12Content-Type: text/html\15\12Content-Length: 
939\15\12Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT\15\12\15\12}   <<< 
MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

 real request (length=56)

GET http://www.news.com/ HTTP/1.1
Connection: close



[GET http://www.news.com/ HTTP/1.1
Connection: close

]


 real response (length=163)

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



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

]

{HTTP/1.0 200 OK\15\12MIME-Version: 1.0\15\12Server: WebSTAR/2.1 
ID/30013\15\12Content-Type: text/html\15\12Content-Length: 
939\15\12Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT\15\12\15\12}   <<< 
MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSTextLog) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(cache) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSTextLog) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(cache) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSTextLog) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Release) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Release) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Set) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Set) still in progress

[GitHub] trafficserver pull request #840: TS-4711: Remove proxy.config.log.custom_log...

[jpeach]

Github user jpeach closed the pull request at:

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


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

[jira] [Resolved] (TS-4711) Remove proxy.config.log.custom_logs_enabled

[James Peach (JIRA)]

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

James Peach resolved TS-4711.
-
Resolution: Fixed

> Remove proxy.config.log.custom_logs_enabled
> ---
>
> Key: TS-4711
> URL: https://issues.apache.org/jira/browse/TS-4711
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Is there a use case for running without custom logs. Does it even work? Let's 
> agree to remove the ability to disable custom logging.



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

[jira] [Work logged] (TS-4711) Remove proxy.config.log.custom_logs_enabled

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Remove proxy.config.log.custom_logs_enabled
> ---
>
> Key: TS-4711
> URL: https://issues.apache.org/jira/browse/TS-4711
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Is there a use case for running without custom logs. Does it even work? Let's 
> agree to remove the ability to disable custom logging.



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

[jira] [Work logged] (TS-4720) ATS not properly closing origin connections in client abort situations

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ATS not properly closing origin connections in client abort situations
> --
>
> Key: TS-4720
> URL: https://issues.apache.org/jira/browse/TS-4720
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We've noticed that there are some scenarios that ATS doesn't close the origin 
> connection when the client aborts. To reproduce I set up an http server which 
> would return a text/stream sending a message every 10s. In this case, if I do 
> a GET request to the endpoint and then immediately kill the client, the 
> connection to the origin doesn't close until the transaction active timer 
> kicks in. 
> After digging into this, it seems that this is actually due to a bug in the 
> HttpSM-- specifically in how it checks whether a request has a body. The 
> default value for content-length is `-1`, but some checks are `== 0` -- which 
> means that if the request had no content-length header it is treated as a 
> request with a content-length. 
> The particular place that was problematic was the section that enables the 
> vio reader to watch for client aborts-- which specifically isn't enabled for 
> POST/chunked requests as it is enabled later down the call chain (since it 
> needs to handle the buffers itself).



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

[GitHub] trafficserver issue #841: TS-4720 correctly check if requests have a body

[atsci]

Github user atsci commented on the issue:

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



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

[jira] [Work logged] (TS-4720) ATS not properly closing origin connections in client abort situations

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ATS not properly closing origin connections in client abort situations
> --
>
> Key: TS-4720
> URL: https://issues.apache.org/jira/browse/TS-4720
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We've noticed that there are some scenarios that ATS doesn't close the origin 
> connection when the client aborts. To reproduce I set up an http server which 
> would return a text/stream sending a message every 10s. In this case, if I do 
> a GET request to the endpoint and then immediately kill the client, the 
> connection to the origin doesn't close until the transaction active timer 
> kicks in. 
> After digging into this, it seems that this is actually due to a bug in the 
> HttpSM-- specifically in how it checks whether a request has a body. The 
> default value for content-length is `-1`, but some checks are `== 0` -- which 
> means that if the request had no content-length header it is treated as a 
> request with a content-length. 
> The particular place that was problematic was the section that enables the 
> vio reader to watch for client aborts-- which specifically isn't enabled for 
> POST/chunked requests as it is enabled later down the call chain (since it 
> needs to handle the buffers itself).



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

[GitHub] trafficserver issue #841: TS-4720 correctly check if requests have a body

[atsci]

Github user atsci commented on the issue:

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



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

[jira] [Issue Comment Deleted] (TS-4720) ATS not properly closing origin connections in client abort situations

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4720:
---
Comment: was deleted

(was: https://github.com/apache/trafficserver/pull/841)

> ATS not properly closing origin connections in client abort situations
> --
>
> Key: TS-4720
> URL: https://issues.apache.org/jira/browse/TS-4720
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We've noticed that there are some scenarios that ATS doesn't close the origin 
> connection when the client aborts. To reproduce I set up an http server which 
> would return a text/stream sending a message every 10s. In this case, if I do 
> a GET request to the endpoint and then immediately kill the client, the 
> connection to the origin doesn't close until the transaction active timer 
> kicks in. 
> After digging into this, it seems that this is actually due to a bug in the 
> HttpSM-- specifically in how it checks whether a request has a body. The 
> default value for content-length is `-1`, but some checks are `== 0` -- which 
> means that if the request had no content-length header it is treated as a 
> request with a content-length. 
> The particular place that was problematic was the section that enables the 
> vio reader to watch for client aborts-- which specifically isn't enabled for 
> POST/chunked requests as it is enabled later down the call chain (since it 
> needs to handle the buffers itself).



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

[jira] [Commented] (TS-4720) ATS not properly closing origin connections in client abort situations

[Thomas Jackson (JIRA)]

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

Thomas Jackson commented on TS-4720:


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

> ATS not properly closing origin connections in client abort situations
> --
>
> Key: TS-4720
> URL: https://issues.apache.org/jira/browse/TS-4720
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We've noticed that there are some scenarios that ATS doesn't close the origin 
> connection when the client aborts. To reproduce I set up an http server which 
> would return a text/stream sending a message every 10s. In this case, if I do 
> a GET request to the endpoint and then immediately kill the client, the 
> connection to the origin doesn't close until the transaction active timer 
> kicks in. 
> After digging into this, it seems that this is actually due to a bug in the 
> HttpSM-- specifically in how it checks whether a request has a body. The 
> default value for content-length is `-1`, but some checks are `== 0` -- which 
> means that if the request had no content-length header it is treated as a 
> request with a content-length. 
> The particular place that was problematic was the section that enables the 
> vio reader to watch for client aborts-- which specifically isn't enabled for 
> POST/chunked requests as it is enabled later down the call chain (since it 
> needs to handle the buffers itself).



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

[jira] [Work logged] (TS-4720) ATS not properly closing origin connections in client abort situations

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 05/Aug/16 00:58
Start Date: 05/Aug/16 00:58
Worklog Time Spent: 10m 
  Work Description: GitHub user jacksontj opened a pull request:

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

TS-4720 correctly check if requests have a body

HttpTransact defaults content length to `-1`, meaning that if the request 
has no content length header it will be `-1`. These checks weren't taking that 
into consideration -- meaning client aborts during requests with no content 
length (GET for example) would leave the origin session open until another 
timeout kicked in.

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

$ git pull https://github.com/jacksontj/trafficserver TS-4720

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

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


commit a075556602d77d79f5a02e2a36053abfa92703f0
Author: Thomas Jackson 
Date:   2016-08-05T00:55:59Z

TS-4720 correctly check if requests have a body

HttpTransact defaults content length to `-1`, meaning that if the request 
has no content length header it will be `-1`. These checks weren't taking that 
into consideration -- meaning client aborts during requests with no content 
length (GET for example) would leave the origin session open until another 
timeout kicked in.




Issue Time Tracking
---

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

> ATS not properly closing origin connections in client abort situations
> --
>
> Key: TS-4720
> URL: https://issues.apache.org/jira/browse/TS-4720
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We've noticed that there are some scenarios that ATS doesn't close the origin 
> connection when the client aborts. To reproduce I set up an http server which 
> would return a text/stream sending a message every 10s. In this case, if I do 
> a GET request to the endpoint and then immediately kill the client, the 
> connection to the origin doesn't close until the transaction active timer 
> kicks in. 
> After digging into this, it seems that this is actually due to a bug in the 
> HttpSM-- specifically in how it checks whether a request has a body. The 
> default value for content-length is `-1`, but some checks are `== 0` -- which 
> means that if the request had no content-length header it is treated as a 
> request with a content-length. 
> The particular place that was problematic was the section that enables the 
> vio reader to watch for client aborts-- which specifically isn't enabled for 
> POST/chunked requests as it is enabled later down the call chain (since it 
> needs to handle the buffers itself).



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

[GitHub] trafficserver pull request #841: TS-4720 correctly check if requests have a ...

[jacksontj]

GitHub user jacksontj opened a pull request:

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

TS-4720 correctly check if requests have a body

HttpTransact defaults content length to `-1`, meaning that if the request 
has no content length header it will be `-1`. These checks weren't taking that 
into consideration -- meaning client aborts during requests with no content 
length (GET for example) would leave the origin session open until another 
timeout kicked in.

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

$ git pull https://github.com/jacksontj/trafficserver TS-4720

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

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


commit a075556602d77d79f5a02e2a36053abfa92703f0
Author: Thomas Jackson 
Date:   2016-08-05T00:55:59Z

TS-4720 correctly check if requests have a body

HttpTransact defaults content length to `-1`, meaning that if the request 
has no content length header it will be `-1`. These checks weren't taking that 
into consideration -- meaning client aborts during requests with no content 
length (GET for example) would leave the origin session open until another 
timeout kicked in.




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

[jira] [Updated] (TS-4720) ATS not properly closing origin connections in client abort situations

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4720:
---
Fix Version/s: 7.0.0

> ATS not properly closing origin connections in client abort situations
> --
>
> Key: TS-4720
> URL: https://issues.apache.org/jira/browse/TS-4720
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> We've noticed that there are some scenarios that ATS doesn't close the origin 
> connection when the client aborts. To reproduce I set up an http server which 
> would return a text/stream sending a message every 10s. In this case, if I do 
> a GET request to the endpoint and then immediately kill the client, the 
> connection to the origin doesn't close until the transaction active timer 
> kicks in. 
> After digging into this, it seems that this is actually due to a bug in the 
> HttpSM-- specifically in how it checks whether a request has a body. The 
> default value for content-length is `-1`, but some checks are `== 0` -- which 
> means that if the request had no content-length header it is treated as a 
> request with a content-length. 
> The particular place that was problematic was the section that enables the 
> vio reader to watch for client aborts-- which specifically isn't enabled for 
> POST/chunked requests as it is enabled later down the call chain (since it 
> needs to handle the buffers itself).



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

[jira] [Created] (TS-4720) ATS not properly closing origin connections in client abort situations

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4720:
--

 Summary: ATS not properly closing origin connections in client 
abort situations
 Key: TS-4720
 URL: https://issues.apache.org/jira/browse/TS-4720
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Thomas Jackson


We've noticed that there are some scenarios that ATS doesn't close the origin 
connection when the client aborts. To reproduce I set up an http server which 
would return a text/stream sending a message every 10s. In this case, if I do a 
GET request to the endpoint and then immediately kill the client, the 
connection to the origin doesn't close until the transaction active timer kicks 
in. 

After digging into this, it seems that this is actually due to a bug in the 
HttpSM-- specifically in how it checks whether a request has a body. The 
default value for content-length is `-1`, but some checks are `== 0` -- which 
means that if the request had no content-length header it is treated as a 
request with a content-length. 

The particular place that was problematic was the section that enables the vio 
reader to watch for client aborts-- which specifically isn't enabled for 
POST/chunked requests as it is enabled later down the call chain (since it 
needs to handle the buffers itself).



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

[jira] [Assigned] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[Phil Sorber (JIRA)]

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

Phil Sorber reassigned TS-4719:
---

Assignee: Phil Sorber

> Should have NUMA affinity for disk threads (AIO threads)
> 
>
> Key: TS-4719
> URL: https://issues.apache.org/jira/browse/TS-4719
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>
> We should properly interleave AIO threads (disk threads) evenly across the 
> NUMA nodes, and have affinity on those nodes. That would allow for better 
> memory distribution across NUMA nodes. We've noticed pretty uneven 
> allocations on some boxes, which I attribute to this problem (but no strong 
> evidence, but it does make sense).
> {code}
> Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.000.000.00
> Stack1.380.642.02
> Private 188993.7559142.80   248136.55
>   --- --- ---
> Total   188995.1359143.44   248138.57
> {code}



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

[jira] [Updated] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4719:
--
Description: 
We should properly interleave AIO threads (disk threads) evenly across the NUMA 
nodes, and have affinity on those nodes. That would allow for better memory 
distribution across NUMA nodes. We've noticed pretty uneven allocations on some 
boxes, which I attribute to this problem (but no strong evidence, but it does 
make sense).

{code}
Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
   Node 0  Node 1   Total
  --- --- ---
Huge 0.000.000.00
Heap 0.000.000.00
Stack1.380.642.02
Private 188993.7559142.80   248136.55
  --- --- ---
Total   188995.1359143.44   248138.57
{code}

  was:
We should properly interleave AIO threads (disk threads) evenly across the NUMA 
nodes, and have affinity on those nodes. That would allow for better memory 
distribution across NUMA nodes. I've noticed pretty uneven allocations on some 
boxes, which I attribute to this problem (but no strong evidence, but it does 
make sense).

{code}
Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
   Node 0  Node 1   Total
  --- --- ---
Huge 0.000.000.00
Heap 0.000.000.00
Stack1.380.642.02
Private 188993.7559142.80   248136.55
  --- --- ---
Total   188995.1359143.44   248138.57
{code}


> Should have NUMA affinity for disk threads (AIO threads)
> 
>
> Key: TS-4719
> URL: https://issues.apache.org/jira/browse/TS-4719
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> We should properly interleave AIO threads (disk threads) evenly across the 
> NUMA nodes, and have affinity on those nodes. That would allow for better 
> memory distribution across NUMA nodes. We've noticed pretty uneven 
> allocations on some boxes, which I attribute to this problem (but no strong 
> evidence, but it does make sense).
> {code}
> Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.000.000.00
> Stack1.380.642.02
> Private 188993.7559142.80   248136.55
>   --- --- ---
> Total   188995.1359143.44   248138.57
> {code}



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

[jira] [Updated] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[Leif Hedstrom (JIRA)]

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

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

> Should have NUMA affinity for disk threads (AIO threads)
> 
>
> Key: TS-4719
> URL: https://issues.apache.org/jira/browse/TS-4719
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> We should properly interleave AIO threads (disk threads) evenly across the 
> NUMA nodes, and have affinity on those nodes. That would allow for better 
> memory distribution across NUMA nodes. I've noticed pretty uneven allocations 
> on some boxes, which I attribute to this problem (but no strong evidence, but 
> it does make sense).
> {code}
> Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.000.000.00
> Stack1.380.642.02
> Private 188993.7559142.80   248136.55
>   --- --- ---
> Total   188995.1359143.44   248138.57
> {code}



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

[jira] [Updated] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4719:
--
Backport to Version: 6.2.1

> Should have NUMA affinity for disk threads (AIO threads)
> 
>
> Key: TS-4719
> URL: https://issues.apache.org/jira/browse/TS-4719
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> We should properly interleave AIO threads (disk threads) evenly across the 
> NUMA nodes, and have affinity on those nodes. That would allow for better 
> memory distribution across NUMA nodes. I've noticed pretty uneven allocations 
> on some boxes, which I attribute to this problem (but no strong evidence, but 
> it does make sense).
> {code}
> Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.000.000.00
> Stack1.380.642.02
> Private 188993.7559142.80   248136.55
>   --- --- ---
> Total   188995.1359143.44   248138.57
> {code}



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

[jira] [Created] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4719:
-

 Summary: Should have NUMA affinity for disk threads (AIO threads)
 Key: TS-4719
 URL: https://issues.apache.org/jira/browse/TS-4719
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cache, Core
Reporter: Leif Hedstrom


We should properly interleave AIO threads (disk threads) evenly across the NUMA 
nodes, and have affinity on those nodes. That would allow for better memory 
distribution across NUMA nodes. I've noticed pretty uneven allocations on some 
boxes, which I attribute to this problem (but no strong evidence, but it does 
make sense).

{code}
Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
   Node 0  Node 1   Total
  --- --- ---
Huge 0.000.000.00
Heap 0.000.000.00
Stack1.380.642.02
Private 188993.7559142.80   248136.55
  --- --- ---
Total   188995.1359143.44   248138.57
{code}



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

[jira] [Created] (TS-4718) Change the default for proxy.config.exec_thread.affinity to "1"

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4718:
-

 Summary: Change the default for proxy.config.exec_thread.affinity 
to "1"
 Key: TS-4718
 URL: https://issues.apache.org/jira/browse/TS-4718
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration
Reporter: Leif Hedstrom


The docs falsely claim that the default is already "1", and I really think "1" 
makes the most sense in general.  We should just change this.



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

[jira] [Updated] (TS-4718) Change the default for proxy.config.exec_thread.affinity to "1"

[Leif Hedstrom (JIRA)]

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

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

> Change the default for proxy.config.exec_thread.affinity to "1"
> ---
>
> Key: TS-4718
> URL: https://issues.apache.org/jira/browse/TS-4718
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> The docs falsely claim that the default is already "1", and I really think 
> "1" makes the most sense in general.  We should just change this.



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

[jira] [Assigned] (TS-4718) Change the default for proxy.config.exec_thread.affinity to "1"

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reassigned TS-4718:
-

Assignee: Leif Hedstrom

> Change the default for proxy.config.exec_thread.affinity to "1"
> ---
>
> Key: TS-4718
> URL: https://issues.apache.org/jira/browse/TS-4718
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> The docs falsely claim that the default is already "1", and I really think 
> "1" makes the most sense in general.  We should just change this.



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

[GitHub] trafficserver issue #840: TS-4711: Remove proxy.config.log.custom_logs_enabl...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/840
  
:+1:


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

[jira] [Work logged] (TS-4711) Remove proxy.config.log.custom_logs_enabled

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Aug/16 20:51
Start Date: 04/Aug/16 20:51
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/840
  
:+1:


Issue Time Tracking
---

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

> Remove proxy.config.log.custom_logs_enabled
> ---
>
> Key: TS-4711
> URL: https://issues.apache.org/jira/browse/TS-4711
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Is there a use case for running without custom logs. Does it even work? Let's 
> agree to remove the ability to disable custom logging.



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

Jenkins build is back to normal : osx-master » clang,osx,debug #1058

[jenkins]

See 

[jira] [Work logged] (TS-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Aug/16 20:04
Start Date: 04/Aug/16 20:04
Worklog Time Spent: 10m 
  Work Description: Github user pbchou commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
@zwoop I implemented the two API calls that you recommended above (along 
with the two corresponding ts_lua API calls). However, I did not see a graceful 
way to get the URL set via the API calls to the ParentConsistentHash.cc hash 
generation function since it is only passing the request_data and not the 
entire HTTP transaction. As a work-around, I wrote the URL into an "@ATS..." 
MIME field to accomplish the data exchange. The plus to this is that you can 
set the MIME field without using the API (and it does not need to be a valid 
URL if set with this method). The hash generation will just hash the contents 
of this MIME field if it is defined (and ignore the other options maxdirs, 
fname, and qstring). I retained the maxdirs and fname enhancements in the 
earlier commit as I have not yet sold my users on this new approach.


Issue Time Tracking
---

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

> Parent Consistent Hash Selection - add fname and maxdirs options.
> -
>
> Key: TS-4707
> URL: https://issues.apache.org/jira/browse/TS-4707
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Peter Chou
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This enhancement adds two options, "fname" and "maxdirs", which can be used 
> to exclude the file-name and some of the directories in the path. The 
> remaining portions of the path are then used as part of the hash computation 
> for selecting among multiple parent caches.
> For our usage, it was desirable from an operational perspective to direct all 
> components of particular sub-tree to a single parent cache (to simplify 
> trouble-shooting, pre-loading, etc.). This can be achieved by excluding the 
> query-string, file-name, and right-most portions of the path from the hash 
> computation.



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

Build failed in Jenkins: osx-master » clang,osx,debug #1057

[jenkins]

See 


Changes:

[shinrich] TS-4507: Fix SSN and TXN hook ordering.

--
[...truncated 2308 lines...]
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   balancer.la 
'
libtool: install: /usr/bin/install -c .libs/balancer.so 

libtool: install: /usr/bin/install -c .libs/balancer.lai 

make[4]: Nothing to be done for `install-data-am'.
Making install in buffer_upload
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   
buffer_upload.la 
'
libtool: install: /usr/bin/install -c .libs/buffer_upload.so 

libtool: install: /usr/bin/install -c .libs/buffer_upload.lai 

make[4]: Nothing to be done for `install-data-am'.
Making install in cache_promote
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   
cache_promote.la 
'
libtool: install: /usr/bin/install -c .libs/cache_promote.so 

libtool: install: /usr/bin/install -c .libs/cache_promote.lai 

make[4]: Nothing to be done for `install-data-am'.
Making install in cache_range_requests
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   
cache_range_requests.la 
'
libtool: install: /usr/bin/install -c .libs/cache_range_requests.so 

libtool: install: /usr/bin/install -c .libs/cache_range_requests.lai 

make[4]: Nothing to be done for `install-data-am'.
Making install in cachekey
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   cachekey.la 
'
libtool: install: /usr/bin/install -c .libs/cachekey.so 

libtool: install: /usr/bin/install -c .libs/cachekey.lai 

make[4]: Nothing to be done for `install-data-am'.
Making install in collapsed_connection
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   
collapsed_connection.la 
'
libtool: install: /usr/bin/install -c .libs/collapsed_connection.so 

Build failed in Jenkins: clang-analyzer #2526

[jenkins]

See 

Changes:

[shinrich] TS-4507: Fix SSN and TXN hook ordering.

--
[...truncated 4952 lines...]
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... [ 54%] 
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... [ 55%] 
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... [ 56%] 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... [ 57%] 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... [ 58%] 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... [ 59%] 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... [ 60%] 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... [ 61%] 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... [ 62%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 62%] 
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... [ 63%] 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... [ 64%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSUuidCreate.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%] developer-guide/api/functions/TSVConnFdCreate.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnIsSsl.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnRead.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnReadVIOGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReenable.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnShutdown.en
reading sources... [ 67%] 

[GitHub] trafficserver pull request #810: TS-4679: Allow multicert line with action b...

[shinrich]

Github user shinrich closed the pull request at:

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


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

[jira] [Work logged] (TS-4679) Allow ssl_multicert line to have no ssl_cert_name specified

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Allow ssl_multicert line to have no ssl_cert_name specified
> ---
>
> Key: TS-4679
> URL: https://issues.apache.org/jira/browse/TS-4679
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> It is reasonable to not specify a ssl_cert_name if the action=tunnel is 
> specified.  As the code currently stands you must enter a dummy ssl_cert_name 
> even in the blind tunnel case because of sanity checks in the ssl_multicert 
> loading code.
> The following should be an allowable entry
> {code}
> dest_ip=10.10.10.10 action=tunnel
> {code}



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

[jira] [Work logged] (TS-4507) It is still possible for SSN_CLOSE hook to be called before TXN_CLOSE hook

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> It is still possible for SSN_CLOSE hook to be called before TXN_CLOSE hook
> --
>
> Key: TS-4507
> URL: https://issues.apache.org/jira/browse/TS-4507
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> One of our plugins will occasionally crash.  It appears there is still a path 
> for HTTP2 that has the SSN_CLOSE hook close before the TXN_CLOSE hook.
> Working through solutions that delay the SSN_CLOSE hook until after all the 
> TXN_CLOSE hooks, but does not lose the SSN_CLOSE. 



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

[GitHub] trafficserver pull request #787: TS-4507: Fix SSN and TXN hook ordering.

[shinrich]

Github user shinrich closed the pull request at:

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


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

[jira] [Created] (TS-4717) Http2 stack explosion

[Susan Hinrichs (JIRA)]

Susan Hinrichs created TS-4717:
--

 Summary: Http2 stack explosion
 Key: TS-4717
 URL: https://issues.apache.org/jira/browse/TS-4717
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP/2
Reporter: Susan Hinrichs


We see this periodically with high traffic loads.  ATS crashes with 7000+ 
frames on the stack.  The bulk of the frames are the following frame sequence.  

{code}
#117 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90, 
event=100, data=0x2b0bad0c7cf0)
at ../iocore/eventsystem/I_Continuation.h:150
#118 0x0064c05d in Http2ClientSession::state_start_frame_read 
(this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
at Http2ClientSession.cc:451
#119 0x0064b0af in Http2ClientSession::main_event_handler 
(this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0) at 
Http2ClientSession.cc:292
#120 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90, 
event=100, data=0x2b0bad0c7cf0)
at ../iocore/eventsystem/I_Continuation.h:150
#121 0x0064c386 in Http2ClientSession::state_complete_frame_read 
(this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
at Http2ClientSession.cc:483
#122 0x0064b0af in Http2ClientSession::main_event_handler 
(this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0) at 
Http2ClientSession.cc:292
#123 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90, 
event=100, data=0x2b0bad0c7cf0)
at ../iocore/eventsystem/I_Continuation.h:150
#124 0x0064c05d in Http2ClientSession::state_start_frame_read 
(this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
at Http2ClientSession.cc:451
{code}

We had cherry picked in the fix for TS-4209 to correctly enforce the concurrent 
stream limit.  But in the latest crash of this type, it looks like we are 
pulling small items from cache, so the stream lives and dies on the stack.  The 
concurrent active connection count never reaches the limit.

I am going to try to change the 
state_state_start_frame_read/state_complete_frame_read logic from recursing 
handlers to a loop.



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

[jira] [Assigned] (TS-4717) Http2 stack explosion

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs reassigned TS-4717:
--

Assignee: Susan Hinrichs

> Http2 stack explosion
> -
>
> Key: TS-4717
> URL: https://issues.apache.org/jira/browse/TS-4717
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> We see this periodically with high traffic loads.  ATS crashes with 7000+ 
> frames on the stack.  The bulk of the frames are the following frame 
> sequence.  
> {code}
> #117 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90, 
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #118 0x0064c05d in Http2ClientSession::state_start_frame_read 
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:451
> #119 0x0064b0af in Http2ClientSession::main_event_handler 
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0) at 
> Http2ClientSession.cc:292
> #120 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90, 
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #121 0x0064c386 in Http2ClientSession::state_complete_frame_read 
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:483
> #122 0x0064b0af in Http2ClientSession::main_event_handler 
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0) at 
> Http2ClientSession.cc:292
> #123 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90, 
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #124 0x0064c05d in Http2ClientSession::state_start_frame_read 
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:451
> {code}
> We had cherry picked in the fix for TS-4209 to correctly enforce the 
> concurrent stream limit.  But in the latest crash of this type, it looks like 
> we are pulling small items from cache, so the stream lives and dies on the 
> stack.  The concurrent active connection count never reaches the limit.
> I am going to try to change the 
> state_state_start_frame_read/state_complete_frame_read logic from recursing 
> handlers to a loop.



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

[jira] [Updated] (TS-3915) Regression fails when compilied with ASAN, heap-use-after-free

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3915:
--
Summary: Regression fails when compilied with ASAN, heap-use-after-free  
(was: Regression fails when compilied with asan, heap-use-after-free)

> Regression fails when compilied with ASAN, heap-use-after-free
> --
>
> Key: TS-3915
> URL: https://issues.apache.org/jira/browse/TS-3915
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: ASAN
> Fix For: 7.0.0
>
>
> Running regression with asan enable on Fedora 22:
> {code}
> CXXFLAGS="-Werror -fno-omit-frame-pointer -fsanitize=address" 
> CFLAGS="-Werror" SPDYLAY_CFLAGS="-I /usr/local/include/" 
> SPDYLAY_LIBS="-L/usr/local/lib -lspdylay"  ./configure --enable-ccache 
> --enable-spdy --disable-freelist
> REGRESSION TEST SDK_API_HttpTxnTransform started
> Regression test(SDK_API_HttpTxnTransform) still in progress
> [SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] <> { ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnUntransformedResponseCache : [TestCase1] 
> <> { ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformedResponseCache : [TestCase1] 
> <> { ok }
> =
> ==14340==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x60800d59276b at pc 0x005cb466 bp 0x7f4f46b88b40 sp 0x7f4f46b88b30
> READ of size 1 at 0x60800d59276b thread T9 ([ET_NET 8])
> #0 0x5cb465 in transformtest_transform 
> /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6318
> #1 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #2 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #3 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #4 0xc32438 in spawn_thread_internal 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:86
> #5 0x7f4f4da8c554 in start_thread (/lib64/libpthread.so.0+0x7554)
> #6 0x7f4f4c9bcb9c in __clone (/lib64/libc.so.6+0x102b9c)
> 0x60800d59276b is located 75 bytes inside of 96-byte region 
> [0x60800d592720,0x60800d592780)
> freed by thread T4 ([ET_NET 3]) here:
> #0 0x7f4f4fb2470a in __interceptor_free (/lib64/libasan.so.2+0x9870a)
> #1 0x5de815 in transform_hook_handler 
> /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6637
> #2 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #3 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #4 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #5 0xc32438 in spawn_thread_internal 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:86
> #6 0x7f4f4da8c554 in start_thread (/lib64/libpthread.so.0+0x7554)
> previously allocated by thread T0 ([ET_NET 0]) here:
> #0 0x7f4f4fb24a0a in malloc (/lib64/libasan.so.2+0x98a0a)
> #1 0x7f4f4f859ae5 in ats_malloc 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:54
> #2 0x5d3d2a in RegressionTest_SDK_API_HttpTxnTransform(RegressionTest*, 
> int, int*) /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6663
> #3 0x7f4f4f844f69 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:78
> #4 0x7f4f4f844f69 in RegressionTest::run_some() 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:126
> #5 0x7f4f4f845366 in RegressionTest::check_status() 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:141
> #6 0x563773 in RegressionCont::mainEvent(int, Event*) 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1210
> #7 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #8 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #9 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #10 0x497d2c in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1812
> #11 0x7f4f4c8da6ff in __libc_start_main 

[jira] [Updated] (TS-3915) Regression fails when compilied with ASAN, heap-use-after-free

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3915:
--
Labels: ASAN  (was: )

> Regression fails when compilied with ASAN, heap-use-after-free
> --
>
> Key: TS-3915
> URL: https://issues.apache.org/jira/browse/TS-3915
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: ASAN
> Fix For: 7.0.0
>
>
> Running regression with asan enable on Fedora 22:
> {code}
> CXXFLAGS="-Werror -fno-omit-frame-pointer -fsanitize=address" 
> CFLAGS="-Werror" SPDYLAY_CFLAGS="-I /usr/local/include/" 
> SPDYLAY_LIBS="-L/usr/local/lib -lspdylay"  ./configure --enable-ccache 
> --enable-spdy --disable-freelist
> REGRESSION TEST SDK_API_HttpTxnTransform started
> Regression test(SDK_API_HttpTxnTransform) still in progress
> [SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] <> { ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnUntransformedResponseCache : [TestCase1] 
> <> { ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformedResponseCache : [TestCase1] 
> <> { ok }
> =
> ==14340==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x60800d59276b at pc 0x005cb466 bp 0x7f4f46b88b40 sp 0x7f4f46b88b30
> READ of size 1 at 0x60800d59276b thread T9 ([ET_NET 8])
> #0 0x5cb465 in transformtest_transform 
> /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6318
> #1 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #2 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #3 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #4 0xc32438 in spawn_thread_internal 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:86
> #5 0x7f4f4da8c554 in start_thread (/lib64/libpthread.so.0+0x7554)
> #6 0x7f4f4c9bcb9c in __clone (/lib64/libc.so.6+0x102b9c)
> 0x60800d59276b is located 75 bytes inside of 96-byte region 
> [0x60800d592720,0x60800d592780)
> freed by thread T4 ([ET_NET 3]) here:
> #0 0x7f4f4fb2470a in __interceptor_free (/lib64/libasan.so.2+0x9870a)
> #1 0x5de815 in transform_hook_handler 
> /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6637
> #2 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #3 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #4 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #5 0xc32438 in spawn_thread_internal 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:86
> #6 0x7f4f4da8c554 in start_thread (/lib64/libpthread.so.0+0x7554)
> previously allocated by thread T0 ([ET_NET 0]) here:
> #0 0x7f4f4fb24a0a in malloc (/lib64/libasan.so.2+0x98a0a)
> #1 0x7f4f4f859ae5 in ats_malloc 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:54
> #2 0x5d3d2a in RegressionTest_SDK_API_HttpTxnTransform(RegressionTest*, 
> int, int*) /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6663
> #3 0x7f4f4f844f69 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:78
> #4 0x7f4f4f844f69 in RegressionTest::run_some() 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:126
> #5 0x7f4f4f845366 in RegressionTest::check_status() 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:141
> #6 0x563773 in RegressionCont::mainEvent(int, Event*) 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1210
> #7 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #8 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #9 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #10 0x497d2c in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1812
> #11 0x7f4f4c8da6ff in __libc_start_main (/lib64/libc.so.6+0x206ff)
> Thread T9 ([ET_NET 8]) created by T0 ([ET_NET 0]) here:
> #0 0x7f4f4fac2703 in pthread_create 

[jira] [Updated] (TS-3657) Run tsqa with ASAN (and perhaps a TSAN) builds

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3657:
--
Labels: ASAN  (was: )

> Run tsqa with ASAN (and perhaps a TSAN) builds
> --
>
> Key: TS-3657
> URL: https://issues.apache.org/jira/browse/TS-3657
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: tsqa
>Reporter: Leif Hedstrom
>Assignee: Thomas Jackson
> Fix For: sometime
>
>
> We should just enable ASAN (when available) on the tsqa run(s). We will trip 
> on some other stuff as well, I've filed some other Jira's on that issue.
> But, running all of tsqa through ASAN builds would be very useful. On the CI, 
> you would have to use a different gcc. Specifically:
> {code}
> CC="/opt/gcc/bin/gcc"; export CC
> CXX="/opt/gcc/bin/g++"; export CXX
> CFLAGS="-fsanitize=address -fno-omit-frame-pointer"; export CFLAGS
> CXXFLAGS="-fsanitize=address -fno-omit-frame-pointer"; export CXXFLAGS
> {code}



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

[jira] [Updated] (TS-3805) ASAN heap-use-after-free in ProxyClientSession::ssn_hook_get

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3805:
--
Labels: ASAN crash  (was: asan crash)

> ASAN heap-use-after-free in ProxyClientSession::ssn_hook_get
> 
>
> Key: TS-3805
> URL: https://issues.apache.org/jira/browse/TS-3805
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>  Labels: ASAN, crash
> Fix For: 7.0.0
>
>
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/ats'
> [Jul 30 11:02:22.124] Manager {0x7f1366c0e8c0} WARNING: Be aware that access 
> control checks for HTTP/2 connections are not active!
> [Jul 30 11:02:22.124] Manager {0x7f1366c0e8c0} WARNING: Be aware that access 
> control checks for HTTP/2 connections are not active!
> traffic_server: using root directory '/opt/ats'
> =
> ==11239==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x6179a170 at pc 0x52e50d bp 0x2b9d1a56a6b0 sp 0x2b9d1a56a6a8
> READ of size 8 at 0x6179a170 thread T3 ([ET_NET 2])
> #0 0x52e50c in APIHooks::get() const 
> /usr/local/src/trafficserver/proxy/InkAPI.cc:1258
> #1 0x66bb1e in FeatureAPIHooks (TSHttpHookID)19>::get(TSHttpHookID) const ../../proxy/InkAPIInternal.h:256
> #2 0x66bb1e in ProxyClientSession::ssn_hook_get(TSHttpHookID) const 
> ../../proxy/ProxyClientSession.h:64
> #3 0x66bb1e in HttpSM::state_api_callout(int, void*) 
> /usr/local/src/trafficserver/proxy/http/HttpSM.cc:1328
> #4 0x67c586 in HttpSM::kill_this() 
> /usr/local/src/trafficserver/proxy/http/HttpSM.cc:6552
> #5 0x67f817 in HttpSM::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http/HttpSM.cc:2558
> #6 0xbb82d0 in Continuation::handleEvent(int, void*) 
> ../../iocore/eventsystem/I_Continuation.h:146
> #7 0xbb82d0 in read_signal_and_update 
> /usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:145
> #8 0xbb82d0 in UnixNetVConnection::mainEvent(int, Event*) 
> /usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:1175
> #9 0xb8d622 in Continuation::handleEvent(int, void*) 
> ../../iocore/eventsystem/I_Continuation.h:146
> #10 0xb8d622 in InactivityCop::check_inactivity(int, Event*) 
> /usr/local/src/trafficserver/iocore/net/UnixNet.cc:102
> #11 0xc336de in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #12 0xc336de in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #13 0xc35947 in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #14 0xc322e8 in spawn_thread_internal 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #15 0x2b9d1363bdf4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> #16 0x2b9d14ea41ac in __clone (/lib64/libc.so.6+0xf61ac)
> 0x6179a170 is located 240 bytes inside of 688-byte region 
> [0x6179a080,0x6179a330)
> freed by thread T3 ([ET_NET 2]) here:
> #0 0x2b9d1123a1c7 in __interceptor_free 
> ../../.././libsanitizer/asan/asan_malloc_linux.cc:62
> #1 0x62f74e in HttpVCTable::cleanup_entry(HttpVCTableEntry*) 
> /usr/local/src/trafficserver/proxy/http/HttpSM.cc:216
> #2 0x65047a in HttpSM::state_read_client_request_header(int, void*) 
> /usr/local/src/trafficserver/proxy/http/HttpSM.cc:606
> #3 0x67f4f0 in HttpSM::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http/HttpSM.cc:2545
> #4 0xbb82d0 in Continuation::handleEvent(int, void*) 
> ../../iocore/eventsystem/I_Continuation.h:146
> #5 0xbb82d0 in read_signal_and_update 
> /usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:145
> #6 0xbb82d0 in UnixNetVConnection::mainEvent(int, Event*) 
> /usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:1175
> #7 0xb8d622 in Continuation::handleEvent(int, void*) 
> ../../iocore/eventsystem/I_Continuation.h:146
> #8 0xb8d622 in InactivityCop::check_inactivity(int, Event*) 
> /usr/local/src/trafficserver/iocore/net/UnixNet.cc:102
> #9 0xc336de in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #10 0xc336de in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #11 0xc35947 in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #12 0xc322e8 in spawn_thread_internal 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #13 0x2b9d1363bdf4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> previously allocated by 

[jira] [Updated] (TS-3657) Run tsqa with ASAN (and perhaps a TSAN) builds

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3657:
--
Labels:   (was: ASAN)

> Run tsqa with ASAN (and perhaps a TSAN) builds
> --
>
> Key: TS-3657
> URL: https://issues.apache.org/jira/browse/TS-3657
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: tsqa
>Reporter: Leif Hedstrom
>Assignee: Thomas Jackson
> Fix For: sometime
>
>
> We should just enable ASAN (when available) on the tsqa run(s). We will trip 
> on some other stuff as well, I've filed some other Jira's on that issue.
> But, running all of tsqa through ASAN builds would be very useful. On the CI, 
> you would have to use a different gcc. Specifically:
> {code}
> CC="/opt/gcc/bin/gcc"; export CC
> CXX="/opt/gcc/bin/g++"; export CXX
> CFLAGS="-fsanitize=address -fno-omit-frame-pointer"; export CFLAGS
> CXXFLAGS="-fsanitize=address -fno-omit-frame-pointer"; export CXXFLAGS
> {code}



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

[jira] [Updated] (TS-4114) ASAN based build fails with gcc 5

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4114:
--
Labels: ASAN  (was: )

> ASAN based build fails with gcc 5
> -
>
> Key: TS-4114
> URL: https://issues.apache.org/jira/browse/TS-4114
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Jason Kenny
>Assignee: Jason Kenny
>  Labels: ASAN
> Fix For: 7.0.0
>
>
> When building with gcc 5.x and asan on, the build will fail with memory leak 
> issues in lua.
> ==1442==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 4112 byte(s) in 1 object(s) allocated from:
> #0 0x47f8ea in __interceptor_malloc 
> (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea)
> #1 0x407c8d in build_code host/buildvm.c:204
> #2 0x407c8d in main host/buildvm.c:446
> #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c)
> Direct leak of 1304 byte(s) in 1 object(s) allocated from:
> #0 0x47fa51 in calloc 
> (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47fa51)
> #1 0x405666 in build_code host/buildvm.c:177
> #2 0x405666 in main host/buildvm.c:446
> #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c)
> Direct leak of 372 byte(s) in 1 object(s) allocated from:
> #0 0x47f8ea in __interceptor_malloc 
> (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea)
> #1 0x407cae in build_code host/buildvm.c:206
> #2 0x407cae in main host/buildvm.c:446
> #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c)
> Direct leak of 296 byte(s) in 1 object(s) allocated from:
> #0 0x47f8ea in __interceptor_malloc 
> (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea)
> #1 0x40568d in build_code host/buildvm.c:182
> #2 0x40568d in main host/buildvm.c:446
> #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c)
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x47f8ea in __interceptor_malloc 
> (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea)
> #1 0x407c58 in sym_decorate host/buildvm.c:122
> #2 0x407c58 in build_code host/buildvm.c:203
> #3 0x407c58 in main host/buildvm.c:446
> #4 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c)
> Indirect leak of 14758 byte(s) in 1 object(s) allocated from:
> #0 0x47f8ea in __interceptor_malloc 
> (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea)
> #1 0x407bbc in build_code host/buildvm.c:199
> #2 0x407bbc in main host/buildvm.c:446
> #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c)
> Indirect leak of 2425 byte(s) in 156 object(s) allocated from:
> #0 0x47f8ea in __interceptor_malloc 
> (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea)
> #1 0x4b129c in sym_decorate host/buildvm.c:122
> #2 0x4b129c in sym_insert host/buildvm.c:166
> #3 0x407ed5 in build_code host/buildvm.c:230
> #4 0x407ed5 in main host/buildvm.c:446
> #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c)
> Indirect leak of 1082 byte(s) in 93 object(s) allocated from:
> #0 0x47f8ea in __interceptor_malloc 
> (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea)
> #1 0x4b129c in sym_decorate host/buildvm.c:122
> #2 0x4b129c in sym_insert host/buildvm.c:166
> #3 0x407e72 in build_code host/buildvm.c:217
> #4 0x407e72 in main host/buildvm.c:446
> #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c)
> Indirect leak of 525 byte(s) in 37 object(s) allocated from:
> #0 0x47f8ea in __interceptor_malloc 
> (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea)
> #1 0x4b4722 in sym_decorate host/buildvm.c:122
> #2 0x4b4722 in collect_reloc host/buildvm.c:140
> #3 0x4b4722 in dasm_encode ../dynasm/dasm_x86.h:425
> #4 0x407bce in build_code host/buildvm.c:200
> #5 0x407bce in main host/buildvm.c:446
> #6 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c)
> Indirect leak of 1 byte(s) in 1 object(s) allocated from:
> #0 0x47f8ea in __interceptor_malloc 
> (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea)
> #1 0x4b129c in sym_decorate host/buildvm.c:122
> #2 0x4b129c in sym_insert host/buildvm.c:166
> #3 0x407fc9 in build_code host/buildvm.c:235
> #4 0x407fc9 in main host/buildvm.c:446
> #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c)
> SUMMARY: AddressSanitizer: 24891 byte(s) leaked in 293 allocation(s).
> make[5]: *** [lj_ffdef.h] Error 23



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

[jira] [Updated] (TS-4558) ASAN buffer overflow in traffic_manager -h

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4558:
--
Labels: ASAN  (was: )

> ASAN buffer overflow in traffic_manager -h
> --
>
> Key: TS-4558
> URL: https://issues.apache.org/jira/browse/TS-4558
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>  Labels: ASAN
> Fix For: 7.0.0
>
>
> {code}
> [root@qa1 ats]# ./bin/traffic_manager  -h
> Usage: traffic_manager [--SWITCH [ARG]]
>   switch__type__default___description
>   --proxyOff  on   
> =
> ==14425==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x0089fd40 at pc 0x7fd0aef80b5e bp 0x7ffe0d210590 sp 0x7ffe0d210588
> READ of size 4 at 0x0089fd40 thread T0
> #0 0x7fd0aef80b5d in usage(ArgumentDescription const*, unsigned int, char 
> const*) /usr/local/src/trafficserver/lib/ts/ink_args.cc:323
> #1 0x7fd0aef7f5c7 in process_arg 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:122
> #2 0x7fd0aef80135 in process_args_ex(AppVersionInfo const*, 
> ArgumentDescription const*, unsigned int, char const**) 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:237
> #3 0x7fd0aef80bba in process_args(AppVersionInfo const*, 
> ArgumentDescription const*, unsigned int, char const**, char const*) 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:166
> #4 0x4305a4 in main 
> /usr/local/src/trafficserver/cmd/traffic_manager/traffic_manager.cc:481
> #5 0x7fd0abbfdb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> #6 0x4343e4  (/opt/ats/bin/traffic_manager+0x4343e4)
> 0x0089fd41 is located 0 bytes to the right of global variable 'proxy_off' 
> defined in 'traffic_manager.cc:86:13' (0x89fd40) of size 1
>   'proxy_off' is ascii string ''
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:323 usage(ArgumentDescription 
> const*, unsigned int, char const*)
> Shadow bytes around the buggy address:
>   0x8010bf50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf60: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x8010bfa0: 00 00 00 00 f9 f9 f9 f9[01]f9 f9 f9 f9 f9 f9 f9
>   0x8010bfb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Heap right redzone:  fb
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack partial redzone:   f4
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
> ==14425==ABORTING
> {code}



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

[jira] [Updated] (TS-4554) ASAN crash (stack overflow) with H2 priorities

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4554:
--
Labels: ASAN  (was: )

> ASAN crash (stack overflow) with H2 priorities
> --
>
> Key: TS-4554
> URL: https://issues.apache.org/jira/browse/TS-4554
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Affects Versions: 7.0.0
>Reporter: Leif Hedstrom
>Assignee: Masaori Koshiba
>  Labels: ASAN
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> I'm seeing (truncated):
> {code}
> ASAN:SIGSEGV
> =
> ==11178==ERROR: AddressSanitizer: stack-overflow on address 0x2aab63633ff0 
> (pc 0x007ddaa9 bp 0x2aab63634050 sp 0x2aab63633ff0 T6)
> #0 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134
> #1 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> .
> .
> .
> #2261 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2262 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2263 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> SUMMARY: AddressSanitizer: stack-overflow 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int)
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x2aab5b0d50c4 in __interceptor_pthread_create 
> ../../../../libsanitizer/asan/asan_interceptors.cc:179
> #1 0xcfdb99 in ink_thread_create ../../lib/ts/ink_thread.h:147
> #2 0xcfdb99 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:99
> #3 0xd0562e in EventProcessor::start(int, unsigned long) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEventProcessor.cc:140
> #4 0x497b59 in main /usr/local/src/trafficserver/proxy/Main.cc:1746
> #5 0x2aab5ee11b14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> ==11178==ABORTING
> {code}



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

[jira] [Updated] (TS-4541) SEGV in send_a_data_frame with HTTP/2 (possibly ASAN mutex)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4541:
--
Labels: A ASAN  (was: A)

> SEGV in send_a_data_frame with HTTP/2 (possibly ASAN  mutex)
> 
>
> Key: TS-4541
> URL: https://issues.apache.org/jira/browse/TS-4541
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Priority: Critical
>  Labels: A, ASAN
> Fix For: 7.0.0
>
>
> {code}
> ==26628==ERROR: AddressSanitizer: SEGV on unknown address 0x0038 (pc 
> 0x009ad1b9 sp 0x2b7e55d79740 bp 0x2b7e55d7d8f0 T15)
> #0 0x9ad1b8 in Mutex_lock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:381
> #1 0x9ad1b8 in MutexLock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:449
> #2 0x9ad1b8 in Http2ConnectionState::send_a_data_frame(Http2Stream*, 
> unsigned long&) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1040
> #3 0x9af71d in 
> Http2ConnectionState::send_data_frames_depends_on_priority() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1000
> #4 0x9b1ff9 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:803
> #5 0xe9f5e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0xe9f5e3 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #7 0xea18c9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:202
> #8 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2b7e4d575aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #10 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Updated] (TS-4559) ASAN leaks / errors in traffic_manager (on exit)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4559:
--
Labels: ASAN  (was: )

> ASAN leaks / errors in traffic_manager (on exit)
> 
>
> Key: TS-4559
> URL: https://issues.apache.org/jira/browse/TS-4559
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>  Labels: ASAN
> Fix For: sometime
>
>
> When we exit manager, ASAN trips on a few things, it'd be nice if we had a 
> clean shutdown on traffic_manager.
> {code}
> =
> ==14870==ERROR: AddressSanitizer: attempting double-free on 0x61902d80 in 
> thread T0 ([ET_NET 0]):
> ==14870==WARNING: readlink("/proc/self/exe") failed with errno 13, some stack 
> frames may not be symbolized
> #0 0x2ac4a4efddca  (/opt/gcc5/lib/../lib64/libasan.so.2+0x93dca)
> #1 0x2ac4a8bf3e8f  (/lib64/libc.so.6+0x38e8f)
> #2 0x2ac4a8bf3eb4  (/lib64/libc.so.6+0x38eb4)
> #3 0x58cc0b  (/proc/self/exe+0x58cc0b)
> #4 0x2ac4a7f280ff  (/lib64/libpthread.so.0+0xf0ff)
> #5 0x2ac4a8cb22c2  (/lib64/libc.so.6+0xf72c2)
> #6 0xc8fde6  (/proc/self/exe+0xc8fde6)
> #7 0xd80203  (/proc/self/exe+0xd80203)
> #8 0xd831aa  (/proc/self/exe+0xd831aa)
> #9 0x49b36e  (/proc/self/exe+0x49b36e)
> #10 0x2ac4a8bdcb14  (/lib64/libc.so.6+0x21b14)
> #11 0x4aacc4  (/proc/self/exe+0x4aacc4)
> 0x61902d80 is located 0 bytes inside of 1040-byte region 
> [0x61902d80,0x61903190)
> freed by thread T1 here:
> #0 0x2ac4a4efddca  (/opt/gcc5/lib/../lib64/libasan.so.2+0x93dca)
> #1 0x2ac4a8bf3e8f  (/lib64/libc.so.6+0x38e8f)
> previously allocated by thread T0 ([ET_NET 0]) here:
> #0 0x2ac4a4efe1d1  (/opt/gcc5/lib/../lib64/libasan.so.2+0x941d1)
> #1 0x2ac4a8bf4043  (/lib64/libc.so.6+0x39043)
> Thread T1 created by T0 ([ET_NET 0]) here:
> #0 0x2ac4a4ea00c4  (/opt/gcc5/lib/../lib64/libasan.so.2+0x360c4)
> #1 0x498ee5  (/proc/self/exe+0x498ee5)
> #2 0x2ac4a8bdcb14  (/lib64/libc.so.6+0x21b14)
> SUMMARY: AddressSanitizer: double-free ??:0 ??
> ==14870==ABORTING
> [TrafficManager] ==> signal #2
> =
> ==14864==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 8964 byte(s) in 249 object(s) allocated from:
> #0 0x7faab3c7006a in __interceptor_malloc 
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:38
> #1 0x7faab1f3281f in cap_init (/lib64/libcap.so.2+0x181f)
> #2 0x7faab39a1d2e in ElevateAccess::ElevateAccess(unsigned int) 
> /usr/local/src/trafficserver/lib/ts/ink_cap.cc:413
> #3 0x48aa7f in Rollback::statFile(int, stat*) 
> /usr/local/src/trafficserver/mgmt/Rollback.cc:267
> #4 0x48ea10 in Rollback::checkForUserUpdate(RollBackCheckType) 
> /usr/local/src/trafficserver/mgmt/Rollback.cc:911
> #5 0x481adf in FileManager::isConfigStale() 
> /usr/local/src/trafficserver/mgmt/FileManager.cc:690
> #6 0x50c697 in sync_thr 
> /usr/local/src/trafficserver/lib/records/RecLocal.cc:106
> #7 0x7faab1449dc4 in start_thread (/lib64/libpthread.so.0+0x7dc4)
> Direct leak of 6361 byte(s) in 208 object(s) allocated from:
> #0 0x7faab3c7006a in __interceptor_malloc 
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:38
> #1 0x7faab39aaaf5 in ats_malloc 
> /usr/local/src/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x7faab39ab036 in _xstrdup 
> /usr/local/src/trafficserver/lib/ts/ink_memory.cc:268
> #3 0x55cf74 in lua_metrics_new(char const*, lua_State*) 
> /usr/local/src/trafficserver/lib/bindings/metrics.cc:186
> #4 0x55d3c6 in lua_metrics_install(lua_State*) 
> /usr/local/src/trafficserver/lib/bindings/metrics.cc:230
> #5 0x447576 in update_metrics_namespace 
> /usr/local/src/trafficserver/cmd/traffic_manager/metrics.cc:162
> #6 0x447576 in metrics_binding_evaluate(BindingInstance&) 
> /usr/local/src/trafficserver/cmd/traffic_manager/metrics.cc:372
> #7 0x431b48 in main 
> /usr/local/src/trafficserver/cmd/traffic_manager/traffic_manager.cc:807
> #8 0x7faab061bb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> Direct leak of 842 byte(s) in 30 object(s) allocated from:
> #0 0x7faab3c7006a in __interceptor_malloc 
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:38
> #1 0x7faab39aaaf5 in ats_malloc 
> /usr/local/src/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x7faab39ab036 in _xstrdup 
> /usr/local/src/trafficserver/lib/ts/ink_memory.cc:268
> #3 0x55cf74 in lua_metrics_new(char const*, lua_State*) 
> /usr/local/src/trafficserver/lib/bindings/metrics.cc:186
> #4 0x55d3c6 in lua_metrics_install(lua_State*) 
> /usr/local/src/trafficserver/lib/bindings/metrics.cc:230
> #5 0x446b12 in update_metrics_namespace 
> 

[jira] [Created] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[Kyle O'Malley (JIRA)]

Kyle O'Malley created TS-4716:
-

 Summary: 6.2.0: build is putting files into wrong directory? 
/usr/man/man3 instead of /usr/share/man/man3
 Key: TS-4716
 URL: https://issues.apache.org/jira/browse/TS-4716
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: Kyle O'Malley


PROBLEM:
Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
location? 


RPM build errors:
File not found by glob: 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
File not found: 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
File not found: 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
File not found by glob: 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)


These files are not ending up in /usr/share/man/man3, but rather /usr/man/man3/

Doesn't matter what I manually configure prefix or change build config to


./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
--target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
--mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
--libdir=/usr/lib64/trafficserver --libexecdir=/usr/lib64/trafficserver/plugins 
--sysconfdir=/etc/trafficserver --with-tcl=/usr/lib64 --disable-luajit 
--with-user=ats --with-group=ats --enable-linux-native-aio 
--enable-experimental-plugins --disable-silent-rules


h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so this 
could be a duplicate bug report

== build system
oel6.5 / linux 
make-3.81-23.el6.x86_64
==

something strange here (maybe) with INSTALL_DIRS missing?

make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
make[4]: Entering directory 
`/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
Installing 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
Installing 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
Installing 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
Installing 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
Installing 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
Installing 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
Installing 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
Installing 
/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
INSTALLDIRS not defined, defaulting to INSTALLDIRS=site




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