date:20151005

Build failed in Jenkins: tsqa-master #906

2015-10-05 Thread jenkins

See 

--
[...truncated 479 lines...]
INFO 2015-10-05 17:57:43,047 - sending data back to the client
INFO 2015-10-05 17:57:45,048 - Client disconnected
INFO 2015-10-05 17:57:45,450 - sending data back to the client
INFO 2015-10-05 17:57:45,857 - sending data back to the client
INFO 2015-10-05 17:57:47,858 - Client disconnected
INFO 2015-10-05 17:57:49,862 - sending data back to the client
ok
INFO 2015-10-05 17:57:51,873 - Client disconnected
INFO 2015-10-05 17:57:52,066 - Environment prefix is /tmp/tsqa.env.FAscT7
INFO 2015-10-05 17:57:53,868 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... ok
Verify that we get 502s from origins that reset_after_accept, once any bytes 
are sent to origin we assume we cannot re-dispatch ... ok
INFO 2015-10-05 17:58:02,388 - Environment prefix is /tmp/tsqa.env.5C3IMa
test_log_field (test_custom_log.TestCustomLogField) ... FAIL
INFO 2015-10-05 17:58:15,934 - Environment prefix is /tmp/tsqa.env.U2TAS1
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-10-05 17:58:47,471 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-10-05 17:59:53,353 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-10-05 17:59:53,415 - Environment prefix is /tmp/tsqa.env.5zxItU
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-10-05 17:59:56,825 - Environment prefix is /tmp/tsqa.env.zl2F8D
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[05/Oct/2015 18:00:00] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-10-05 18:00:00,251 - Environment prefix is /tmp/tsqa.env.weTfMv
test_logs_exist (test_example.TestLogs) ... ok
SKIP: Skip the entire class
INFO 2015-10-05 18:00:13,814 - Environment prefix is /tmp/tsqa.env.7hdutP
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[05/Oct/2015 18:00:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [05/Oct/2015 18:00:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [05/Oct/2015 18:00:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [05/Oct/2015 18:00:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [05/Oct/2015 18:00:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [05/Oct/2015 18:00:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [05/Oct/2015 18:00:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [05/Oct/2015 18:00:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [05/Oct/2015 18:00:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [05/Oct/2015 18:00:17] "GET / HTTP/1.1" 200 5
ok
INFO 2015-10-05 18:00:17,293 - Environment prefix is /tmp/tsqa.env.bK0KtY
INFO 2015-10-05 18:00:17,295 - map / http://127.0.0.1:51142/
test_head_request_without_timout 
(test_headrequest.TestHeadRequestWithoutTimeout) ... INFO 2015-10-05 
18:00:20,528 - HTTP/1.1 200 OK
Server: ATS/6.1.0
Vary: Accept-Encoding
Date: Mon, 05 Oct 2015 18:00:20 GMT
Age: 0
Connection: close


INFO 2015-10-05 18:00:20,528 - head request with case(TE) costs 0.004255 
seconds while the timout is 5.00 seconds.
INFO 2015-10-05 18:00:20,544 - HTTP/1.1 200 OK
Server: ATS/6.1.0
Content-Length: 123
Vary: Accept-Encoding
Date: Mon, 05 Oct 2015 18:00:20 GMT
Age: 0
Connection: close


INFO 2015-10-05 18:00:20,545 - head request with case(CL) costs 0.016216 
seconds while the timout is 5.00 seconds.
INFO 2015-10-05 18:00:20,556 - HTTP/1.1 200 OK
Server: ATS/6.1.0
Vary: Accept-Encoding
Date: Mon, 05 Oct 2015 18:00:20 GMT
Age: 0
Connection: close


INFO 2015-10-05 18:00:20,557 - head request with case() costs 0.011320 seconds 
while the timout is 5.00 seconds.
ok
INFO 2015-10-05 18:00:20,738 - Environment prefix is /tmp/tsqa.env.E6mj2P
test_working (test_hostdb.TestHostDBBadResolvConf) ... ok
INFO 2015-10-05 18:00:24,194 - Environment prefix is /tmp/tsqa.env.v1Q1Le
test_lookup_timeout (test_hostdb.TestHostDBFailedDNS) ... ok
INFO 2015-10-05 18:00:29,729 - Environment prefix is /tmp/tsqa.env.IRtiwr
Test basic fnctionality of hosts files ... ok
Test that changes to hosts file get loaded within host_file.interval ... ok
INFO 2015-10-05 18:00:39,233 - Environment prefix is /tmp/tsqa.env.N85wSR
SKIP: 
 >> begin captured logging << 
root: INFO: Environment prefix is /tmp/tsqa.env.N85wSR

Jenkins build is back to normal : tsqa-master #907

2015-10-05 Thread jenkins

See

Build failed in Jenkins: clang-analyzer #1469

2015-10-05 Thread jenkins

See 

Changes:

[mlibbey] invalid markup preventing table from displaying

[mlibbey] Fix invalid rst syntax

[shinrich] TS-3901: Leaking connections from HttpSessionManager.

--
[...truncated 2390 lines...]
reading sources... [ 91%] sdk/io-guide/guide-to-cache-api/errors.en
reading sources... [ 92%] sdk/io-guide/guide-to-cache-api/example.en
reading sources... [ 92%] 
sdk/io-guide/guide-to-cache-api/how-to-do-a-cache-remove.en
reading sources... [ 92%] 
sdk/io-guide/guide-to-cache-api/how-to-do-a-cache-write.en
reading sources... [ 93%] sdk/io-guide/io-buffers.en
reading sources... [ 93%] sdk/io-guide/net-vconnections.en
reading sources... [ 93%] sdk/io-guide/transformations.en
reading sources... [ 93%] sdk/io-guide/vios.en
reading sources... [ 94%] sdk/misc-interface-guide.en
reading sources... [ 94%] sdk/misc-interface-guide/memory-allocation.en
reading sources... [ 94%] sdk/misc-interface-guide/thread-functions.en
reading sources... [ 95%] sdk/misc-interface-guide/tsfopen-family.en
reading sources... [ 95%] sdk/mutex-guide.en
reading sources... [ 95%] sdk/new-protocol-plugins.en
reading sources... [ 95%] sdk/plugin-configurations.en
reading sources... [ 96%] sdk/plugin-management.en
reading sources... [ 96%] sdk/plugin-management/guide-to-the-logging-api.en
reading sources... [ 96%] 
sdk/plugin-management/reading-trafficserver-settings-and-statistics.en
reading sources... [ 96%] sdk/preface.en
reading sources... [ 97%] sdk/preface/how-to-use-this-book.en
reading sources... [ 97%] sdk/preface/typographical-conventions.en
reading sources... [ 97%] sdk/remap-plugin.en
reading sources... [ 98%] sdk/remap-plugin/example-query-remap.en
reading sources... [ 98%] sdk/sample-source-code.en
reading sources... [ 98%] sdk/trafficserver-timers.en
reading sources... [ 98%] sdk/troubleshooting-tips.en
reading sources... [ 99%] sdk/troubleshooting-tips/debugging-memory-leaks.en
reading sources... [ 99%] sdk/troubleshooting-tips/unable-to-debug-tags.en
reading sources... [ 99%] sdk/troubleshooting-tips/unable-to-load-plugins.en
reading sources... [100%] sdk/troubleshooting-tips/using-a-debugger.en

:350:
 WARNING: malformed hyperlink target.
:26:
 ERROR: Unknown interpreted text role "c:arg".
:32:
 ERROR: Unknown interpreted text role "c:arg".
:32:
 ERROR: Unknown interpreted text role "c:arg".
:32:
 ERROR: Unknown interpreted text role "c:arg".
:63:
 ERROR: Unknown interpreted text role "cpp:arg".
:63:
 ERROR: Unknown interpreted text role "cpp:arg".
:69:
 ERROR: Unknown interpreted text role "cpp:arg".
:69:
 ERROR: Unknown interpreted text role "cpp:arg".
:26:
 WARNING: duplicate C object description of TSHttpTxnCacheLookupUrlGet, other 
instance in 

:45:
 WARNING: duplicate C object description of TSHttpTxnCacheLookupUrlSet, other 
instance in 

:2950:
 ERROR: Unknown interpreted text role "configfile".
:2955:
 ERROR: Unknown interpreted text role "configfile".
:63:
 WARNING: toctree contains reference to nonexisting document 
u'reference/plugins/Cache Promotion: provides additional control over when an 
object should be'
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
writing... TSAPI.3ts { } None:None: WARNING: c:data reference target not found: 
TS_EVENT_NONE
None:None:

[jira] [Commented] (TS-3901) Leaking connections from HttpSessionManager

2015-10-05 Thread ASF subversion and git services (JIRA)


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

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

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

TS-3901: Leaking connections from HttpSessionManager.


> Leaking connections from HttpSessionManager
> ---
>
> Key: TS-3901
> URL: https://issues.apache.org/jira/browse/TS-3901
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3901.diff
>
>
> Observed in production.  Got the following warnings in diags.log
> "Connection leak from http keep-alive system"
> Our connections to origin would increase and the number of connections in 
> CLOSE_WAIT were enormous.
> I think the issue was when the origin URL was http with default port.  That 
> URL was remapped to https with default port.  The default port stored in 
> HttpServerSession->server_ip was not updated.  
> When the connection was closed or timed out of the session pool, it would be 
> looked up with port 443.   But the session was stored via the server_ip value 
> with port 80 and would never match.
> Relatively small change in HTTPHdr::_file_target_cache. 
> Running the fix in production to verify early results.



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

Build failed in Jenkins: clang-analyzer #1470

2015-10-05 Thread jenkins

See 

Changes:

[shinrich] Fix traffic_via regression test.

--
[...truncated 2390 lines...]
reading sources... [ 91%] sdk/io-guide/guide-to-cache-api/errors.en
reading sources... [ 92%] sdk/io-guide/guide-to-cache-api/example.en
reading sources... [ 92%] 
sdk/io-guide/guide-to-cache-api/how-to-do-a-cache-remove.en
reading sources... [ 92%] 
sdk/io-guide/guide-to-cache-api/how-to-do-a-cache-write.en
reading sources... [ 93%] sdk/io-guide/io-buffers.en
reading sources... [ 93%] sdk/io-guide/net-vconnections.en
reading sources... [ 93%] sdk/io-guide/transformations.en
reading sources... [ 93%] sdk/io-guide/vios.en
reading sources... [ 94%] sdk/misc-interface-guide.en
reading sources... [ 94%] sdk/misc-interface-guide/memory-allocation.en
reading sources... [ 94%] sdk/misc-interface-guide/thread-functions.en
reading sources... [ 95%] sdk/misc-interface-guide/tsfopen-family.en
reading sources... [ 95%] sdk/mutex-guide.en
reading sources... [ 95%] sdk/new-protocol-plugins.en
reading sources... [ 95%] sdk/plugin-configurations.en
reading sources... [ 96%] sdk/plugin-management.en
reading sources... [ 96%] sdk/plugin-management/guide-to-the-logging-api.en
reading sources... [ 96%] 
sdk/plugin-management/reading-trafficserver-settings-and-statistics.en
reading sources... [ 96%] sdk/preface.en
reading sources... [ 97%] sdk/preface/how-to-use-this-book.en
reading sources... [ 97%] sdk/preface/typographical-conventions.en
reading sources... [ 97%] sdk/remap-plugin.en
reading sources... [ 98%] sdk/remap-plugin/example-query-remap.en
reading sources... [ 98%] sdk/sample-source-code.en
reading sources... [ 98%] sdk/trafficserver-timers.en
reading sources... [ 98%] sdk/troubleshooting-tips.en
reading sources... [ 99%] sdk/troubleshooting-tips/debugging-memory-leaks.en
reading sources... [ 99%] sdk/troubleshooting-tips/unable-to-debug-tags.en
reading sources... [ 99%] sdk/troubleshooting-tips/unable-to-load-plugins.en
reading sources... [100%] sdk/troubleshooting-tips/using-a-debugger.en

:350:
 WARNING: malformed hyperlink target.
:26:
 ERROR: Unknown interpreted text role "c:arg".
:32:
 ERROR: Unknown interpreted text role "c:arg".
:32:
 ERROR: Unknown interpreted text role "c:arg".
:32:
 ERROR: Unknown interpreted text role "c:arg".
:63:
 ERROR: Unknown interpreted text role "cpp:arg".
:63:
 ERROR: Unknown interpreted text role "cpp:arg".
:69:
 ERROR: Unknown interpreted text role "cpp:arg".
:69:
 ERROR: Unknown interpreted text role "cpp:arg".
:26:
 WARNING: duplicate C object description of TSHttpTxnCacheLookupUrlGet, other 
instance in 

:45:
 WARNING: duplicate C object description of TSHttpTxnCacheLookupUrlSet, other 
instance in 

:2950:
 ERROR: Unknown interpreted text role "configfile".
:2955:
 ERROR: Unknown interpreted text role "configfile".
:63:
 WARNING: toctree contains reference to nonexisting document 
u'reference/plugins/Cache Promotion: provides additional control over when an 
object should be'
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
writing... TSAPI.3ts { } None:None: WARNING: c:data reference target not found: 
TS_EVENT_NONE
None:None: WARNING: c:data reference target not found: TS_EVENT_NONE
None:None: WARNING: c:data reference target not found:

[jira] [Commented] (TS-315) Add switch to disable config file generation/runtime behavior changing

2015-10-05 Thread Alan M. Carroll (JIRA)


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

Alan M. Carroll commented on TS-315:


This seems reasonable for 6.0. For 7.0 we may want to shift this to be an 
option on {{traffic_ctl}} so that it controls the persistence of the update. 
That would provide the most flexibility.

> Add switch to disable config file generation/runtime behavior changing
> --
>
> Key: TS-315
> URL: https://issues.apache.org/jira/browse/TS-315
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Miles Libbey
>Assignee: Bryan Call
>Priority: Minor
>  Labels: A, yahoo
> Fix For: sometime
>
>
> (was yahoo bug 1863676)
> Original description
> by Michael S. Fischer  2 years ago at 2008-04-09 09:52
> In production, in order to improve site stability, it is imperative that TS 
> never accidentally overwrite its own
> configuration files.  
> For this reason, we'd like to request a switch be added to TS, preferably via 
> the command line, that disables all
> automatic configuration file generation or other  runtime behavioral changes 
> initiated by any form of IPC other than
> 'traffic_line -x'  (including the web interface, etc.)
>   
>  
> Comment 1
>  by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17
> A very crucial request, in my opinion. If TS needs to be able to read 
> command-line config changes on the fly, these
> changes should be stored in another config file (for example 
> remap.config.local instead of remap.config). We have a
> patch config package that overwrites 4 of the config files under 
> /home/conf/ts/, and with all packages 
> we'd like to think that the content of these files can't change outside our 
> control.
>
> Comment 2
>  by Bryan Call  2 years ago at 2008-04-09 11:02:46
> traffic_line -x doesn't modify the configuration, it reloads the 
> configuration files.  If we want to have an option for
> this it would be good to have it as an option configuration file (CONFIG 
> proxy.config.write_protect INT 1).
> It would be an equivalent of write protecting floppies (ahh the memories)...
>   
>  
> Comment 3
>  by Michael S. Fischer  2 years ago at 2008-04-09 11:09:09
> I don't think it would be a good idea to have this in the configuration file, 
> as it would introduce a chicken/egg
> problem.
>   
>  
> Comment 4
>  by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17
> So I'm not 100% positive that this isn't just a bad interaction. Now, it's 
> only
> triggered when trafficserver is running, but usually what ends up happening 
> is that we get a records.config which
> looks like it's the default config that comes with the trafficserver package.
> It's possible it's all one and the same issue, or we might have two issues.
>   



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

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

2015-10-05 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom commented on TS-3072:
---

Seems reasonable. Was this benchmarked? A test which is running at 100k or more 
QPS would be useful to verify that there not a performance issue, at least when 
not enabled.

> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>  Labels: Yahoo
> Fix For: sometime
>
> Attachments: ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



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

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

2015-10-05 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on TS-3956:


Github user bgaff commented on the pull request:

https://github.com/apache/trafficserver/pull/300#issuecomment-145744298
  
Any other comments on the implementation before I land it?


> Header_rewrite applies strange logic with = operator and whitespace
> ---
>
> Key: TS-3956
> URL: https://issues.apache.org/jira/browse/TS-3956
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that whitespace causes weird behavior with header_rewrite, for 
> example:
> If you remove the white space before the = and the quotes it appears to 
> behave correctly. This whitespace issue is likely to cause strange bugs and 
> needs to be fixed.
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
> cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
> add-header X-HeaderRewriteApplied true
> {code}
> With the following request:
> {code}
> curl -v localhost/
> {code}
> Header_rewrite will incorrectly apply the rule:
> {code}
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Building 
> resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)  Adding 
> TXN client request header buffers
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: Host, field_loc: 0x7fffd02070d0
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Appending HEADER(Host) to evaluation value -> localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Test 
> regular expression ^localhost$ : localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Successfully found regular expression match
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER(): localhost - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: non_existent_header, field_loc: (nil)
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER():  - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> OperatorAddHeader::exec() invoked on header X-HeaderRewriteApplied: true
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)
> Adding header X-HeaderRewriteApplied
> {code}



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

Failed: trafficserver (9d4da597)

2015-10-05 Thread Read the Docs


Build Failed for trafficserver (latest)



You can find out more about this failure here:
https://readthedocs.org/projects/trafficserver/builds/3376426/

If you have questions, a good place to start is the FAQ:
https://docs.readthedocs.org/en/latest/faq.html



Keep documenting,
Read the Docs
--
http://readthedocs.org

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

2015-10-05 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on TS-3956:


Github user bgaff commented on the pull request:

https://github.com/apache/trafficserver/pull/300#issuecomment-145743518
  
After looking into this, testing doesn't really make sense in a regression 
test so what i'll do is just drop in another source file called parser_tests.cc 
and have automake build that and link it to make check. I'll commit that when I 
land this.


> Header_rewrite applies strange logic with = operator and whitespace
> ---
>
> Key: TS-3956
> URL: https://issues.apache.org/jira/browse/TS-3956
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that whitespace causes weird behavior with header_rewrite, for 
> example:
> If you remove the white space before the = and the quotes it appears to 
> behave correctly. This whitespace issue is likely to cause strange bugs and 
> needs to be fixed.
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
> cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
> add-header X-HeaderRewriteApplied true
> {code}
> With the following request:
> {code}
> curl -v localhost/
> {code}
> Header_rewrite will incorrectly apply the rule:
> {code}
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Building 
> resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)  Adding 
> TXN client request header buffers
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: Host, field_loc: 0x7fffd02070d0
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Appending HEADER(Host) to evaluation value -> localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Test 
> regular expression ^localhost$ : localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Successfully found regular expression match
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER(): localhost - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: non_existent_header, field_loc: (nil)
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER():  - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> OperatorAddHeader::exec() invoked on header X-HeaderRewriteApplied: true
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)
> Adding header X-HeaderRewriteApplied
> {code}



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

Build failed in Jenkins: clang-analyzer #1471

2015-10-05 Thread jenkins

See 

Changes:

[James Peach] doc: fix some program references

[James Peach] doc: fix :arg: references

[James Peach] doc: websocket schemes are supported in remap.config

[Leif Hedstrom] Fix the docs link for storage.config

--
[...truncated 2382 lines...]
reading sources... [ 89%] 
sdk/http-hooks-and-transactions/intercepting-http-transactions.en
reading sources... [ 90%] sdk/http-transformation-plugin.en
reading sources... [ 90%] 
sdk/http-transformation-plugin/append-transform-plugin.en
reading sources... [ 90%] 
sdk/http-transformation-plugin/sample-buffered-null-transformation-plugin.en
reading sources... [ 90%] 
sdk/http-transformation-plugin/sample-null-transformation-plugin.en
reading sources... [ 91%] sdk/index.en
reading sources... [ 91%] sdk/io-guide.en
reading sources... [ 91%] sdk/io-guide/guide-to-cache-api.en
reading sources... [ 91%] sdk/io-guide/guide-to-cache-api/errors.en
reading sources... [ 92%] sdk/io-guide/guide-to-cache-api/example.en
reading sources... [ 92%] 
sdk/io-guide/guide-to-cache-api/how-to-do-a-cache-remove.en
reading sources... [ 92%] 
sdk/io-guide/guide-to-cache-api/how-to-do-a-cache-write.en
reading sources... [ 93%] sdk/io-guide/io-buffers.en
reading sources... [ 93%] sdk/io-guide/net-vconnections.en
reading sources... [ 93%] sdk/io-guide/transformations.en
reading sources... [ 93%] sdk/io-guide/vios.en
reading sources... [ 94%] sdk/misc-interface-guide.en
reading sources... [ 94%] sdk/misc-interface-guide/memory-allocation.en
reading sources... [ 94%] sdk/misc-interface-guide/thread-functions.en
reading sources... [ 95%] sdk/misc-interface-guide/tsfopen-family.en
reading sources... [ 95%] sdk/mutex-guide.en
reading sources... [ 95%] sdk/new-protocol-plugins.en
reading sources... [ 95%] sdk/plugin-configurations.en
reading sources... [ 96%] sdk/plugin-management.en
reading sources... [ 96%] sdk/plugin-management/guide-to-the-logging-api.en
reading sources... [ 96%] 
sdk/plugin-management/reading-trafficserver-settings-and-statistics.en
reading sources... [ 96%] sdk/preface.en
reading sources... [ 97%] sdk/preface/how-to-use-this-book.en
reading sources... [ 97%] sdk/preface/typographical-conventions.en
reading sources... [ 97%] sdk/remap-plugin.en
reading sources... [ 98%] sdk/remap-plugin/example-query-remap.en
reading sources... [ 98%] sdk/sample-source-code.en
reading sources... [ 98%] sdk/trafficserver-timers.en
reading sources... [ 98%] sdk/troubleshooting-tips.en
reading sources... [ 99%] sdk/troubleshooting-tips/debugging-memory-leaks.en
reading sources... [ 99%] sdk/troubleshooting-tips/unable-to-debug-tags.en
reading sources... [ 99%] sdk/troubleshooting-tips/unable-to-load-plugins.en
reading sources... [100%] sdk/troubleshooting-tips/using-a-debugger.en

:350:
 WARNING: malformed hyperlink target.
:26:
 WARNING: duplicate C object description of TSHttpTxnCacheLookupUrlGet, other 
instance in 

:45:
 WARNING: duplicate C object description of TSHttpTxnCacheLookupUrlSet, other 
instance in 

:2950:
 ERROR: Unknown interpreted text role "configfile".
:2955:
 ERROR: Unknown interpreted text role "configfile".
:63:
 WARNING: toctree contains reference to nonexisting document 
u'reference/plugins/Cache Promotion: provides additional control over when an 
object should be'
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
writing... TSAPI.3ts { } None:None: WARNING: c:data reference target not found: 
TS_EVENT_NONE
None:None: WARNING: c:data reference target not found: TS_EVENT_NONE
None:None: WARNING: c:data reference target not found: TS_VC_CLOSE_ABORT
None:None: WARNING: c:data reference target not found: TS_URL_SCHEME_FILE
None:None: WARNING: c:data reference target not found: TS_MIME_FIELD_ACCEPT
None:None: WARNING: u'file' reference target not found: 
{CONFIG_DIR}/plugin.config
None:None: WARNING: u'file' reference target not found: 
{CONFIG_DIR}/records.config
TSActionCancel.3ts { } TSActionDone.3ts { } TSCacheRead.3ts { } None:None: 
WARNING: c:data reference target

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

2015-10-05 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on TS-3956:


Github user jpeach commented on the pull request:

https://github.com/apache/trafficserver/pull/300#issuecomment-145649988
  
I think we need tests for this.


> Header_rewrite applies strange logic with = operator and whitespace
> ---
>
> Key: TS-3956
> URL: https://issues.apache.org/jira/browse/TS-3956
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that whitespace causes weird behavior with header_rewrite, for 
> example:
> If you remove the white space before the = and the quotes it appears to 
> behave correctly. This whitespace issue is likely to cause strange bugs and 
> needs to be fixed.
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
> cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
> add-header X-HeaderRewriteApplied true
> {code}
> With the following request:
> {code}
> curl -v localhost/
> {code}
> Header_rewrite will incorrectly apply the rule:
> {code}
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Building 
> resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)  Adding 
> TXN client request header buffers
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: Host, field_loc: 0x7fffd02070d0
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Appending HEADER(Host) to evaluation value -> localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Test 
> regular expression ^localhost$ : localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Successfully found regular expression match
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER(): localhost - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: non_existent_header, field_loc: (nil)
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER():  - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> OperatorAddHeader::exec() invoked on header X-HeaderRewriteApplied: true
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)
> Adding header X-HeaderRewriteApplied
> {code}



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

[jira] [Comment Edited] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

2015-10-05 Thread Brian Geffon (JIRA)


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

Brian Geffon edited comment on TS-3956 at 10/5/15 6:36 AM:
---

I have a proposed patch incoming it maintains backwards compatability while 
being a little more flexible with whitespace, for example the following config 
will parse as:

{code}
cond %{READ_REQUEST_HDR_HOOK}
cond %{CLIENT-HEADER:Host} /^localhost$/[AND]
   cond %{CLIENT-HEADER:Host}=a
 # COMMENT!
# COMMENT
   cond %{Client-HEADER:Foo} =b
   cond %{Client-HEADER:Blah}   =x
cond %{CLIENT-HEADER:non_existent_header} =  "shouldnt_   exist_anyway" 
 [AND]
cond %{CLIENT-HEADER:non_existent_header} =  "shouldnt_   =_anyway" 
 [AND]
cond %{CLIENT-HEADER:non_existent_header} ="="  [AND]
cond %{CLIENT-HEADER:non_existent_header} =""  [AND]
add-header X-HeaderRewriteApplied true
{code}

{code}
$1 = std::vector of length 2, capacity 2 = {"cond", "%{READ_REQUEST_HDR_HOOK}"}
$2 = std::vector of length 4, capacity 4 = {"cond", "%{CLIENT-HEADER:Host}", 
"/^localhost$/", "[AND]"}
$3 = std::vector of length 4, capacity 4 = {"cond", "%{CLIENT-HEADER:Host}", 
"=", "a"}
$4 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Foo}", 
"=", "b"}
$5 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Blah}", 
"=", "x"}
$6 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "shouldnt_   exist_anyway", 
"[AND]"}
$7 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "shouldnt_   =_anyway", 
"[AND]"}
$8 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "=", "[AND]"}
$9 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "", "[AND]"}
$10 = std::vector of length 3, capacity 4 = {"add-header", 
"X-HeaderRewriteApplied", "true"}
{code}


was (Author: briang):
I have a proposed patch incoming it maintains backwards compatability while 
being a little more flexible with whitespace, for example the following config 
will parse as:

{code}
cond %{READ_REQUEST_HDR_HOOK}
cond %{CLIENT-HEADER:Host} /^localhost$/[AND]
   cond %{CLIENT-HEADER:Host}=a
 # COMMENT!
# COMMENT
   cond %{Client-HEADER:Foo} =b
   cond %{Client-HEADER:Blah}   =x
cond %{CLIENT-HEADER:non_existent_header} =  "shouldnt_   exist_anyway" 
 [AND]
cond %{CLIENT-HEADER:non_existent_header} =  "shouldnt_   =_anyway" 
 [AND]
cond %{CLIENT-HEADER:non_existent_header} ="="  [AND]
cond %{CLIENT-HEADER:non_existent_header} =""  [AND]
add-header X-HeaderRewriteApplied true
{code}

{code}
$1 = std::vector of length 2, capacity 2 = {"cond", "%{READ_REQUEST_HDR_HOOK}"}
$2 = std::vector of length 4, capacity 4 = {"cond", "%{CLIENT-HEADER:Host}", 
"/^localhost$/", "[AND]"}
$3 = std::vector of length 4, capacity 4 = {"cond", "%{CLIENT-HEADER:Host}", 
"=", "a"}
$4 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Foo}", 
"=", "b"}
$5 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Blah}", 
"=", "x"}
$6 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "shouldnt_   exist_anyway", 
"[AND]"}
$8 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "=", "[AND]"}
$9 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "", "[AND]"}
$10 = std::vector of length 3, capacity 4 = {"add-header", 
"X-HeaderRewriteApplied", "true"}
{code}

> Header_rewrite applies strange logic with = operator and whitespace
> ---
>
> Key: TS-3956
> URL: https://issues.apache.org/jira/browse/TS-3956
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that whitespace causes weird behavior with header_rewrite, for 
> example:
> If you remove the white space before the = and the quotes it appears to 
> behave correctly. This whitespace issue is likely to cause strange bugs and 
> needs to be fixed.
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
> cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
> add-header X-HeaderRewriteApplied true
> {code}
> With the following request:
> {code}
> curl -v localhost/
> {code}
> Header_rewrite will incorrectly apply the rule:
> {code}
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Building 
> resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG:

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

2015-10-05 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on TS-3956:


GitHub user bgaff opened a pull request:

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

TS-3956: Header_rewrite applies strange logic with = operator

Please see ticket TS-3956 for more information, I'm using github here so 
that @zwoop / @jacksontj can provide a code review.

It appears that whitespace causes weird behavior with header_rewrite, for 
example:
If you remove the white space before the = and the quotes it appears to 
behave correctly. This whitespace issue is likely to cause strange bugs and 
needs to be fixed.

```
cond %{READ_REQUEST_HDR_HOOK}
cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
add-header X-HeaderRewriteApplied true
```
With the following request:

```
curl -v localhost/
```

Header_rewrite will incorrectly apply the rule:

```
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
Building resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)
Adding TXN client request header buffers
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
Getting Header: Host, field_loc: 0x7fffd02070d0
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
Appending HEADER(Host) to evaluation value -> localhost
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Test 
regular expression ^localhost$ : localhost
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
Successfully found regular expression match
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
Evaluating HEADER(): localhost - rval: 1
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
Getting Header: non_existent_header, field_loc: (nil)
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
Evaluating HEADER():  - rval: 1
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
OperatorAddHeader::exec() invoked on header X-HeaderRewriteApplied: true
[Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)
Adding header X-HeaderRewriteApplied
```
I have a proposed patch incoming it maintains backwards compatability while 
being a little more flexible with whitespace, for example the following config 
will parse as:

```
cond %{READ_REQUEST_HDR_HOOK}
cond %{CLIENT-HEADER:Host} /^localhost$/[AND]
   cond %{CLIENT-HEADER:Host}=a
 # COMMENT!
# COMMENT
   cond %{Client-HEADER:Foo} =b
   cond %{Client-HEADER:Blah}   =x
cond %{CLIENT-HEADER:non_existent_header} =  "shouldnt_   exist_anyway" 
 [AND]
cond %{CLIENT-HEADER:non_existent_header} =  "shouldnt_   =_anyway" 
 [AND]
cond %{CLIENT-HEADER:non_existent_header} ="="  [AND]
cond %{CLIENT-HEADER:non_existent_header} =""  [AND]
add-header X-HeaderRewriteApplied true
```

```
$1 = std::vector of length 2, capacity 2 = {"cond", 
"%{READ_REQUEST_HDR_HOOK}"}
$2 = std::vector of length 4, capacity 4 = {"cond", 
"%{CLIENT-HEADER:Host}", "/^localhost$/", "[AND]"}
$3 = std::vector of length 4, capacity 4 = {"cond", 
"%{CLIENT-HEADER:Host}", "=", "a"}
$4 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Foo}", 
"=", "b"}
$5 = std::vector of length 4, capacity 4 = {"cond", 
"%{Client-HEADER:Blah}", "=", "x"}
$6 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "shouldnt_   exist_anyway", 
"[AND]"}
$7 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "shouldnt_   =_anyway", 
"[AND]"}
$8 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "=", "[AND]"}
$9 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "", "[AND]"}
$10 = std::vector of length 3, capacity 4 = {"add-header", 
"X-HeaderRewriteApplied", "true"}
```

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

$ git pull https://github.com/bgaff/trafficserver master

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

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


commit bd3f2a8a3da46b0a4c59c5cb1a2509be9b02c0dd
Author: Brian Geffon 
Date:   2015-10-05T07:23:45Z

TS-3956:

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

2015-10-05 Thread Brian Geffon (JIRA)


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

Brian Geffon commented on TS-3956:
--

I have a proposed patch incoming it maintains backwards compatability while 
being a little more flexible with whitespace, for example the following config 
will parse as:

{code}
cond %{READ_REQUEST_HDR_HOOK}
cond %{CLIENT-HEADER:Host} /^localhost$/[AND]
   cond %{CLIENT-HEADER:Host}=a
 # COMMENT!
# COMMENT
   cond %{Client-HEADER:Foo} =b
   cond %{Client-HEADER:Blah}   =x
cond %{CLIENT-HEADER:non_existent_header} =  "shouldnt_   exist_anyway" 
 [AND]
add-header X-HeaderRewriteApplied true
{code}

{code}
$1 = std::vector of length 2, capacity 2 = {"cond", "%{READ_REQUEST_HDR_HOOK}"}
$2 = std::vector of length 4, capacity 4 = {"cond", "%{CLIENT-HEADER:Host}", 
"/^localhost$/", "[AND]"}
$3 = std::vector of length 4, capacity 4 = {"cond", "%{CLIENT-HEADER:Host}", 
"=", "a"}
$4 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Foo}", 
"=", "b"}
$5 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Blah}", 
"=", "x"}
$6 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "shouldnt_   exist_anyway", 
"[AND]"}
$7 = std::vector of length 3, capacity 4 = {"add-header", 
"X-HeaderRewriteApplied", "true"}
{code}

> Header_rewrite applies strange logic with = operator and whitespace
> ---
>
> Key: TS-3956
> URL: https://issues.apache.org/jira/browse/TS-3956
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that whitespace causes weird behavior with header_rewrite, for 
> example:
> If you remove the white space before the = and the quotes it appears to 
> behave correctly. This whitespace issue is likely to cause strange bugs and 
> needs to be fixed.
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
> cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
> add-header X-HeaderRewriteApplied true
> {code}
> With the following request:
> {code}
> curl -v localhost/
> {code}
> Header_rewrite will incorrectly apply the rule:
> {code}
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Building 
> resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)  Adding 
> TXN client request header buffers
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: Host, field_loc: 0x7fffd02070d0
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Appending HEADER(Host) to evaluation value -> localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Test 
> regular expression ^localhost$ : localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Successfully found regular expression match
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER(): localhost - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: non_existent_header, field_loc: (nil)
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER():  - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> OperatorAddHeader::exec() invoked on header X-HeaderRewriteApplied: true
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)
> Adding header X-HeaderRewriteApplied
> {code}



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

[jira] [Comment Edited] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

2015-10-05 Thread Brian Geffon (JIRA)


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

Brian Geffon edited comment on TS-3956 at 10/5/15 6:09 AM:
---

I have a proposed patch incoming it maintains backwards compatability while 
being a little more flexible with whitespace, for example the following config 
will parse as:

{code}
cond %{READ_REQUEST_HDR_HOOK}
cond %{CLIENT-HEADER:Host} /^localhost$/[AND]
   cond %{CLIENT-HEADER:Host}=a
 # COMMENT!
# COMMENT
   cond %{Client-HEADER:Foo} =b
   cond %{Client-HEADER:Blah}   =x
cond %{CLIENT-HEADER:non_existent_header} =  "shouldnt_   exist_anyway" 
 [AND]
cond %{CLIENT-HEADER:non_existent_header} =  "shouldnt_   =_anyway" 
 [AND]
cond %{CLIENT-HEADER:non_existent_header} ="="  [AND]
cond %{CLIENT-HEADER:non_existent_header} =""  [AND]
add-header X-HeaderRewriteApplied true
{code}

{code}
$1 = std::vector of length 2, capacity 2 = {"cond", "%{READ_REQUEST_HDR_HOOK}"}
$2 = std::vector of length 4, capacity 4 = {"cond", "%{CLIENT-HEADER:Host}", 
"/^localhost$/", "[AND]"}
$3 = std::vector of length 4, capacity 4 = {"cond", "%{CLIENT-HEADER:Host}", 
"=", "a"}
$4 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Foo}", 
"=", "b"}
$5 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Blah}", 
"=", "x"}
$6 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "shouldnt_   exist_anyway", 
"[AND]"}
$8 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "=", "[AND]"}
$9 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "", "[AND]"}
$10 = std::vector of length 3, capacity 4 = {"add-header", 
"X-HeaderRewriteApplied", "true"}
{code}


was (Author: briang):
I have a proposed patch incoming it maintains backwards compatability while 
being a little more flexible with whitespace, for example the following config 
will parse as:

{code}
cond %{READ_REQUEST_HDR_HOOK}
cond %{CLIENT-HEADER:Host} /^localhost$/[AND]
   cond %{CLIENT-HEADER:Host}=a
 # COMMENT!
# COMMENT
   cond %{Client-HEADER:Foo} =b
   cond %{Client-HEADER:Blah}   =x
cond %{CLIENT-HEADER:non_existent_header} =  "shouldnt_   exist_anyway" 
 [AND]
add-header X-HeaderRewriteApplied true
{code}

{code}
$1 = std::vector of length 2, capacity 2 = {"cond", "%{READ_REQUEST_HDR_HOOK}"}
$2 = std::vector of length 4, capacity 4 = {"cond", "%{CLIENT-HEADER:Host}", 
"/^localhost$/", "[AND]"}
$3 = std::vector of length 4, capacity 4 = {"cond", "%{CLIENT-HEADER:Host}", 
"=", "a"}
$4 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Foo}", 
"=", "b"}
$5 = std::vector of length 4, capacity 4 = {"cond", "%{Client-HEADER:Blah}", 
"=", "x"}
$6 = std::vector of length 5, capacity 8 = {"cond", 
"%{CLIENT-HEADER:non_existent_header}", "=", "shouldnt_   exist_anyway", 
"[AND]"}
$7 = std::vector of length 3, capacity 4 = {"add-header", 
"X-HeaderRewriteApplied", "true"}
{code}

> Header_rewrite applies strange logic with = operator and whitespace
> ---
>
> Key: TS-3956
> URL: https://issues.apache.org/jira/browse/TS-3956
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that whitespace causes weird behavior with header_rewrite, for 
> example:
> If you remove the white space before the = and the quotes it appears to 
> behave correctly. This whitespace issue is likely to cause strange bugs and 
> needs to be fixed.
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
> cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
> add-header X-HeaderRewriteApplied true
> {code}
> With the following request:
> {code}
> curl -v localhost/
> {code}
> Header_rewrite will incorrectly apply the rule:
> {code}
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Building 
> resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)  Adding 
> TXN client request header buffers
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: Host, field_loc: 0x7fffd02070d0
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Appending HEADER(Host) to evaluation value -> localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Test 
> regular expression ^localhost$ : localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Successfully found regular expression match
> [Oct  4 20:56:49.245]

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

2015-10-05 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on TS-3956:


Github user bgaff commented on the pull request:

https://github.com/apache/trafficserver/pull/300#issuecomment-145712386
  
@zwoop yah unit tests should be pretty easy to add.


> Header_rewrite applies strange logic with = operator and whitespace
> ---
>
> Key: TS-3956
> URL: https://issues.apache.org/jira/browse/TS-3956
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that whitespace causes weird behavior with header_rewrite, for 
> example:
> If you remove the white space before the = and the quotes it appears to 
> behave correctly. This whitespace issue is likely to cause strange bugs and 
> needs to be fixed.
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
> cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
> add-header X-HeaderRewriteApplied true
> {code}
> With the following request:
> {code}
> curl -v localhost/
> {code}
> Header_rewrite will incorrectly apply the rule:
> {code}
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Building 
> resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)  Adding 
> TXN client request header buffers
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: Host, field_loc: 0x7fffd02070d0
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Appending HEADER(Host) to evaluation value -> localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Test 
> regular expression ^localhost$ : localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Successfully found regular expression match
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER(): localhost - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: non_existent_header, field_loc: (nil)
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER():  - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> OperatorAddHeader::exec() invoked on header X-HeaderRewriteApplied: true
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)
> Adding header X-HeaderRewriteApplied
> {code}



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

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

2015-10-05 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on TS-3956:


Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/300#issuecomment-145669029
  
it ought to be possible to make a standalone test program, that exercises 
the config loading / parsing, without having to run as a plugin. Basically, 
something that runs as part of “make check” right ?


> Header_rewrite applies strange logic with = operator and whitespace
> ---
>
> Key: TS-3956
> URL: https://issues.apache.org/jira/browse/TS-3956
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that whitespace causes weird behavior with header_rewrite, for 
> example:
> If you remove the white space before the = and the quotes it appears to 
> behave correctly. This whitespace issue is likely to cause strange bugs and 
> needs to be fixed.
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
> cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
> add-header X-HeaderRewriteApplied true
> {code}
> With the following request:
> {code}
> curl -v localhost/
> {code}
> Header_rewrite will incorrectly apply the rule:
> {code}
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Building 
> resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)  Adding 
> TXN client request header buffers
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: Host, field_loc: 0x7fffd02070d0
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Appending HEADER(Host) to evaluation value -> localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Test 
> regular expression ^localhost$ : localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Successfully found regular expression match
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER(): localhost - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: non_existent_header, field_loc: (nil)
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER():  - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> OperatorAddHeader::exec() invoked on header X-HeaderRewriteApplied: true
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)
> Adding header X-HeaderRewriteApplied
> {code}



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

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

2015-10-05 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on TS-3956:


Github user PSUdaemon commented on the pull request:

https://github.com/apache/trafficserver/pull/300#issuecomment-145647206
  
This looks reasonable. I'm not surprised that the existing code is broken. 
I wrote it in a hurry to be able to remove Boost but I guess I didn't test 
variations with the spacing well enough. Can we have some tests for this? Seems 
like a good use case.


> Header_rewrite applies strange logic with = operator and whitespace
> ---
>
> Key: TS-3956
> URL: https://issues.apache.org/jira/browse/TS-3956
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that whitespace causes weird behavior with header_rewrite, for 
> example:
> If you remove the white space before the = and the quotes it appears to 
> behave correctly. This whitespace issue is likely to cause strange bugs and 
> needs to be fixed.
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
> cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
> add-header X-HeaderRewriteApplied true
> {code}
> With the following request:
> {code}
> curl -v localhost/
> {code}
> Header_rewrite will incorrectly apply the rule:
> {code}
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Building 
> resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)  Adding 
> TXN client request header buffers
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: Host, field_loc: 0x7fffd02070d0
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Appending HEADER(Host) to evaluation value -> localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Test 
> regular expression ^localhost$ : localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Successfully found regular expression match
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER(): localhost - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: non_existent_header, field_loc: (nil)
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER():  - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> OperatorAddHeader::exec() invoked on header X-HeaderRewriteApplied: true
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)
> Adding header X-HeaderRewriteApplied
> {code}



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

[jira] [Updated] (TS-3072) Debug logging for a single connection in production traffic.

2015-10-05 Thread Susan Hinrichs (JIRA)


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

Susan Hinrichs updated TS-3072:
---
Attachment: ts-3072.diff

Re-activating the discussion.  We recently deployed what [~sudheerv] suggested 
in production while tracking yet another tedious user-specific crash.  

I've attached the patch in ts-3072.diff.  It is a surprisingly small code 
change.  We changed how debug.enabled is interpreted to minimize the 
performance impact if one is not using the debug.client_ip feature.  The 
client-ip value is only tested if debug.enabled is set to 2.  Regular full 
debugging happens with debug.enabled set to 1.  Nothing is checked if 
debug.enabled is set to 0.

It was incredibly useful while tracking down our most recent fire.  We didn't 
have to anticipate the need for a plugin.  We were able to change the client_ip 
setting without restarting ATS.  

[~amc] has ideas for generalizing this technique to "taint" VC's for other more 
detailed tracking/debugging/monitoring.

> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>  Labels: Yahoo
> Fix For: sometime
>
> Attachments: ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



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

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

2015-10-05 Thread Sudheer Vinukonda (JIRA)


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

Sudheer Vinukonda commented on TS-3072:
---

Needless to say, I'm +1 on this feature being in the core with the ability to 
control with a simple config settings. The patch looks cool and simple and I 
love the fact that it will automatically output any new logs without having to 
make any additional changes.

> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>  Labels: Yahoo
> Fix For: sometime
>
> Attachments: ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



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

[jira] [Updated] (TS-3957) Core dump from SpdyClientSession::state_session_start

2015-10-05 Thread Susan Hinrichs (JIRA)


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

Susan Hinrichs updated TS-3957:
---
Labels: yahoo  (was: )

> Core dump from SpdyClientSession::state_session_start
> -
>
> Key: TS-3957
> URL: https://issues.apache.org/jira/browse/TS-3957
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Labels: yahoo
>
> We see this in production on machines under swap, so the timings are very 
> distorted.
> {code}
> gdb) bt
> #0  0x in ?? ()
> #1  0x0064a5dc in SpdyClientSession::state_session_start 
> (this=0x2b234fbe8030)
> at SpdyClientSession.cc:211
> #2  0x00510e34 in Continuation::handleEvent (this=0x2b234fbe8030, 
> event=1, 
> data=0x2b23eda76630) at ../iocore/eventsystem/I_Continuation.h:145
> #3  0x0079a066 in EThread::process_event (this=0x2b21170a2010, 
> e=0x2b23eda76630, 
> calling_code=1) at UnixEThread.cc:128
> #4  0x0079a234 in EThread::execute (this=0x2b21170a2010) at 
> UnixEThread.cc:179
> #5  0x00799611 in spawn_thread_internal (a=0x12226a0) at Thread.cc:85
> #6  0x2b21153e19d1 in start_thread () from /lib64/libpthread.so.0
> #7  0x003827ee88fd in clone () from /lib64/libc.so.6
> {code}
> After poking around on the core some more [~amc] and I determined that the vc 
> referenced by the SpdyClientSession was a freed object (the vtable pointer 
> was swizzled out to be the freelist next pointer).
> We assume that the swapping is causing very odd event timing.  We replaced 
> the schedule_immediate with a direct call that that seemed to solve our crash 
> in production.



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

Jenkins build is back to normal : tsqa-master #904

2015-10-05 Thread jenkins

See

[jira] [Created] (TS-3957) Core dump from SpdyClientSession::state_session_start

2015-10-05 Thread Susan Hinrichs (JIRA)

Susan Hinrichs created TS-3957:
--

 Summary: Core dump from SpdyClientSession::state_session_start
 Key: TS-3957
 URL: https://issues.apache.org/jira/browse/TS-3957
 Project: Traffic Server
  Issue Type: Bug
  Components: SPDY
Reporter: Susan Hinrichs


We see this in production on machines under swap, so the timings are very 
distorted.

{code}
gdb) bt
#0  0x in ?? ()
#1  0x0064a5dc in SpdyClientSession::state_session_start 
(this=0x2b234fbe8030)
at SpdyClientSession.cc:211
#2  0x00510e34 in Continuation::handleEvent (this=0x2b234fbe8030, 
event=1, 
data=0x2b23eda76630) at ../iocore/eventsystem/I_Continuation.h:145
#3  0x0079a066 in EThread::process_event (this=0x2b21170a2010, 
e=0x2b23eda76630, 
calling_code=1) at UnixEThread.cc:128
#4  0x0079a234 in EThread::execute (this=0x2b21170a2010) at 
UnixEThread.cc:179
#5  0x00799611 in spawn_thread_internal (a=0x12226a0) at Thread.cc:85
#6  0x2b21153e19d1 in start_thread () from /lib64/libpthread.so.0
#7  0x003827ee88fd in clone () from /lib64/libc.so.6
{code}

After poking around on the core some more [~amc] and I determined that the vc 
referenced by the SpdyClientSession was a freed object (the vtable pointer was 
swizzled out to be the freelist next pointer).

We assume that the swapping is causing very odd event timing.  We replaced the 
schedule_immediate with a direct call that that seemed to solve our crash in 
production.



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

[jira] [Assigned] (TS-3957) Core dump from SpdyClientSession::state_session_start

2015-10-05 Thread Susan Hinrichs (JIRA)


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

Susan Hinrichs reassigned TS-3957:
--

Assignee: Susan Hinrichs

> Core dump from SpdyClientSession::state_session_start
> -
>
> Key: TS-3957
> URL: https://issues.apache.org/jira/browse/TS-3957
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Labels: yahoo
>
> We see this in production on machines under swap, so the timings are very 
> distorted.
> {code}
> gdb) bt
> #0  0x in ?? ()
> #1  0x0064a5dc in SpdyClientSession::state_session_start 
> (this=0x2b234fbe8030)
> at SpdyClientSession.cc:211
> #2  0x00510e34 in Continuation::handleEvent (this=0x2b234fbe8030, 
> event=1, 
> data=0x2b23eda76630) at ../iocore/eventsystem/I_Continuation.h:145
> #3  0x0079a066 in EThread::process_event (this=0x2b21170a2010, 
> e=0x2b23eda76630, 
> calling_code=1) at UnixEThread.cc:128
> #4  0x0079a234 in EThread::execute (this=0x2b21170a2010) at 
> UnixEThread.cc:179
> #5  0x00799611 in spawn_thread_internal (a=0x12226a0) at Thread.cc:85
> #6  0x2b21153e19d1 in start_thread () from /lib64/libpthread.so.0
> #7  0x003827ee88fd in clone () from /lib64/libc.so.6
> {code}
> After poking around on the core some more [~amc] and I determined that the vc 
> referenced by the SpdyClientSession was a freed object (the vtable pointer 
> was swizzled out to be the freelist next pointer).
> We assume that the swapping is causing very odd event timing.  We replaced 
> the schedule_immediate with a direct call that that seemed to solve our crash 
> in production.



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

[jira] [Resolved] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized

2015-10-05 Thread Sudheer Vinukonda (JIRA)


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

Sudheer Vinukonda resolved TS-3952.
---
Resolution: Fixed

> SSLNetVConnection::free crashes when "nh" is not initialized
> 
>
> Key: TS-3952
> URL: https://issues.apache.org/jira/browse/TS-3952
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Sudheer Vinukonda
>
> On failure to making a connection, the *nh* is not init'ed in netVC and 
> ::free crashes on a null pointer.
>  
> Below's the backtrace:
> {code}
> (gdb) bt
> #0 0x006da394 in Queue UnixNetVConnection::Link_read_ready_link>::remove (this=0x38, 
> e=0x2b46c5b97e10) at ../../lib/ts/List.h:251
> #1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10, 
> t=0x2b456810) at SSLNetVConnection.cc:630
> #2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10, 
> t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
> #3 0x0073dbf8 in UnixNetProcessor::connect_re_internal 
> (this=0x1029960, cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870, 
> opt=0x2b456bc36de0, 
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at 
> UnixNetProcessor.cc:255
> #4 0x00521d23 in NetProcessor::connect_re (this=0x1029960, 
> cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0, 
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at 
> ../iocore/net/P_UnixNetProcessor.h:87
> #5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0, 
> raw=false) at HttpSM.cc:4759
> #6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7128
> #7 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at HttpSM.cc:2415
> #9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at HttpSM.cc:2522
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at 
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0, 
> url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320, 
> pin_in_cache=0, retry=true, 
> allow_multiple=false) at HttpCacheSM.cc:297
> #12 0x005da126 in HttpSM::do_cache_prepare_action 
> (this=0x2b4a5ca1c5c0, c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320, 
> retry=true, allow_multiple=false)
> at HttpSM.cc:4513
> #13 0x005e8850 in HttpSM::do_cache_prepare_write 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4434
> #14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7211
> #15 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #18 0x005db6c7 in HttpSM::do_api_callout_internal 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:437
> #20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:6979
> #21 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:3997
> #23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7078
> #24 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #27 0x005db6c7 in HttpSM::do_api_callout_internal 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:437
> #29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:6979
> #30 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #33 0x005db6c7 in HttpSM::do_api_callout_internal 
>

[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized

2015-10-05 Thread David Carlin (JIRA)


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

David Carlin updated TS-3952:
-
Labels: yahoo  (was: )

> SSLNetVConnection::free crashes when "nh" is not initialized
> 
>
> Key: TS-3952
> URL: https://issues.apache.org/jira/browse/TS-3952
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Sudheer Vinukonda
>  Labels: yahoo
>
> On failure to making a connection, the *nh* is not init'ed in netVC and 
> ::free crashes on a null pointer.
>  
> Below's the backtrace:
> {code}
> (gdb) bt
> #0 0x006da394 in Queue UnixNetVConnection::Link_read_ready_link>::remove (this=0x38, 
> e=0x2b46c5b97e10) at ../../lib/ts/List.h:251
> #1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10, 
> t=0x2b456810) at SSLNetVConnection.cc:630
> #2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10, 
> t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
> #3 0x0073dbf8 in UnixNetProcessor::connect_re_internal 
> (this=0x1029960, cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870, 
> opt=0x2b456bc36de0, 
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at 
> UnixNetProcessor.cc:255
> #4 0x00521d23 in NetProcessor::connect_re (this=0x1029960, 
> cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0, 
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at 
> ../iocore/net/P_UnixNetProcessor.h:87
> #5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0, 
> raw=false) at HttpSM.cc:4759
> #6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7128
> #7 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at HttpSM.cc:2415
> #9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at HttpSM.cc:2522
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at 
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0, 
> url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320, 
> pin_in_cache=0, retry=true, 
> allow_multiple=false) at HttpCacheSM.cc:297
> #12 0x005da126 in HttpSM::do_cache_prepare_action 
> (this=0x2b4a5ca1c5c0, c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320, 
> retry=true, allow_multiple=false)
> at HttpSM.cc:4513
> #13 0x005e8850 in HttpSM::do_cache_prepare_write 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4434
> #14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7211
> #15 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #18 0x005db6c7 in HttpSM::do_api_callout_internal 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:437
> #20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:6979
> #21 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:3997
> #23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7078
> #24 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #27 0x005db6c7 in HttpSM::do_api_callout_internal 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:437
> #29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:6979
> #30 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #33 0x005db6c7 in HttpSM::do_api_callout_internal

[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized

2015-10-05 Thread Sudheer Vinukonda (JIRA)


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

Sudheer Vinukonda updated TS-3952:
--
Fix Version/s: 6.1.0

> SSLNetVConnection::free crashes when "nh" is not initialized
> 
>
> Key: TS-3952
> URL: https://issues.apache.org/jira/browse/TS-3952
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Sudheer Vinukonda
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> On failure to making a connection, the *nh* is not init'ed in netVC and 
> ::free crashes on a null pointer.
>  
> Below's the backtrace:
> {code}
> (gdb) bt
> #0 0x006da394 in Queue UnixNetVConnection::Link_read_ready_link>::remove (this=0x38, 
> e=0x2b46c5b97e10) at ../../lib/ts/List.h:251
> #1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10, 
> t=0x2b456810) at SSLNetVConnection.cc:630
> #2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10, 
> t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
> #3 0x0073dbf8 in UnixNetProcessor::connect_re_internal 
> (this=0x1029960, cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870, 
> opt=0x2b456bc36de0, 
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at 
> UnixNetProcessor.cc:255
> #4 0x00521d23 in NetProcessor::connect_re (this=0x1029960, 
> cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0, 
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at 
> ../iocore/net/P_UnixNetProcessor.h:87
> #5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0, 
> raw=false) at HttpSM.cc:4759
> #6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7128
> #7 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at HttpSM.cc:2415
> #9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at HttpSM.cc:2522
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at 
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0, 
> url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320, 
> pin_in_cache=0, retry=true, 
> allow_multiple=false) at HttpCacheSM.cc:297
> #12 0x005da126 in HttpSM::do_cache_prepare_action 
> (this=0x2b4a5ca1c5c0, c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320, 
> retry=true, allow_multiple=false)
> at HttpSM.cc:4513
> #13 0x005e8850 in HttpSM::do_cache_prepare_write 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4434
> #14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7211
> #15 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #18 0x005db6c7 in HttpSM::do_api_callout_internal 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:437
> #20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:6979
> #21 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:3997
> #23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7078
> #24 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #27 0x005db6c7 in HttpSM::do_api_callout_internal 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:437
> #29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:6979
> #30 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #33

[jira] [Commented] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized

2015-10-05 Thread ASF subversion and git services (JIRA)


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

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

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

[TS-3952] dummy commit to fix the wrong jira in commit 
b9df2ebd69bd132d23df4c34ab62f3a139f2f4ad


> SSLNetVConnection::free crashes when "nh" is not initialized
> 
>
> Key: TS-3952
> URL: https://issues.apache.org/jira/browse/TS-3952
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Sudheer Vinukonda
>
> On failure to making a connection, the *nh* is not init'ed in netVC and 
> ::free crashes on a null pointer.
>  
> Below's the backtrace:
> {code}
> (gdb) bt
> #0 0x006da394 in Queue UnixNetVConnection::Link_read_ready_link>::remove (this=0x38, 
> e=0x2b46c5b97e10) at ../../lib/ts/List.h:251
> #1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10, 
> t=0x2b456810) at SSLNetVConnection.cc:630
> #2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10, 
> t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
> #3 0x0073dbf8 in UnixNetProcessor::connect_re_internal 
> (this=0x1029960, cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870, 
> opt=0x2b456bc36de0, 
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at 
> UnixNetProcessor.cc:255
> #4 0x00521d23 in NetProcessor::connect_re (this=0x1029960, 
> cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0, 
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at 
> ../iocore/net/P_UnixNetProcessor.h:87
> #5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0, 
> raw=false) at HttpSM.cc:4759
> #6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7128
> #7 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at HttpSM.cc:2415
> #9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at HttpSM.cc:2522
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at 
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0, 
> url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320, 
> pin_in_cache=0, retry=true, 
> allow_multiple=false) at HttpCacheSM.cc:297
> #12 0x005da126 in HttpSM::do_cache_prepare_action 
> (this=0x2b4a5ca1c5c0, c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320, 
> retry=true, allow_multiple=false)
> at HttpSM.cc:4513
> #13 0x005e8850 in HttpSM::do_cache_prepare_write 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4434
> #14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7211
> #15 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #18 0x005db6c7 in HttpSM::do_api_callout_internal 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:437
> #20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:6979
> #21 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:3997
> #23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7078
> #24 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #27 0x005db6c7 in HttpSM::do_api_callout_internal 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:437
> #29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:6979
> #30 0x005e2178 in HttpSM::call_transact_and_set_next_state 
>

[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized

2015-10-05 Thread Sudheer Vinukonda (JIRA)


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

Sudheer Vinukonda updated TS-3952:
--
Backport to Version: 6.0.0

> SSLNetVConnection::free crashes when "nh" is not initialized
> 
>
> Key: TS-3952
> URL: https://issues.apache.org/jira/browse/TS-3952
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Sudheer Vinukonda
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> On failure to making a connection, the *nh* is not init'ed in netVC and 
> ::free crashes on a null pointer.
>  
> Below's the backtrace:
> {code}
> (gdb) bt
> #0 0x006da394 in Queue UnixNetVConnection::Link_read_ready_link>::remove (this=0x38, 
> e=0x2b46c5b97e10) at ../../lib/ts/List.h:251
> #1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10, 
> t=0x2b456810) at SSLNetVConnection.cc:630
> #2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10, 
> t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
> #3 0x0073dbf8 in UnixNetProcessor::connect_re_internal 
> (this=0x1029960, cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870, 
> opt=0x2b456bc36de0, 
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at 
> UnixNetProcessor.cc:255
> #4 0x00521d23 in NetProcessor::connect_re (this=0x1029960, 
> cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0, 
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at 
> ../iocore/net/P_UnixNetProcessor.h:87
> #5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0, 
> raw=false) at HttpSM.cc:4759
> #6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7128
> #7 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at HttpSM.cc:2415
> #9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at HttpSM.cc:2522
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0, 
> event=1109, data=0xb04f) at 
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0, 
> url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320, 
> pin_in_cache=0, retry=true, 
> allow_multiple=false) at HttpCacheSM.cc:297
> #12 0x005da126 in HttpSM::do_cache_prepare_action 
> (this=0x2b4a5ca1c5c0, c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320, 
> retry=true, allow_multiple=false)
> at HttpSM.cc:4513
> #13 0x005e8850 in HttpSM::do_cache_prepare_write 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4434
> #14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7211
> #15 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #18 0x005db6c7 in HttpSM::do_api_callout_internal 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:437
> #20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:6979
> #21 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:3997
> #23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:7078
> #24 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #27 0x005db6c7 in HttpSM::do_api_callout_internal 
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:437
> #29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:6979
> #30 0x005e2178 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at 
> HttpSM.cc:1502
> #32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0, 
> event=0, data=0x0) at HttpSM.cc:1438
> #33

[jira] [Updated] (TS-315) Add switch to disable config file generation/runtime behavior changing

2015-10-05 Thread Susan Hinrichs (JIRA)


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

Susan Hinrichs updated TS-315:
--
Labels: A yahoo  (was: A)

> Add switch to disable config file generation/runtime behavior changing
> --
>
> Key: TS-315
> URL: https://issues.apache.org/jira/browse/TS-315
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Miles Libbey
>Assignee: Bryan Call
>Priority: Minor
>  Labels: A, yahoo
> Fix For: sometime
>
>
> (was yahoo bug 1863676)
> Original description
> by Michael S. Fischer  2 years ago at 2008-04-09 09:52
> In production, in order to improve site stability, it is imperative that TS 
> never accidentally overwrite its own
> configuration files.  
> For this reason, we'd like to request a switch be added to TS, preferably via 
> the command line, that disables all
> automatic configuration file generation or other  runtime behavioral changes 
> initiated by any form of IPC other than
> 'traffic_line -x'  (including the web interface, etc.)
>   
>  
> Comment 1
>  by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17
> A very crucial request, in my opinion. If TS needs to be able to read 
> command-line config changes on the fly, these
> changes should be stored in another config file (for example 
> remap.config.local instead of remap.config). We have a
> patch config package that overwrites 4 of the config files under 
> /home/conf/ts/, and with all packages 
> we'd like to think that the content of these files can't change outside our 
> control.
>
> Comment 2
>  by Bryan Call  2 years ago at 2008-04-09 11:02:46
> traffic_line -x doesn't modify the configuration, it reloads the 
> configuration files.  If we want to have an option for
> this it would be good to have it as an option configuration file (CONFIG 
> proxy.config.write_protect INT 1).
> It would be an equivalent of write protecting floppies (ahh the memories)...
>   
>  
> Comment 3
>  by Michael S. Fischer  2 years ago at 2008-04-09 11:09:09
> I don't think it would be a good idea to have this in the configuration file, 
> as it would introduce a chicken/egg
> problem.
>   
>  
> Comment 4
>  by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17
> So I'm not 100% positive that this isn't just a bad interaction. Now, it's 
> only
> triggered when trafficserver is running, but usually what ends up happening 
> is that we get a records.config which
> looks like it's the default config that comes with the trafficserver package.
> It's possible it's all one and the same issue, or we might have two issues.
>   



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

[jira] [Updated] (TS-3901) Leaking connections from HttpSessionManager

2015-10-05 Thread Susan Hinrichs (JIRA)


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

Susan Hinrichs updated TS-3901:
---
Attachment: ts-3901.diff

ts-3901.diff contains the changes that we have been running in production that 
seem to have eliminated the crash.

> Leaking connections from HttpSessionManager
> ---
>
> Key: TS-3901
> URL: https://issues.apache.org/jira/browse/TS-3901
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3901.diff
>
>
> Observed in production.  Got the following warnings in diags.log
> "Connection leak from http keep-alive system"
> Our connections to origin would increase and the number of connections in 
> CLOSE_WAIT were enormous.
> I think the issue was when the origin URL was http with default port.  That 
> URL was remapped to https with default port.  The default port stored in 
> HttpServerSession->server_ip was not updated.  
> When the connection was closed or timed out of the session pool, it would be 
> looked up with port 443.   But the session was stored via the server_ip value 
> with port 80 and would never match.
> Relatively small change in HTTPHdr::_file_target_cache. 
> Running the fix in production to verify early results.



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

Build failed in Jenkins: tsqa-master #906

Jenkins build is back to normal : tsqa-master #907

Build failed in Jenkins: clang-analyzer #1469

[jira] [Commented] (TS-3901) Leaking connections from HttpSessionManager

Build failed in Jenkins: clang-analyzer #1470

[jira] [Commented] (TS-315) Add switch to disable config file generation/runtime behavior changing

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

Failed: trafficserver (9d4da597)

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

Build failed in Jenkins: clang-analyzer #1471

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

[jira] [Comment Edited] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

[jira] [Comment Edited] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

[jira] [Commented] (TS-3956) Header_rewrite applies strange logic with = operator and whitespace

[jira] [Updated] (TS-3072) Debug logging for a single connection in production traffic.

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[jira] [Updated] (TS-3957) Core dump from SpdyClientSession::state_session_start

Jenkins build is back to normal : tsqa-master #904

[jira] [Created] (TS-3957) Core dump from SpdyClientSession::state_session_start

[jira] [Assigned] (TS-3957) Core dump from SpdyClientSession::state_session_start

[jira] [Resolved] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized

[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized

[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized

[jira] [Commented] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized

[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized

[jira] [Updated] (TS-315) Add switch to disable config file generation/runtime behavior changing

[jira] [Updated] (TS-3901) Leaking connections from HttpSessionManager

32 matches

Site Navigation

Mail list logo

Footer information