[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