[jira] [Commented] (TS-856) ATS doesn't build on Solaris Studio 12.2 in 32 bit mode

2011-07-13 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/TS-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064483#comment-13064483
 ] 

Igor Galić commented on TS-856:
---

{noformat}
@postwait jMCg: the code changes look fine
@postwait the configure.ac does not
@postwait putting /usr/local/include in the CPPFLAGS isn't something we 
should be doing -- the build should:
@postwait CPPFLAGS=-I/usr/local/include ./configure 
@postwait Also, the other configure.ac change would have the build _default_ 
to 32 bit.
@postwait Solaris doesn't really even run on 32 bit anymore.
@postwait ZFS has trouble and all of the 32bit ZFS bugs files are being 
ignored.
@postwait Sun (and now Oracle) are treating 32bit as a dead platform.
@postwait So, at the very least we should defaul to a 64bit build.
{noformat}

I disagree with the 32/64 part. We are not defaulting to 32bit. We are 
defaulting to what the user specifies in CFLAGS or in CC.

 ATS doesn't build on Solaris Studio 12.2 in 32 bit mode
 ---

 Key: TS-856
 URL: https://issues.apache.org/jira/browse/TS-856
 Project: Traffic Server
  Issue Type: Bug
  Components: Build, DNS
Affects Versions: 3.1.0, 3.0.0
 Environment: Solaris 10, x86, Solaris Studio 12.2
Reporter: Igor Galić
 Fix For: 3.1.0

 Attachments: sunpro12.2-32bit.patch


 Because our build system automatically adds -m64 on Solaris/SunPro, we're 
 unable to compile Traffic Server in 32bit mode: This is necessary because 
 some libraries simply aren't available in 64bit.
 I've created a patch to alter this behaviour, except now it cannot link 
 traffic_server:
 {noformat}
 gmake[2]: Entering directory 
 `/buildr/mgar/pkg/trafficserver/trunk/work/build-isa-i386/trafficserver-3.0.0/proxy'
 /bin/bash ../libtool --tag=CXX   --mode=link /opt/solstudio12.2/bin/CC -m32  
 -xO3 -g -mt -library=stlport4 -erroff -R/opt/csw/lib -L/opt/csw/lib -L/lib 
 -L/usr/local/lib -o traffic_server AbstractBuffer.o CacheControl.o 
 ProxyConfig.o ControlBase.o ControlMatcher.o CoreUtils.o DiagsConfig.o 
 Error.o EventName.o ICP.o ICPConfig.o ICPProcessor.o ICPStats.o InkAPI.o 
 FetchSM.o InkIOCoreAPI.o InkXml.o IPAllow.o Main.o ParentSelection.o Plugin.o 
 PluginDB.o PluginVC.o Prefetch.o ReverseProxy.o signals.o SocksProxy.o 
 StatPages.o StatSystem.o Transform.o Update.o InkAPITest.o RegressionSM.o 
 TestHook.o http/libhttp.a http/remap/libhttp_remap.a 
 congest/libCongestionControl.a logging/liblogging.a logging/liblogcollation.a 
 stats/libstats.a hdrs/libhdrs.a ../mgmt/preparse/libpreparse.a 
 ../mgmt/utils/libutils_p.a ../mgmt/libmgmt_p.a ../iocore/utils/libinkutils.a 
 ../iocore/cluster/libinkcluster.a ../iocore/dns/libinkdns.a 
 ../iocore/hostdb/libinkhostdb.a ../iocore/dns/libinkdns.a 
 ../iocore/cluster/libinkcluster.a ../iocore/cache/libinkcache.a 
 ../iocore/aio/libinkaio.a ../iocore/net/libinknet.a 
 ../iocore/eventsystem/libinkevent.a ../lib/records/librecprocess.a 
 ../iocore/eventsystem/libinkevent.a ../lib/ts/libtsutil.la -lpthread -lsocket 
 -lnsl -lresolv -lposix4 -lpcre -lssl -lcrypto -L/opt/csw/lib -ltcl8.4 -ldl 
 -lexpat -ldemangle -liconv -lm-lz
 libtool: link: /opt/solstudio12.2/bin/CC -m32 -xO3 -g -mt -erroff -o 
 .libs/traffic_server AbstractBuffer.o CacheControl.o ProxyConfig.o 
 ControlBase.o ControlMatcher.o CoreUtils.o DiagsConfig.o Error.o EventName.o 
 ICP.o ICPConfig.o ICPProcessor.o ICPStats.o InkAPI.o FetchSM.o InkIOCoreAPI.o 
 InkXml.o IPAllow.o Main.o ParentSelection.o Plugin.o PluginDB.o PluginVC.o 
 Prefetch.o ReverseProxy.o signals.o SocksProxy.o StatPages.o StatSystem.o 
 Transform.o Update.o InkAPITest.o RegressionSM.o TestHook.o  -L/opt/csw/lib 
 -L/lib -L/usr/local/lib http/libhttp.a http/remap/libhttp_remap.a 
 congest/libCongestionControl.a logging/liblogging.a logging/liblogcollation.a 
 stats/libstats.a hdrs/libhdrs.a ../mgmt/preparse/libpreparse.a 
 ../mgmt/utils/libutils_p.a ../mgmt/libmgmt_p.a ../iocore/utils/libinkutils.a 
 ../iocore/hostdb/libinkhostdb.a ../iocore/dns/libinkdns.a 
 ../iocore/cluster/libinkcluster.a ../iocore/cache/libinkcache.a 
 ../iocore/aio/libinkaio.a ../iocore/net/libinknet.a 
 ../lib/records/librecprocess.a ../iocore/eventsystem/libinkevent.a 
 ../lib/ts/.libs/libtsutil.so -library=stlport4 -lc -lpthread -lsocket -lnsl 
 -lresolv -lposix4 -lpcre -lssl -lcrypto -ltcl8.4 -ldl -lexpat -ldemangle 
 -liconv -lm -lz -mt -R/opt/csw/lib
 Undefined   first referenced
  symbol in file
 int ink_res_mkquery(__ink_res_state*,int,const char*,int,int,const unsigned 
 char*,int,const unsigned char*,unsigned char*,int) 
 ../iocore/dns/libinkdns.a(DNS.o)
 ld: fatal: Symbol referencing errors. No output written to 
 .libs/traffic_server
 gmake[2]: *** [traffic_server] Error 2
 gmake[2]: Leaving directory

[jira] [Commented] (TS-872) ATS 3.0 shows a http 502 error as a forward proxy server ！

2011-07-13 Thread taoyunxing (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064514#comment-13064514
 ] 

taoyunxing commented on TS-872:
---

I make a fresh operation including config,make and install, and a little revise 
in records.config as forward proxy,  then open the web pages successfully. 
Maybe I make some mistakes last time. thanks Leif, the ATS 3.0 is good! this is 
not a bug!

 ATS 3.0 shows a http 502 error as a forward proxy server ！
 --

 Key: TS-872
 URL: https://issues.apache.org/jira/browse/TS-872
 Project: Traffic Server
  Issue Type: Bug
  Components: DNS
Affects Versions: 3.0.0
 Environment: OS: Ubuntu 10.10, Traffic Server version:.3.0, Web 
 Browser：firefox 4.0.1，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 
 500G
Reporter: taoyunxing
  Labels: patch
 Fix For: sometime

   Original Estimate: 48h
  Remaining Estimate: 48h

 when I set up a forward proxy with ATS 3.0 and firefox 4.0.1 and start the 
 proxy server as a root, it shows me the following info:
 root@tyx-System-Product-Name:/usr/local/bin# ./traffic_server 
 [TrafficServer] using root directory '/usr/local'
 [Jul  6 08:56:36.765] {3077691088} STATUS: opened 
 /usr/local/var/log/trafficserver/diags.log
 [Jul  6 08:56:36.765] {3077691088} NOTE: updated diags config
 [Jul  6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua) 
 [HttpConfig::init_aeua_filter] - Config: 
 /usr/local/etc/trafficserver/ae_ua.config
 [Jul  6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua) 
 [HttpConfig::init_aeua_filter] - Opening config 
 /usr/local/etc/trafficserver/ae_ua.config
 [Jul  6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua) 
 [HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
 [Jul  6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua) 
 [init_http_aeua_filter] - Total loaded 0 REGEXP for 
 Accept-Enconding/User-Agent filtering
 [Jul  6 08:56:36.768] Server {3077691088} NOTE: cache clustering disabled
 [Jul  6 08:56:36.768] Server {3077691088} NOTE: clearing statistics
 [Jul  6 08:56:36.770] Server {3077691088} DEBUG: (dns) ink_dns_init: called 
 with init_called = 0
 [Jul  6 08:56:36.779] Server {3077691088} DEBUG: (dns) 
 localhost=tyx-System-Product-Name
 [Jul  6 08:56:36.779] Server {3077691088} DEBUG: (dns) Round-robin 
 nameservers = 0
 [Jul  6 08:56:36.779] Server {3077691088} DEBUG: (hostdb) Storage path is 
 /usr/local/var/trafficserver
 [Jul  6 08:56:36.779] Server {3077691088} DEBUG: (hostdb) Opening host.db, 
 size=20
 [Jul  6 08:56:36.779] Server {3077691088} WARNING: configuration changed: 
 [hostdb.config] : reinitializing database
 [Jul  6 08:56:36.779] Server {3077691088} NOTE: reconfiguring host database
 [Jul  6 08:56:36.779] Server {3077691088} DEBUG: (hostdb) unable to unlink 
 /usr/local/etc/trafficserver/internal/hostdb.config
 [Jul  6 08:56:36.779] Server {3077691088} WARNING: Configured store too 
 small, unable to reconfigure
 [Jul  6 08:56:36.779] Server {3077691088} WARNING: unable to initialize 
 database (too little storage)
 : [hostdb.config] : disabling database
 You may need to 'reconfigure' your cache manually.  Please refer to
 the 'Configuration' chapter in the manual.
 [Jul  6 08:56:36.779] Server {3077691088} WARNING: could not initialize host 
 database. Host database will be disabled
 [Jul  6 08:56:36.779] Server {3077691088} WARNING: bad hostdb or storage 
 configuration, hostdb disabled
 [Jul  6 08:56:36.780] Server {3077691088} NOTE: cache clustering disabled
 [Jul  6 08:56:36.834] Server {3057408880} WARNING: disk header different for 
 disk /usr/local/var/trafficserver/cache.db: clearing the disk
 [Jul  6 08:56:36.884] Server {3077691088} NOTE: logging initialized[7], 
 logging_mode = 3
 [Jul  6 08:56:36.887] Server {3077691088} DEBUG: (http_init) 
 proxy.config.http.redirection_enabled = 0
 [Jul  6 08:56:36.887] Server {3077691088} DEBUG: (http_init) 
 proxy.config.http.number_of_redirections = 1
 [Jul  6 08:56:36.887] Server {3077691088} DEBUG: (http_init) 
 proxy.config.http.post_copy_size = 2048
 [Jul  6 08:56:36.887] Server {3077691088} DEBUG: (http_tproxy) Primary listen 
 socket transparency is off
 [Jul  6 08:56:36.890] Server {3077691088} NOTE: traffic server running
 [Jul  6 08:56:36.890] Server {3077691088} DEBUG: (dns) 
 DNSHandler::startEvent: on thread 0
 [Jul  6 08:56:36.890] Server {3077691088} DEBUG: (dns) open_con: opening 
 connection 8.8.8.8:53
 [Jul  6 08:56:36.890] Server {3077691088} DEBUG: (dns) random port = 42595
 [Jul  6 08:56:36.890] Server {3077691088} DEBUG: (dns) opening connection 
 8.8.8.8:53 SUCCEEDED for 0
 [Jul  6 08:56:36.918] Server {3058461552} NOTE: Clearing Disk: 
 /usr/local/var/trafficserver/cache.db
 [Jul  6 08:56:36.919] Server {3058461552} NOTE: clearing cache

[jira] [Created] (TS-875) TSFetchRestpGet(), TSFetchPageResptGet() and TSFetchUrl() have incorrect asserts

2011-07-13 Thread Manjesh Nilange (JIRA) 
TSFetchRestpGet(), TSFetchPageResptGet() and TSFetchUrl() have incorrect asserts


 Key: TS-875
 URL: https://issues.apache.org/jira/browse/TS-875
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange


The asserts cause TS to crash when these API functions are used. The asserts 
are incorrect as argument 'txnp' is actually not a transaction, but a FetchSM 
pointer as apparent in the code that follows.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-875) TSFetchRestpGet(), TSFetchPageResptGet() and TSFetchUrl() have incorrect asserts

2011-07-13 Thread Manjesh Nilange (JIRA) 

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

Manjesh Nilange updated TS-875:
---

Attachment: inkapi.patch

Patch for InkAPI.cc

 TSFetchRestpGet(), TSFetchPageResptGet() and TSFetchUrl() have incorrect 
 asserts
 

 Key: TS-875
 URL: https://issues.apache.org/jira/browse/TS-875
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
 Attachments: inkapi.patch


 The asserts cause TS to crash when these API functions are used. The asserts 
 are incorrect as argument 'txnp' is actually not a transaction, but a FetchSM 
 pointer as apparent in the code that follows.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-875) TSFetchRestpGet(), TSFetchPageResptGet() and TSFetchUrl() have incorrect asserts

2011-07-13 Thread Manjesh Nilange (JIRA) 

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

Manjesh Nilange updated TS-875:
---

Description: 
The asserts cause TS to crash when these API functions are used. The asserts 
are incorrect as argument 'txnp' is actually not a transaction, but a FetchSM 
pointer as apparent in the code that follows.

And TSFetchUrl allows continuations to make requests with no callbacks and for 
such code paths, the continuation check should not be done.

  was:The asserts cause TS to crash when these API functions are used. The 
asserts are incorrect as argument 'txnp' is actually not a transaction, but a 
FetchSM pointer as apparent in the code that follows.


 TSFetchRestpGet(), TSFetchPageResptGet() and TSFetchUrl() have incorrect 
 asserts
 

 Key: TS-875
 URL: https://issues.apache.org/jira/browse/TS-875
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
 Attachments: inkapi.patch


 The asserts cause TS to crash when these API functions are used. The asserts 
 are incorrect as argument 'txnp' is actually not a transaction, but a FetchSM 
 pointer as apparent in the code that follows.
 And TSFetchUrl allows continuations to make requests with no callbacks and 
 for such code paths, the continuation check should not be done.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TS-876) forward map based on request receive port

2011-07-13 Thread Manjesh Nilange (JIRA) 
forward map based on request receive port
-

 Key: TS-876
 URL: https://issues.apache.org/jira/browse/TS-876
 Project: Traffic Server
  Issue Type: New Feature
  Components: Remap API
Reporter: Manjesh Nilange


Currently the port in the from fields of all remap rules are compared against 
the port in the request (explicitly in the request or implicitly deduced from 
the protocol). TS supports listening on multiple ports, so there is a use case 
for a remap rule that uses the TS port at which the request is received instead 
of the request port.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-876) forward map based on request receive port

2011-07-13 Thread Manjesh Nilange (JIRA) 

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

Manjesh Nilange updated TS-876:
---

Attachment: map_with_recv_port.patch

This patch introduces a new forward map directive - 'map_with_recv_port'. The 
regex qualifier can be applied to this mapping as well.

 forward map based on request receive port
 -

 Key: TS-876
 URL: https://issues.apache.org/jira/browse/TS-876
 Project: Traffic Server
  Issue Type: New Feature
  Components: Remap API
Reporter: Manjesh Nilange
 Attachments: map_with_recv_port.patch


 Currently the port in the from fields of all remap rules are compared 
 against the port in the request (explicitly in the request or implicitly 
 deduced from the protocol). TS supports listening on multiple ports, so there 
 is a use case for a remap rule that uses the TS port at which the request is 
 received instead of the request port.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-875) TSFetchRestpGet(), TSFetchPageResptGet() and TSFetchUrl() have incorrect asserts

2011-07-13 Thread Manjesh Nilange (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064808#comment-13064808
 ] 

Manjesh Nilange commented on TS-875:


Yeah, ideally they should be a different data type.

P.S. As of now, I don't have enough bandwidth to be an active committer and I 
don't want to be a passive committer again. That's why I'm contributing via 
this route. Let's see, maybe in the future that may change.



 TSFetchRestpGet(), TSFetchPageResptGet() and TSFetchUrl() have incorrect 
 asserts
 

 Key: TS-875
 URL: https://issues.apache.org/jira/browse/TS-875
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
 Attachments: inkapi.patch


 The asserts cause TS to crash when these API functions are used. The asserts 
 are incorrect as argument 'txnp' is actually not a transaction, but a FetchSM 
 pointer as apparent in the code that follows.
 And TSFetchUrl allows continuations to make requests with no callbacks and 
 for such code paths, the continuation check should not be done.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-853) Plugin examples should be updated to use the sockaddr API instead of the deprecated int style API.

2011-07-13 Thread Leif Hedstrom (JIRA) 

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

Leif Hedstrom resolved TS-853.
--

Resolution: Fixed

 Plugin examples should be updated to use the sockaddr API instead of the 
 deprecated int style API.
 --

 Key: TS-853
 URL: https://issues.apache.org/jira/browse/TS-853
 Project: Traffic Server
  Issue Type: Task
  Components: Plugins
Affects Versions: 3.0.0
Reporter: Alan M. Carroll
Assignee: Leif Hedstrom
Priority: Minor
 Fix For: 3.1.0


 For 3.0 the IP address related API was changed to use sockaddr instead of int 
 for IP addresses in preparation for IPv6 compatibility. The old functions 
 were marked deprecated. The example plugins should use the sockaddr interface 
 and not the deprecated interface.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-876) forward map based on request receive port

2011-07-13 Thread Leif Hedstrom (JIRA) 

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

Leif Hedstrom updated TS-876:
-

Fix Version/s: 3.1.0
 Assignee: Leif Hedstrom

 forward map based on request receive port
 -

 Key: TS-876
 URL: https://issues.apache.org/jira/browse/TS-876
 Project: Traffic Server
  Issue Type: New Feature
  Components: Remap API
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
 Fix For: 3.1.0

 Attachments: map_with_recv_port.patch


 Currently the port in the from fields of all remap rules are compared 
 against the port in the request (explicitly in the request or implicitly 
 deduced from the protocol). TS supports listening on multiple ports, so there 
 is a use case for a remap rule that uses the TS port at which the request is 
 received instead of the request port.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-875) TSFetchRestpGet(), TSFetchPageResptGet() and TSFetchUrl() have incorrect asserts

2011-07-13 Thread Leif Hedstrom (JIRA) 

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

Leif Hedstrom updated TS-875:
-

Backport to Version: 3.0.1
  Fix Version/s: 3.1.0
   Assignee: Leif Hedstrom

 TSFetchRestpGet(), TSFetchPageResptGet() and TSFetchUrl() have incorrect 
 asserts
 

 Key: TS-875
 URL: https://issues.apache.org/jira/browse/TS-875
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
 Fix For: 3.1.0

 Attachments: inkapi.patch


 The asserts cause TS to crash when these API functions are used. The asserts 
 are incorrect as argument 'txnp' is actually not a transaction, but a FetchSM 
 pointer as apparent in the code that follows.
 And TSFetchUrl allows continuations to make requests with no callbacks and 
 for such code paths, the continuation check should not be done.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-876) forward map based on request receive port

2011-07-13 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064824#comment-13064824
 ] 

Leif Hedstrom commented on TS-876:
--

Quick nit-picky comment: remap.config is not the source file, they were all 
renamed to .default, e.g. remap.config.default. Would you mind producing a 
patch with that fixed, just for clarity?

 forward map based on request receive port
 -

 Key: TS-876
 URL: https://issues.apache.org/jira/browse/TS-876
 Project: Traffic Server
  Issue Type: New Feature
  Components: Remap API
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
 Fix For: 3.1.0

 Attachments: map_with_recv_port.patch


 Currently the port in the from fields of all remap rules are compared 
 against the port in the request (explicitly in the request or implicitly 
 deduced from the protocol). TS supports listening on multiple ports, so there 
 is a use case for a remap rule that uses the TS port at which the request is 
 received instead of the request port.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-876) forward map based on request receive port

2011-07-13 Thread Manjesh Nilange (JIRA) 

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

Manjesh Nilange updated TS-876:
---

Attachment: map_with_recv_port_v2.patch

Modified patch. The old patch was not handling the case when the only forward 
mappings were of the 'map_with_recv_port' type. It was segfaulting.

 forward map based on request receive port
 -

 Key: TS-876
 URL: https://issues.apache.org/jira/browse/TS-876
 Project: Traffic Server
  Issue Type: New Feature
  Components: Remap API
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
 Fix For: 3.1.0

 Attachments: map_with_recv_port.patch, map_with_recv_port_v2.patch


 Currently the port in the from fields of all remap rules are compared 
 against the port in the request (explicitly in the request or implicitly 
 deduced from the protocol). TS supports listening on multiple ports, so there 
 is a use case for a remap rule that uses the TS port at which the request is 
 received instead of the request port.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-876) forward map based on request receive port

2011-07-13 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064852#comment-13064852
 ] 

Leif Hedstrom commented on TS-876:
--

That would explain the old filename (remap.config vs the new 
remap.config.default). You really ought to switch to at least 2.1.9, or 
preferably 3.0.0, there are several important fixes since 2.1.7.

And yeah, getting patches off trunk would be preferably.

 forward map based on request receive port
 -

 Key: TS-876
 URL: https://issues.apache.org/jira/browse/TS-876
 Project: Traffic Server
  Issue Type: New Feature
  Components: Remap API
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
 Fix For: 3.1.0

 Attachments: map_with_recv_port.patch, map_with_recv_port_v2.patch


 Currently the port in the from fields of all remap rules are compared 
 against the port in the request (explicitly in the request or implicitly 
 deduced from the protocol). TS supports listening on multiple ports, so there 
 is a use case for a remap rule that uses the TS port at which the request is 
 received instead of the request port.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TS-877) Segfault caused by HTTPInfo::object_key_get

2011-07-13 Thread Kingsley Foreman (JIRA) 
Segfault caused by  HTTPInfo::object_key_get


 Key: TS-877
 URL: https://issues.apache.org/jira/browse/TS-877
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
 Environment: Ubuntu 10.04tls 64bit
Reporter: Kingsley Foreman


Segfault caused by  HTTPInfo::object_key_get

Reading symbols from /usr/lib/libtsutil.so.3...done.
Loaded symbols for /usr/lib/libtsutil.so.3
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libpcre.so.3
Reading symbols from /lib/libssl.so.0.9.8...(no debugging symbols found)...done.
Loaded symbols for /lib/libssl.so.0.9.8
Reading symbols from /lib/libcrypto.so.0.9.8...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libcrypto.so.0.9.8
Reading symbols from /usr/lib/libtcl8.4.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libtcl8.4.so.0
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libexpat.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libexpat.so.1
Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_dns.so.2
Reading symbols from /usr/libexec/trafficserver/header_filter.so...done.
Loaded symbols for /usr/libexec/trafficserver/header_filter.so
Core was generated by `/usr/bin/traffic_server -M -A,9:X'.
Program terminated with signal 11, Segmentation fault.
#0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
../../proxy/hdrs/HTTP.h:1375
1375  ((int32_t *)  val)[0] = m_alt-m_object_key[0];
(gdb) bt
#0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
../../proxy/hdrs/HTTP.h:1375
#1  0x00592c72 in HttpTransactCache::SelectFromAlternates 
(cache_vector=0x1c96568, client_request=0x1c96528, 
http_config_params=0x2ae66c4b5228)
at HttpTransactCache.cc:213
#2  0x006cb4f1 in CacheVC::openReadChooseWriter (this=0x1c96460, 
event=2, e=0x1e6d6d0) at CacheRead.cc:262
#3  0x006cbc82 in CacheVC::openReadFromWriter (this=0x1c96460, event=2, 
e=0x1e6d6d0) at CacheRead.cc:332
#4  0x004e63e8 in Continuation::handleEvent (this=0x1c96460, event=2, 
data=0x1e6d6d0) at ../iocore/eventsystem/I_Continuation.h:146
#5  0x0072055d in EThread::process_event (this=0x2ae646b46010, 
e=0x1e6d6d0, calling_code=2) at UnixEThread.cc:140
#6  0x0072090d in EThread::execute (this=0x2ae646b46010) at 
UnixEThread.cc:217
#7  0x0071ec32 in spawn_thread_internal (a=0x1a14380) at Thread.cc:88
#8  0x2ae643f639ca in start_thread () from /lib/libpthread.so.0
#9  0x2ae64616970d in clone () from /lib/libc.so.6
#10 0x in ?? ()
(gdb) print *this
$1 = {m_alt = 0x0}


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-877) Segfault caused by HTTPInfo::object_key_get

2011-07-13 Thread Leif Hedstrom (JIRA) 

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

Leif Hedstrom updated TS-877:
-

Due Date: 30/Dec/11

 Segfault caused by  HTTPInfo::object_key_get
 

 Key: TS-877
 URL: https://issues.apache.org/jira/browse/TS-877
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
 Environment: Ubuntu 10.04tls 64bit
Reporter: Kingsley Foreman

 Segfault caused by  HTTPInfo::object_key_get
 Reading symbols from /usr/lib/libtsutil.so.3...done.
 Loaded symbols for /usr/lib/libtsutil.so.3
 Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libpthread.so.0
 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libnsl.so.1
 Reading symbols from /lib/libresolv.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libresolv.so.2
 Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/librt.so.1
 Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
 Loaded symbols for /lib/libpcre.so.3
 Reading symbols from /lib/libssl.so.0.9.8...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libssl.so.0.9.8
 Reading symbols from /lib/libcrypto.so.0.9.8...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libcrypto.so.0.9.8
 Reading symbols from /usr/lib/libtcl8.4.so.0...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libtcl8.4.so.0
 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
 Loaded symbols for /lib/libdl.so.2
 Reading symbols from /lib/libexpat.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libexpat.so.1
 Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libz.so.1
 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libstdc++.so.6
 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libm.so.6
 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libgcc_s.so.1
 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libc.so.6
 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libnss_files.so.2
 Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libnss_dns.so.2
 Reading symbols from /usr/libexec/trafficserver/header_filter.so...done.
 Loaded symbols for /usr/libexec/trafficserver/header_filter.so
 Core was generated by `/usr/bin/traffic_server -M -A,9:X'.
 Program terminated with signal 11, Segmentation fault.
 #0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
 ../../proxy/hdrs/HTTP.h:1375
 1375  ((int32_t *)  val)[0] = m_alt-m_object_key[0];
 (gdb) bt
 #0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
 ../../proxy/hdrs/HTTP.h:1375
 #1  0x00592c72 in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x1c96568, client_request=0x1c96528, 
 http_config_params=0x2ae66c4b5228)
 at HttpTransactCache.cc:213
 #2  0x006cb4f1 in CacheVC::openReadChooseWriter (this=0x1c96460, 
 event=2, e=0x1e6d6d0) at CacheRead.cc:262
 #3  0x006cbc82 in CacheVC::openReadFromWriter (this=0x1c96460, 
 event=2, e=0x1e6d6d0) at CacheRead.cc:332
 #4  0x004e63e8 in Continuation::handleEvent (this=0x1c96460, event=2, 
 data=0x1e6d6d0) at ../iocore/eventsystem/I_Continuation.h:146
 #5  0x0072055d in EThread::process_event (this=0x2ae646b46010, 
 e=0x1e6d6d0, calling_code=2) at UnixEThread.cc:140
 #6  0x0072090d in EThread::execute (this=0x2ae646b46010) at 
 UnixEThread.cc:217
 #7  0x0071ec32 in spawn_thread_internal (a=0x1a14380) at Thread.cc:88
 #8  0x2ae643f639ca in start_thread () from /lib/libpthread.so.0
 #9  0x2ae64616970d in clone () from /lib/libc.so.6
 #10 0x in ?? ()
 (gdb) print *this
 $1 = {m_alt = 0x0}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-877) Segfault caused by HTTPInfo::object_key_get

2011-07-13 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065001#comment-13065001
 ] 

Leif Hedstrom commented on TS-877:
--

Looking at how this API is used, I'm wondering (but, far, far from certain) if 
there's a missing test at the beginning, e.g.

{code}
diff --git a/proxy/hdrs/HTTP.h b/proxy/hdrs/HTTP.h
index c25230c..66a4520 100644
--- a/proxy/hdrs/HTTP.h
+++ b/proxy/hdrs/HTTP.h
@@ -1372,6 +1372,9 @@ HTTPInfo::object_key_get()
 {
   INK_MD5 val;
 
+  if (NULL == m_alt)
+return zero_key;
+
   ((int32_t *)  val)[0] = m_alt-m_object_key[0];
   ((int32_t *)  val)[1] = m_alt-m_object_key[1];
   ((int32_t *)  val)[2] = m_alt-m_object_key[2];
{code}

Now, the real question is, why is m_alt == NULL to begin with?

 Segfault caused by  HTTPInfo::object_key_get
 

 Key: TS-877
 URL: https://issues.apache.org/jira/browse/TS-877
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
 Environment: Ubuntu 10.04tls 64bit
Reporter: Kingsley Foreman

 Segfault caused by  HTTPInfo::object_key_get
 Reading symbols from /usr/lib/libtsutil.so.3...done.
 Loaded symbols for /usr/lib/libtsutil.so.3
 Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libpthread.so.0
 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libnsl.so.1
 Reading symbols from /lib/libresolv.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libresolv.so.2
 Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/librt.so.1
 Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
 Loaded symbols for /lib/libpcre.so.3
 Reading symbols from /lib/libssl.so.0.9.8...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libssl.so.0.9.8
 Reading symbols from /lib/libcrypto.so.0.9.8...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libcrypto.so.0.9.8
 Reading symbols from /usr/lib/libtcl8.4.so.0...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libtcl8.4.so.0
 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
 Loaded symbols for /lib/libdl.so.2
 Reading symbols from /lib/libexpat.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libexpat.so.1
 Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libz.so.1
 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libstdc++.so.6
 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libm.so.6
 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libgcc_s.so.1
 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libc.so.6
 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libnss_files.so.2
 Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libnss_dns.so.2
 Reading symbols from /usr/libexec/trafficserver/header_filter.so...done.
 Loaded symbols for /usr/libexec/trafficserver/header_filter.so
 Core was generated by `/usr/bin/traffic_server -M -A,9:X'.
 Program terminated with signal 11, Segmentation fault.
 #0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
 ../../proxy/hdrs/HTTP.h:1375
 1375  ((int32_t *)  val)[0] = m_alt-m_object_key[0];
 (gdb) bt
 #0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
 ../../proxy/hdrs/HTTP.h:1375
 #1  0x00592c72 in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x1c96568, client_request=0x1c96528, 
 http_config_params=0x2ae66c4b5228)
 at HttpTransactCache.cc:213
 #2  0x006cb4f1 in CacheVC::openReadChooseWriter (this=0x1c96460, 
 event=2, e=0x1e6d6d0) at CacheRead.cc:262
 #3  0x006cbc82 in CacheVC::openReadFromWriter (this=0x1c96460, 
 event=2, e=0x1e6d6d0) at CacheRead.cc:332
 #4  0x004e63e8 in Continuation::handleEvent (this=0x1c96460, event=2, 
 data=0x1e6d6d0) at ../iocore/eventsystem/I_Continuation.h:146
 #5  0x0072055d in EThread::process_event (this=0x2ae646b46010, 
 e=0x1e6d6d0, calling_code=2) at UnixEThread.cc:140
 #6  0x0072090d in EThread::execute (this=0x2ae646b46010) at 
 UnixEThread.cc:217
 #7  0x0071ec32 in spawn_thread_internal (a=0x1a14380) at Thread.cc:88
 #8  0x2ae643f639ca in

[jira] [Commented] (TS-877) Segfault caused by HTTPInfo::object_key_get

2011-07-13 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065004#comment-13065004
 ] 

Leif Hedstrom commented on TS-877:
--

Another thought could be that the cache got corrupted. Asking if the OP can try 
to clear the cache.

 Segfault caused by  HTTPInfo::object_key_get
 

 Key: TS-877
 URL: https://issues.apache.org/jira/browse/TS-877
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
 Environment: Ubuntu 10.04tls 64bit
Reporter: Kingsley Foreman

 Segfault caused by  HTTPInfo::object_key_get
 Reading symbols from /usr/lib/libtsutil.so.3...done.
 Loaded symbols for /usr/lib/libtsutil.so.3
 Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libpthread.so.0
 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libnsl.so.1
 Reading symbols from /lib/libresolv.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libresolv.so.2
 Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/librt.so.1
 Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
 Loaded symbols for /lib/libpcre.so.3
 Reading symbols from /lib/libssl.so.0.9.8...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libssl.so.0.9.8
 Reading symbols from /lib/libcrypto.so.0.9.8...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libcrypto.so.0.9.8
 Reading symbols from /usr/lib/libtcl8.4.so.0...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libtcl8.4.so.0
 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
 Loaded symbols for /lib/libdl.so.2
 Reading symbols from /lib/libexpat.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libexpat.so.1
 Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libz.so.1
 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libstdc++.so.6
 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libm.so.6
 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libgcc_s.so.1
 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libc.so.6
 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libnss_files.so.2
 Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libnss_dns.so.2
 Reading symbols from /usr/libexec/trafficserver/header_filter.so...done.
 Loaded symbols for /usr/libexec/trafficserver/header_filter.so
 Core was generated by `/usr/bin/traffic_server -M -A,9:X'.
 Program terminated with signal 11, Segmentation fault.
 #0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
 ../../proxy/hdrs/HTTP.h:1375
 1375  ((int32_t *)  val)[0] = m_alt-m_object_key[0];
 (gdb) bt
 #0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
 ../../proxy/hdrs/HTTP.h:1375
 #1  0x00592c72 in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x1c96568, client_request=0x1c96528, 
 http_config_params=0x2ae66c4b5228)
 at HttpTransactCache.cc:213
 #2  0x006cb4f1 in CacheVC::openReadChooseWriter (this=0x1c96460, 
 event=2, e=0x1e6d6d0) at CacheRead.cc:262
 #3  0x006cbc82 in CacheVC::openReadFromWriter (this=0x1c96460, 
 event=2, e=0x1e6d6d0) at CacheRead.cc:332
 #4  0x004e63e8 in Continuation::handleEvent (this=0x1c96460, event=2, 
 data=0x1e6d6d0) at ../iocore/eventsystem/I_Continuation.h:146
 #5  0x0072055d in EThread::process_event (this=0x2ae646b46010, 
 e=0x1e6d6d0, calling_code=2) at UnixEThread.cc:140
 #6  0x0072090d in EThread::execute (this=0x2ae646b46010) at 
 UnixEThread.cc:217
 #7  0x0071ec32 in spawn_thread_internal (a=0x1a14380) at Thread.cc:88
 #8  0x2ae643f639ca in start_thread () from /lib/libpthread.so.0
 #9  0x2ae64616970d in clone () from /lib/libc.so.6
 #10 0x in ?? ()
 (gdb) print *this
 $1 = {m_alt = 0x0}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-877) Segfault caused by HTTPInfo::object_key_get

2011-07-13 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065006#comment-13065006
 ] 

Leif Hedstrom commented on TS-877:
--

Looking at the code, at a minimum we should apply this optimization:

{code}
diff --git a/proxy/http/HttpTransactCache.cc b/proxy/http/HttpTransactCache.cc
index e1b9a5f..4fab4f9 100644
--- a/proxy/http/HttpTransactCache.cc
+++ b/proxy/http/HttpTransactCache.cc
@@ -169,7 +169,6 @@ int
 HttpTransactCache::SelectFromAlternates(CacheHTTPInfoVector * cache_vector,
 HTTPHdr * client_request, 
CacheLookupHttpConfig * http_config_params)
 {
-  CacheKey zero_key(0, 0);
   time_t current_age, best_age = NUM_SECONDS_IN_ONE_YEAR;
   time_t t_now = 0;
   int best_index = -1;
{code}

 Segfault caused by  HTTPInfo::object_key_get
 

 Key: TS-877
 URL: https://issues.apache.org/jira/browse/TS-877
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
 Environment: Ubuntu 10.04tls 64bit
Reporter: Kingsley Foreman

 Segfault caused by  HTTPInfo::object_key_get
 Reading symbols from /usr/lib/libtsutil.so.3...done.
 Loaded symbols for /usr/lib/libtsutil.so.3
 Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libpthread.so.0
 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libnsl.so.1
 Reading symbols from /lib/libresolv.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libresolv.so.2
 Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/librt.so.1
 Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
 Loaded symbols for /lib/libpcre.so.3
 Reading symbols from /lib/libssl.so.0.9.8...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libssl.so.0.9.8
 Reading symbols from /lib/libcrypto.so.0.9.8...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libcrypto.so.0.9.8
 Reading symbols from /usr/lib/libtcl8.4.so.0...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libtcl8.4.so.0
 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
 Loaded symbols for /lib/libdl.so.2
 Reading symbols from /lib/libexpat.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libexpat.so.1
 Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libz.so.1
 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libstdc++.so.6
 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libm.so.6
 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libgcc_s.so.1
 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libc.so.6
 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libnss_files.so.2
 Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libnss_dns.so.2
 Reading symbols from /usr/libexec/trafficserver/header_filter.so...done.
 Loaded symbols for /usr/libexec/trafficserver/header_filter.so
 Core was generated by `/usr/bin/traffic_server -M -A,9:X'.
 Program terminated with signal 11, Segmentation fault.
 #0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
 ../../proxy/hdrs/HTTP.h:1375
 1375  ((int32_t *)  val)[0] = m_alt-m_object_key[0];
 (gdb) bt
 #0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
 ../../proxy/hdrs/HTTP.h:1375
 #1  0x00592c72 in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x1c96568, client_request=0x1c96528, 
 http_config_params=0x2ae66c4b5228)
 at HttpTransactCache.cc:213
 #2  0x006cb4f1 in CacheVC::openReadChooseWriter (this=0x1c96460, 
 event=2, e=0x1e6d6d0) at CacheRead.cc:262
 #3  0x006cbc82 in CacheVC::openReadFromWriter (this=0x1c96460, 
 event=2, e=0x1e6d6d0) at CacheRead.cc:332
 #4  0x004e63e8 in Continuation::handleEvent (this=0x1c96460, event=2, 
 data=0x1e6d6d0) at ../iocore/eventsystem/I_Continuation.h:146
 #5  0x0072055d in EThread::process_event (this=0x2ae646b46010, 
 e=0x1e6d6d0, calling_code=2) at UnixEThread.cc:140
 #6  0x0072090d in EThread::execute (this=0x2ae646b46010) at 
 UnixEThread.cc:217
 #7  0x0071ec32 in spawn_thread_internal (a=0x1a14380) at Thread.cc:88
 #8

[jira] [Commented] (TS-877) Segfault caused by HTTPInfo::object_key_get

2011-07-13 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065008#comment-13065008
 ] 

Leif Hedstrom commented on TS-877:
--

And, we should probably figure out why m_alt is NULL still, and perhaps 
invalidate a cache object where that would occur? I mean, even though it's most 
likely a cache corruption, it'd be nice to be able to deal with it slightly 
better than a segfault.

 Segfault caused by  HTTPInfo::object_key_get
 

 Key: TS-877
 URL: https://issues.apache.org/jira/browse/TS-877
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
 Environment: Ubuntu 10.04tls 64bit
Reporter: Kingsley Foreman

 Segfault caused by  HTTPInfo::object_key_get
 Reading symbols from /usr/lib/libtsutil.so.3...done.
 Loaded symbols for /usr/lib/libtsutil.so.3
 Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libpthread.so.0
 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libnsl.so.1
 Reading symbols from /lib/libresolv.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libresolv.so.2
 Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/librt.so.1
 Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
 Loaded symbols for /lib/libpcre.so.3
 Reading symbols from /lib/libssl.so.0.9.8...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libssl.so.0.9.8
 Reading symbols from /lib/libcrypto.so.0.9.8...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libcrypto.so.0.9.8
 Reading symbols from /usr/lib/libtcl8.4.so.0...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libtcl8.4.so.0
 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
 Loaded symbols for /lib/libdl.so.2
 Reading symbols from /lib/libexpat.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libexpat.so.1
 Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libz.so.1
 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libstdc++.so.6
 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libm.so.6
 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libgcc_s.so.1
 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libc.so.6
 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libnss_files.so.2
 Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libnss_dns.so.2
 Reading symbols from /usr/libexec/trafficserver/header_filter.so...done.
 Loaded symbols for /usr/libexec/trafficserver/header_filter.so
 Core was generated by `/usr/bin/traffic_server -M -A,9:X'.
 Program terminated with signal 11, Segmentation fault.
 #0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
 ../../proxy/hdrs/HTTP.h:1375
 1375  ((int32_t *)  val)[0] = m_alt-m_object_key[0];
 (gdb) bt
 #0  0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at 
 ../../proxy/hdrs/HTTP.h:1375
 #1  0x00592c72 in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x1c96568, client_request=0x1c96528, 
 http_config_params=0x2ae66c4b5228)
 at HttpTransactCache.cc:213
 #2  0x006cb4f1 in CacheVC::openReadChooseWriter (this=0x1c96460, 
 event=2, e=0x1e6d6d0) at CacheRead.cc:262
 #3  0x006cbc82 in CacheVC::openReadFromWriter (this=0x1c96460, 
 event=2, e=0x1e6d6d0) at CacheRead.cc:332
 #4  0x004e63e8 in Continuation::handleEvent (this=0x1c96460, event=2, 
 data=0x1e6d6d0) at ../iocore/eventsystem/I_Continuation.h:146
 #5  0x0072055d in EThread::process_event (this=0x2ae646b46010, 
 e=0x1e6d6d0, calling_code=2) at UnixEThread.cc:140
 #6  0x0072090d in EThread::execute (this=0x2ae646b46010) at 
 UnixEThread.cc:217
 #7  0x0071ec32 in spawn_thread_internal (a=0x1a14380) at Thread.cc:88
 #8  0x2ae643f639ca in start_thread () from /lib/libpthread.so.0
 #9  0x2ae64616970d in clone () from /lib/libc.so.6
 #10 0x in ?? ()
 (gdb) print *this
 $1 = {m_alt = 0x0}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TS-878) ATS3.0 frequently shows Broken pipe and exit !

2011-07-13 Thread taoyunxing (JIRA) 
ATS3.0 frequently shows Broken pipe and exit !
--

 Key: TS-878
 URL: https://issues.apache.org/jira/browse/TS-878
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
 Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0, Web 
Browser：firefox 4.0.1，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 
500G
Reporter: taoyunxing


when I cliclk some website using the debug mode of ATS 3.0, the web page shows 
well, and I can see most content, but suddenly the following warning occurs: 

Program received signal SIGPIPE, Broken pipe.
0x0012e416 in __kernel_vsyscall ()
(gdb) bt
#0  0x0012e416 in __kernel_vsyscall ()
#1  0x0016754b in write () from /lib/libpthread.so.0
#2  0x082be866 in write (this=0x9562bb0, towrite=5552, wattempted=@0xbfffdb20, 
total_wrote=@0xbfffdb28, buf=...) at 
../../iocore/eventsystem/P_UnixSocketManager.h:207
#3  UnixNetVConnection::load_buffer_and_write (this=0x9562bb0, towrite=5552, 
wattempted=@0xbfffdb20, total_wrote=@0xbfffdb28, buf=...) at 
UnixNetVConnection.cc:834
#4  0x082c31a6 in write_to_net_io (nh=0xb759c528, vc=0x9562bb0, 
thread=0xb759b008) at UnixNetVConnection.cc:439
#5  0x082b977b in NetHandler::mainNetEvent (this=0xb759c528, event=5, 
e=0x88af7a0) at UnixNet.cc:413
#6  0x082e86c2 in handleEvent (this=0xb759b008, e=0x88af7a0, calling_code=5) at 
I_Continuation.h:146
#7  EThread::process_event (this=0xb759b008, e=0x88af7a0, calling_code=5) at 
UnixEThread.cc:140
#8  0x082e8fe3 in EThread::execute (this=0xb759b008) at UnixEThread.cc:262
#9  0x080f68d6 in main (argc=1, argv=0xb424) at Main.cc:1958
(gdb)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-878) ATS3.0 frequently shows Broken pipe and exit !

2011-07-13 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065011#comment-13065011
 ] 

Leif Hedstrom commented on TS-878:
--

This is running inside GDB I assume? This is a misfeature of GDB :-/. See 
https://cwiki.apache.org/confluence/display/TS/Filing+useful+bug+reports for 
more details. If that is indeed the case, please close or let us know.

 ATS3.0 frequently shows Broken pipe and exit !
 --

 Key: TS-878
 URL: https://issues.apache.org/jira/browse/TS-878
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
 Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0, Web 
 Browser：firefox 4.0.1，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 
 500G
Reporter: taoyunxing
   Original Estimate: 96h
  Remaining Estimate: 96h

 when I cliclk some website using the debug mode of ATS 3.0, the web page 
 shows well, and I can see most content, but suddenly the following warning 
 occurs: 
 Program received signal SIGPIPE, Broken pipe.
 0x0012e416 in __kernel_vsyscall ()
 (gdb) bt
 #0  0x0012e416 in __kernel_vsyscall ()
 #1  0x0016754b in write () from /lib/libpthread.so.0
 #2  0x082be866 in write (this=0x9562bb0, towrite=5552, 
 wattempted=@0xbfffdb20, total_wrote=@0xbfffdb28, buf=...) at 
 ../../iocore/eventsystem/P_UnixSocketManager.h:207
 #3  UnixNetVConnection::load_buffer_and_write (this=0x9562bb0, towrite=5552, 
 wattempted=@0xbfffdb20, total_wrote=@0xbfffdb28, buf=...) at 
 UnixNetVConnection.cc:834
 #4  0x082c31a6 in write_to_net_io (nh=0xb759c528, vc=0x9562bb0, 
 thread=0xb759b008) at UnixNetVConnection.cc:439
 #5  0x082b977b in NetHandler::mainNetEvent (this=0xb759c528, event=5, 
 e=0x88af7a0) at UnixNet.cc:413
 #6  0x082e86c2 in handleEvent (this=0xb759b008, e=0x88af7a0, calling_code=5) 
 at I_Continuation.h:146
 #7  EThread::process_event (this=0xb759b008, e=0x88af7a0, calling_code=5) at 
 UnixEThread.cc:140
 #8  0x082e8fe3 in EThread::execute (this=0xb759b008) at UnixEThread.cc:262
 #9  0x080f68d6 in main (argc=1, argv=0xb424) at Main.cc:1958
 (gdb)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-878) ATS3.0 frequently shows Broken pipe and exit !

2011-07-13 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065025#comment-13065025
 ] 

Leif Hedstrom commented on TS-878:
--

I should point out, pay attention to the GDB configuration necessary to run ATS 
under gdb:

{code}
handle SIGPIPE nopass nostop noprint
{code}


 ATS3.0 frequently shows Broken pipe and exit !
 --

 Key: TS-878
 URL: https://issues.apache.org/jira/browse/TS-878
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
 Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0, Web 
 Browser：firefox 4.0.1，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 
 500G
Reporter: taoyunxing
   Original Estimate: 96h
  Remaining Estimate: 96h

 when I cliclk some website using the debug mode of ATS 3.0, the web page 
 shows well, and I can see most content, but suddenly the following warning 
 occurs: 
 Program received signal SIGPIPE, Broken pipe.
 0x0012e416 in __kernel_vsyscall ()
 (gdb) bt
 #0  0x0012e416 in __kernel_vsyscall ()
 #1  0x0016754b in write () from /lib/libpthread.so.0
 #2  0x082be866 in write (this=0x9562bb0, towrite=5552, 
 wattempted=@0xbfffdb20, total_wrote=@0xbfffdb28, buf=...) at 
 ../../iocore/eventsystem/P_UnixSocketManager.h:207
 #3  UnixNetVConnection::load_buffer_and_write (this=0x9562bb0, towrite=5552, 
 wattempted=@0xbfffdb20, total_wrote=@0xbfffdb28, buf=...) at 
 UnixNetVConnection.cc:834
 #4  0x082c31a6 in write_to_net_io (nh=0xb759c528, vc=0x9562bb0, 
 thread=0xb759b008) at UnixNetVConnection.cc:439
 #5  0x082b977b in NetHandler::mainNetEvent (this=0xb759c528, event=5, 
 e=0x88af7a0) at UnixNet.cc:413
 #6  0x082e86c2 in handleEvent (this=0xb759b008, e=0x88af7a0, calling_code=5) 
 at I_Continuation.h:146
 #7  EThread::process_event (this=0xb759b008, e=0x88af7a0, calling_code=5) at 
 UnixEThread.cc:140
 #8  0x082e8fe3 in EThread::execute (this=0xb759b008) at UnixEThread.cc:262
 #9  0x080f68d6 in main (argc=1, argv=0xb424) at Main.cc:1958
 (gdb)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira