[jira] [Created] (TS-838) [GSoC] Create a port of mod_security as Apache TrafficServer plugin
[GSoC] Create a port of mod_security as Apache TrafficServer plugin --- Key: TS-838 URL: https://issues.apache.org/jira/browse/TS-838 Project: Traffic Server Issue Type: Wish Components: Plugins Reporter: Igor Galić ModSecurity is a Web Application Firewall (WAF), which is currently natively implemented as Apache httpd module. It is mostly used to protect multiple back-end applications from a single entry point on a proxy-server. This alone makes Traffic Server the ideal platform for a port. For reference, see https://www.modsecurity.org/tracker/browse/MODSEC-250 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-839) Build errors when specifying lmza location
Build errors when specifying lmza location -- Key: TS-839 URL: https://issues.apache.org/jira/browse/TS-839 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.0 When using a specific lmza location with ./configure, we have a typo that prevents proper building (it'll end up giving a -R option with an empty argument). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-697) Attempting to log the "shi" and "pqsi" parameters via logs_xml.config (IP types) causes a segfault
[
https://issues.apache.org/jira/browse/TS-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-697:
-
Backport to Version: (was: 3.0.1)
Removing backport target until we have a patch and/or more info to reproduce
this.
> Attempting to log the "shi" and "pqsi" parameters via logs_xml.config (IP
> types) causes a segfault
> --
>
> Key: TS-697
> URL: https://issues.apache.org/jira/browse/TS-697
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 2.1.6
> Environment: Solaris 10 u8
>Reporter: Eric Connell
>Priority: Minor
> Fix For: 3.1.0
>
>
> Creating a LogFormat that contains either % or % symbols causes a
> segfault when attempting to unmarshal the IP in LogAccess::unmarshal_ip().
> The following config in logs_xml.config should recreate the problem:
> {code}
>
>
> "/>
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-785) Building outside of the tree does not work
[
https://issues.apache.org/jira/browse/TS-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-785:
-
Backport to Version: (was: 3.0.1)
Removing backport target until we have a patch for this.
> Building outside of the tree does not work
> --
>
> Key: TS-785
> URL: https://issues.apache.org/jira/browse/TS-785
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Igor Galić
> Labels: build
> Fix For: 3.1.0
>
>
> {noformat}
> igalic@bawnb976 ~/Projects/asf/ats-build % ../trafficserver/configure
> --prefix=/opt/dev
>
> ...
> igalic@bawnb976 ~/Projects/asf/ats-build % make
> Making all in proxy/api/ts
> make[1]: Entering directory `/home/igalic/Projects/asf/ats-build/proxy/api/ts'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/home/igalic/Projects/asf/ats-build/proxy/api/ts'
> Making all in iocore
> make[1]: Entering directory `/home/igalic/Projects/asf/ats-build/iocore'
> Making all in eventsystem
> make[2]: Entering directory
> `/home/igalic/Projects/asf/ats-build/iocore/eventsystem'
> g++ -DHAVE_CONFIG_H -I. -I../../../trafficserver/iocore/eventsystem
> -I../../lib/ts -I../../../trafficserver/lib/records -D_LARGEFILE64_SOURCE=1
> -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux
> -I/usr/include/tcl8.4 -mtune=native -march=native -Wall -O3 -march=i586 -g
> -pipe -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -MT EventSystem.o -MD -MP -MF .deps/EventSystem.Tpo -c
> -o EventSystem.o ../../../trafficserver/iocore/eventsystem/EventSystem.cc
> In file included from
> ../../../trafficserver/iocore/eventsystem/EventSystem.cc:31:0:
> ../../../trafficserver/iocore/eventsystem/P_EventSystem.h:39:19: fatal error:
> libts.h: No such file or directory
> compilation terminated.
> make[2]: *** [EventSystem.o] Error 1
> make[2]: Leaving directory
> `/home/igalic/Projects/asf/ats-build/iocore/eventsystem'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/igalic/Projects/asf/ats-build/iocore'
> make: *** [all-recursive] Error 1
> 2 igalic@bawnb976 ~/Projects/asf/ats-build %
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-840) Regression checks fail (again) due to faulty assert use
Regression checks fail (again) due to faulty assert use
---
Key: TS-840
URL: https://issues.apache.org/jira/browse/TS-840
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.0
Reporter: Arno Toell
Priority: Minor
Attachments: ink_assert.patch
When trying to compile regression checks, they fail again for ATS 3.0. They
were fixed in TS-738 some time ago, but are now failing again, this time
because of a build failure. Problem is the usage of _assert()_:
{code}
libtool: link: g++ -g -O2 -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof -o
.libs/test_Map test_Map.o ./.libs/libtsutil.so -L/usr/lib -lpcre -lssl
-lcrypto -ltcl8.4 -lresolv -lrt -lnsl -lcap -lz -Wl,-rpath
-Wl,/usr/lib/trafficserver
g++ -DHAVE_CONFIG_H -I. -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1
-D_GNU_SOURCE -D_REENTRANT -Dlinux -I/usr/include/tcl8.4 -g -O2 -pipe -Wall
-Werror -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof -c -o test_Vec.o test_Vec.cc
test_Vec.cc: In function 'int main(int, char**)':
test_Vec.cc:38: error: '__DONT_USE_BARE_assert_USE_ink_assert__' was not
declared in this scope
{code}
This is due to following definition in _lib/ts/ink_assert.h_:
{code}
#undef assert
#define assert __DONT_USE_BARE_assert_USE_ink_assert__
{code}
I attached a patch which is fixing this issue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-840) Regression checks fail (again) due to faulty assert use
[
https://issues.apache.org/jira/browse/TS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arno Toell updated TS-840:
--
Attachment: ink_assert.patch
> Regression checks fail (again) due to faulty assert use
> ---
>
> Key: TS-840
> URL: https://issues.apache.org/jira/browse/TS-840
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.0.0
>Reporter: Arno Toell
>Priority: Minor
> Attachments: ink_assert.patch
>
>
> When trying to compile regression checks, they fail again for ATS 3.0. They
> were fixed in TS-738 some time ago, but are now failing again, this time
> because of a build failure. Problem is the usage of _assert()_:
> {code}
> libtool: link: g++ -g -O2 -pipe -Wall -Werror -O3
> -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
> -o .libs/test_Map test_Map.o ./.libs/libtsutil.so -L/usr/lib -lpcre -lssl
> -lcrypto -ltcl8.4 -lresolv -lrt -lnsl -lcap -lz -Wl,-rpath
> -Wl,/usr/lib/trafficserver
> g++ -DHAVE_CONFIG_H -I. -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1
> -D_GNU_SOURCE -D_REENTRANT -Dlinux -I/usr/include/tcl8.4 -g -O2 -pipe -Wall
> -Werror -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -c -o test_Vec.o test_Vec.cc
> test_Vec.cc: In function 'int main(int, char**)':
> test_Vec.cc:38: error: '__DONT_USE_BARE_assert_USE_ink_assert__' was not
> declared in this scope
> {code}
> This is due to following definition in _lib/ts/ink_assert.h_:
> {code}
> #undef assert
> #define assert __DONT_USE_BARE_assert_USE_ink_assert__
> {code}
> I attached a patch which is fixing this issue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-833) Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef, ink_freelist_free related
[
https://issues.apache.org/jira/browse/TS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Plevyak updated TS-833:
Attachment: TS-833-2.diff
This is a possible patch which deals with DNS issues.
> Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef,
> ink_freelist_free related
> ---
>
> Key: TS-833
> URL: https://issues.apache.org/jira/browse/TS-833
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.0
> Environment: current trunk, with --enable-debug
>Reporter: Zhao Yongming
> Labels: freelist
> Attachments: TS-833-2.diff, TS-833.diff
>
>
> bt #1
> {code}
> #0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
> event=2, data=0x197c4fc0) at I_Continuation.h:146
> 146 return (this->*handler) (event, data);
> (gdb) bt
> #0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
> event=2, data=0x197c4fc0) at I_Continuation.h:146
> #1 0x006f5830 in EThread::process_event (this=0x2ae29010,
> e=0x197c4fc0, calling_code=2) at UnixEThread.cc:140
> #2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
> UnixEThread.cc:217
> #3 0x004ff37d in main (argc=3, argv=0x7fff76c41528) at Main.cc:1958
> (gdb) info f
> Stack level 0, frame at 0x7fff76c40e40:
> rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
> (I_Continuation.h:146); saved rip 0x6f5830
> called by frame at 0x7fff76c40eb0
> source language c++.
> Arglist at 0x7fff76c40e30, args: this=0x19581df0, event=2, data=0x197c4fc0
> Locals at 0x7fff76c40e30, Previous frame's sp is 0x7fff76c40e40
> Saved registers:
> rbp at 0x7fff76c40e30, rip at 0x7fff76c40e38
> (gdb) x/40x this
> 0x19581df0: 0x19581901 0x 0xefbeadde 0xefbeadde
> 0x19581e00: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e10: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e20: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e30: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e40: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e50: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e60: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e70: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e80: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> {code}
> bt #2
> {code}
> #0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
> data=0xc4408a0) at I_Continuation.h:146
> 146 return (this->*handler) (event, data);
> (gdb) bt
> #0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
> data=0xc4408a0) at I_Continuation.h:146
> #1 0x0070364c in EThread::process_event (this=0x2ae29010,
> e=0xc4408a0, calling_code=2) at UnixEThread.cc:140
> #2 0x0070398e in EThread::execute (this=0x2ae29010) at
> UnixEThread.cc:217
> #3 0x00502aac in main (argc=3, argv=0x7fff32ef2f58) at Main.cc:1961
> (gdb) p *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
> handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
> handler_name = 0xefbeaddeefbeadde bounds>, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {>
> = {
> next = 0xefbeaddeefbeadde}, prev = 0xefbeaddeefbeadde}}
> (gdb)
> {code}
> bt #3
> {code}
> #0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
> event=2, data=0x2aaab00d1570) at I_Continuation.h:146
> 146 return (this->*handler) (event, data);
> (gdb) bt
> #0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
> event=2, data=0x2aaab00d1570) at I_Continuation.h:146
> #1 0x006f5830 in EThread::process_event (this=0x2ae29010,
> e=0x2aaab00d1570, calling_code=2) at UnixEThread.cc:140
> #2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
> UnixEThread.cc:217
> #3 0x004ff37d in main (argc=3, argv=0x7fff421f08d8) at Main.cc:1958
> (gdb) info f
> Stack level 0, frame at 0x7fff421f01f0:
> rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
> (I_Continuation.h:146); saved rip 0x6f5830
> called by frame at 0x7fff421f0260
> source language c++.
> Arglist at 0x7fff421f01e0, args: this=0x2aaab00615b0, event=2,
> data=0x2aaab00d1570
> Locals at 0x7fff421f01e0, Previous frame's sp is 0x7fff421f01f0
> Saved registers:
> rbp at 0x7fff421f01e0, rip at 0x7fff421f01e8
> (gdb) p this->handler
> $1 = 0xefbeaddeefbeadde, this adjustment -1171307680053154338
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-834) Crash Report: InactivityCop::check_inactivity, event=2, UnixNet.cc:57
[
https://issues.apache.org/jira/browse/TS-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Plevyak updated TS-834:
Attachment: TS-834.diff
Patch copied from TS-833 which is really for this bug.
> Crash Report: InactivityCop::check_inactivity, event=2, UnixNet.cc:57
> -
>
> Key: TS-834
> URL: https://issues.apache.org/jira/browse/TS-834
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.0
> Environment: current trunk( the same time as v3.0), --enable-debug
>Reporter: Zhao Yongming
> Labels: UnixNet
> Attachments: TS-834.diff
>
>
> bt #1
> {code}
> #0 0x004d2c5c in Continuation::handleEvent (this=0x2aaaf4091b70,
> event=1, data=0x4b2d6d0) at I_Continuation.h:146
> 146 return (this->*handler) (event, data);
> (gdb) bt
> #0 0x004d2c5c in Continuation::handleEvent (this=0x2aaaf4091b70,
> event=1, data=0x4b2d6d0) at I_Continuation.h:146
> #1 0x006ce196 in InactivityCop::check_inactivity (this=0x4b3f780,
> event=2, e=0x4b2d6d0) at UnixNet.cc:57
> #2 0x004d2c5f in Continuation::handleEvent (this=0x4b3f780, event=2,
> data=0x4b2d6d0) at I_Continuation.h:146
> #3 0x006f5830 in EThread::process_event (this=0x2ae29010,
> e=0x4b2d6d0, calling_code=2) at UnixEThread.cc:140
> #4 0x006f5b72 in EThread::execute (this=0x2ae29010) at
> UnixEThread.cc:217
> #5 0x004ff37d in main (argc=3, argv=0x7fff6f447418) at Main.cc:1958
> (gdb) info f
> Stack level 0, frame at 0x7fff6f446cb0:
> rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
> (I_Continuation.h:146); saved rip 0x6ce196
> called by frame at 0x7fff6f446d00
> source language c++.
> Arglist at 0x7fff6f446ca0, args: this=0x2aaaf4091b70, event=1, data=0x4b2d6d0
> Locals at 0x7fff6f446ca0, Previous frame's sp is 0x7fff6f446cb0
> Saved registers:
> rbp at 0x7fff6f446ca0, rip at 0x7fff6f446ca8
> (gdb) x/80x this
> 0x2aaaf4091b70: 0x0076a830 0x 0x006d1902 0x
> 0x2aaaf4091b80: 0x 0x 0x0076a290 0x
> 0x2aaaf4091b90: 0x 0x 0x 0x
> 0x2aaaf4091ba0: 0x 0x 0x 0x
> 0x2aaaf4091bb0: 0x 0x 0x 0x
> 0x2aaaf4091bc0: 0x 0x 0x 0x
> 0x2aaaf4091bd0: 0x 0x 0x 0x
> 0x2aaaf4091be0: 0x 0x 0x 0x
> 0x2aaaf4091bf0: 0x 0x 0x 0x
> 0x2aaaf4091c00: 0x 0x 0x 0x
> 0x2aaaf4091c10: 0x 0x 0x 0x
> 0x2aaaf4091c20: 0x 0x 0x 0x
> 0x2aaaf4091c30: 0x 0x 0x 0x
> 0x2aaaf4091c40: 0x 0x 0x 0x
> 0x2aaaf4091c50: 0x 0x 0x 0x
> 0x2aaaf4091c60: 0x 0x 0x 0x
> 0x2aaaf4091c70: 0x 0x 0x 0x
> 0x2aaaf4091c80: 0x 0x 0x 0x
> 0x2aaaf4091c90: 0x 0x 0x 0x
> 0x2aaaf4091ca0: 0x 0x 0x 0x
> {code}
> bt #2
> {code}
> #0 0x004d2c5c in Continuation::handleEvent (this=0x11ed6000,
> event=1, data=0x11cbc610) at I_Continuation.h:146
> 146 return (this->*handler) (event, data);
> (gdb) bt
> #0 0x004d2c5c in Continuation::handleEvent (this=0x11ed6000,
> event=1, data=0x11cbc610) at I_Continuation.h:146
> #1 0x006ce196 in InactivityCop::check_inactivity
> (this=0x2c001f50, event=2, e=0x11cbc610) at UnixNet.cc:57
> #2 0x004d2c5f in Continuation::handleEvent (this=0x2c001f50,
> event=2, data=0x11cbc610) at I_Continuation.h:146
> #3 0x006f5830 in EThread::process_event (this=0x2af2a010,
> e=0x11cbc610, calling_code=2) at UnixEThread.cc:140
> #4 0x006f5b72 in EThread::execute (this=0x2af2a010) at
> UnixEThread.cc:217
> #5 0x006f5181 in spawn_thread_internal (a=0x11cadae0) at Thread.cc:88
> #6 0x0030ec2064a7 in start_thread () from /lib64/libpthread.so.0
> #7 0x0030eb6d3c2d in clone () from /lib64/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0x4198df60:
> rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
> (I_Continuation.h:146); saved rip 0x6ce196
> called by frame at 0x4198dfb0
> source language c++.
> Arglist at 0x4198df50, args: this=0x11ed6000, event=1, data=0
[jira] [Updated] (TS-833) Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef, ink_freelist_free related
[
https://issues.apache.org/jira/browse/TS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Plevyak updated TS-833:
Attachment: TS-833-3.diff
Even more conservative coding style.
> Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef,
> ink_freelist_free related
> ---
>
> Key: TS-833
> URL: https://issues.apache.org/jira/browse/TS-833
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.0
> Environment: current trunk, with --enable-debug
>Reporter: Zhao Yongming
> Labels: freelist
> Attachments: TS-833-2.diff, TS-833-3.diff, TS-833.diff
>
>
> bt #1
> {code}
> #0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
> event=2, data=0x197c4fc0) at I_Continuation.h:146
> 146 return (this->*handler) (event, data);
> (gdb) bt
> #0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
> event=2, data=0x197c4fc0) at I_Continuation.h:146
> #1 0x006f5830 in EThread::process_event (this=0x2ae29010,
> e=0x197c4fc0, calling_code=2) at UnixEThread.cc:140
> #2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
> UnixEThread.cc:217
> #3 0x004ff37d in main (argc=3, argv=0x7fff76c41528) at Main.cc:1958
> (gdb) info f
> Stack level 0, frame at 0x7fff76c40e40:
> rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
> (I_Continuation.h:146); saved rip 0x6f5830
> called by frame at 0x7fff76c40eb0
> source language c++.
> Arglist at 0x7fff76c40e30, args: this=0x19581df0, event=2, data=0x197c4fc0
> Locals at 0x7fff76c40e30, Previous frame's sp is 0x7fff76c40e40
> Saved registers:
> rbp at 0x7fff76c40e30, rip at 0x7fff76c40e38
> (gdb) x/40x this
> 0x19581df0: 0x19581901 0x 0xefbeadde 0xefbeadde
> 0x19581e00: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e10: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e20: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e30: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e40: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e50: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e60: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e70: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> 0x19581e80: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
> {code}
> bt #2
> {code}
> #0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
> data=0xc4408a0) at I_Continuation.h:146
> 146 return (this->*handler) (event, data);
> (gdb) bt
> #0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
> data=0xc4408a0) at I_Continuation.h:146
> #1 0x0070364c in EThread::process_event (this=0x2ae29010,
> e=0xc4408a0, calling_code=2) at UnixEThread.cc:140
> #2 0x0070398e in EThread::execute (this=0x2ae29010) at
> UnixEThread.cc:217
> #3 0x00502aac in main (argc=3, argv=0x7fff32ef2f58) at Main.cc:1961
> (gdb) p *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
> handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
> handler_name = 0xefbeaddeefbeadde bounds>, mutex = {m_ptr = 0xefbeaddeefbeadde}, link = {>
> = {
> next = 0xefbeaddeefbeadde}, prev = 0xefbeaddeefbeadde}}
> (gdb)
> {code}
> bt #3
> {code}
> #0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
> event=2, data=0x2aaab00d1570) at I_Continuation.h:146
> 146 return (this->*handler) (event, data);
> (gdb) bt
> #0 0x004d2c5c in Continuation::handleEvent (this=0x2aaab00615b0,
> event=2, data=0x2aaab00d1570) at I_Continuation.h:146
> #1 0x006f5830 in EThread::process_event (this=0x2ae29010,
> e=0x2aaab00d1570, calling_code=2) at UnixEThread.cc:140
> #2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
> UnixEThread.cc:217
> #3 0x004ff37d in main (argc=3, argv=0x7fff421f08d8) at Main.cc:1958
> (gdb) info f
> Stack level 0, frame at 0x7fff421f01f0:
> rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
> (I_Continuation.h:146); saved rip 0x6f5830
> called by frame at 0x7fff421f0260
> source language c++.
> Arglist at 0x7fff421f01e0, args: this=0x2aaab00615b0, event=2,
> data=0x2aaab00d1570
> Locals at 0x7fff421f01e0, Previous frame's sp is 0x7fff421f01f0
> Saved registers:
> rbp at 0x7fff421f01e0, rip at 0x7fff421f01e8
> (gdb) p this->handler
> $1 = 0xefbeaddeefbeadde, this adjustment -1171307680053154338
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-475) HTTP SM should support efficient byte range requests
[ https://issues.apache.org/jira/browse/TS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049521#comment-13049521 ] vijaya bhaskar mamidi commented on TS-475: -- Eric, i will try to get some time by this weekend and look in to this. > HTTP SM should support efficient byte range requests > > > Key: TS-475 > URL: https://issues.apache.org/jira/browse/TS-475 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Eric Balsa >Priority: Critical > Fix For: 3.1.0 > > > The cache has support for efficiently locate a particular range in the cached > object, but the HTTP SM does not support this. In order to make Range: > request efficient (particularly on large objects), the SM should support this > new cache feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
