[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryo Okubo updated TS-2729:
--
Attachment: (was: cleanuped-0002.patch)
Add HTTP/2 support to ATS
-
Key: TS-2729
URL: https://issues.apache.org/jira/browse/TS-2729
Project: Traffic Server
Issue Type: New Feature
Components: HTTP/2
Reporter: Ryo Okubo
Labels: review
Fix For: 5.1.0
Attachments: draft11.patch, fix-handling-version-string.patch,
http2-0002.patch, http2-0003.patch, ts2743.patch, ts2760.patch
h2. Overview
We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
experimentally.
Now, it supports HTTP/2 draft-12.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
Our implementation similar to the SPDY implementation in ATS core(TS-2431)
but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
https://github.com/tatsuhiro-t/nghttp2
We tested NPN and ALPN negotiation.
h2. How to test it
* Install nghttp2 library, here is URL of this library:
https://github.com/tatsuhiro-t/nghttp2
* Use '--enable-http2' option to compile ATS:
{noformat}
$ ./configure --enable-http2
$ make all make install
{noformat}
* You can use '--with-openssl=dir' option.
* Need not configure anything if you just want to test HTTP/2 without SSL.
The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
requests.
* You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
for example:
{noformat}
# HTTP/2 without SSL
$ nghttp -v http://localhost/b.txt
# HTTP/2 + SSL
$ nghttp -v https://localhost/b.txt
{noformat}
h2. TODO
* -Cleanup codes.-
* Follow -http2 draft-12- and later.
* -Support ALPN.-
* Add settings related to HTTP/2 into records.config.
** it'll refer to configuration settings for SPDY on TS-2740
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryo Okubo updated TS-2729:
--
Attachment: (was: draft12.patch)
Add HTTP/2 support to ATS
-
Key: TS-2729
URL: https://issues.apache.org/jira/browse/TS-2729
Project: Traffic Server
Issue Type: New Feature
Components: HTTP/2
Reporter: Ryo Okubo
Labels: review
Fix For: 5.1.0
Attachments: draft11.patch, fix-handling-version-string.patch,
http2-0002.patch, http2-0003.patch, ts2743.patch, ts2760.patch
h2. Overview
We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
experimentally.
Now, it supports HTTP/2 draft-12.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
Our implementation similar to the SPDY implementation in ATS core(TS-2431)
but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
https://github.com/tatsuhiro-t/nghttp2
We tested NPN and ALPN negotiation.
h2. How to test it
* Install nghttp2 library, here is URL of this library:
https://github.com/tatsuhiro-t/nghttp2
* Use '--enable-http2' option to compile ATS:
{noformat}
$ ./configure --enable-http2
$ make all make install
{noformat}
* You can use '--with-openssl=dir' option.
* Need not configure anything if you just want to test HTTP/2 without SSL.
The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
requests.
* You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
for example:
{noformat}
# HTTP/2 without SSL
$ nghttp -v http://localhost/b.txt
# HTTP/2 + SSL
$ nghttp -v https://localhost/b.txt
{noformat}
h2. TODO
* -Cleanup codes.-
* Follow -http2 draft-12- and later.
* -Support ALPN.-
* Add settings related to HTTP/2 into records.config.
** it'll refer to configuration settings for SPDY on TS-2740
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryo Okubo updated TS-2729:
--
Attachment: (was: http2-0001.patch)
Add HTTP/2 support to ATS
-
Key: TS-2729
URL: https://issues.apache.org/jira/browse/TS-2729
Project: Traffic Server
Issue Type: New Feature
Components: HTTP/2
Reporter: Ryo Okubo
Labels: review
Fix For: 5.1.0
Attachments: draft11.patch, fix-handling-version-string.patch,
http2-0002.patch, http2-0003.patch, ts2743.patch, ts2760.patch
h2. Overview
We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
experimentally.
Now, it supports HTTP/2 draft-12.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
Our implementation similar to the SPDY implementation in ATS core(TS-2431)
but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
https://github.com/tatsuhiro-t/nghttp2
We tested NPN and ALPN negotiation.
h2. How to test it
* Install nghttp2 library, here is URL of this library:
https://github.com/tatsuhiro-t/nghttp2
* Use '--enable-http2' option to compile ATS:
{noformat}
$ ./configure --enable-http2
$ make all make install
{noformat}
* You can use '--with-openssl=dir' option.
* Need not configure anything if you just want to test HTTP/2 without SSL.
The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
requests.
* You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
for example:
{noformat}
# HTTP/2 without SSL
$ nghttp -v http://localhost/b.txt
# HTTP/2 + SSL
$ nghttp -v https://localhost/b.txt
{noformat}
h2. TODO
* -Cleanup codes.-
* Follow -http2 draft-12- and later.
* -Support ALPN.-
* Add settings related to HTTP/2 into records.config.
** it'll refer to configuration settings for SPDY on TS-2740
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2878) Core dump in mime_field_print
[
https://issues.apache.org/jira/browse/TS-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027289#comment-14027289
]
Sudheer Vinukonda edited comment on TS-2878 at 6/11/14 4:00 PM:
Indeed, [~briang] - [~bcall] mentioned that you found the possible cause to be
related to TS-2837. That's great to hear - thanks for the help! Could you also
please update the tests to cover the printed string?
was (Author: sudheerv):
Indeed, [~briang], [~bcall] mentioned that you found the possible cause to be
related to TS-2837. That's great to hear - thanks for the help! Could you also
please update the tests to cover the printed string?
Core dump in mime_field_print
-
Key: TS-2878
URL: https://issues.apache.org/jira/browse/TS-2878
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.0.0
Reporter: Sudheer Vinukonda
Found a new core dump on one of our production hosts with the latest master.
{code}
(gdb)
#0 0x00366a489932 in memcpy () from /lib64/libc.so.6
#1 0x006440ec in mime_field_print (field=0x2ad0c12eb398,
buf_start=0x2ad0ccddf6fc
b=4d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--s=l0i=jE4n8cjO._g4wBfgSzBR;
F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-b=pfgj;
Y=v=1n=3kntebmsf6jf7l=43m0h3.2705544@..., buf_length=4096,
buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
MIME.cc:2745
#2 0x0064422c in mime_hdr_print (mh=value optimized out,
buf_start=0x2ad0ccddf000 POST
/w/ygo-mail/msgedit.bp?ci=1.ts=1401981151_httpHost=m.yahoo.com.intl=MX.lang=es-mx
HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La..., buf_length=4096,
buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
MIME.cc:2623
#3 0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010,
hdr=0x2ad0c12eb098,
buf=0x2ad0ccddf000 POST
/w/ygo-mail/msgedit.bp?ci=1.ts=1401981151_httpHost=m.yahoo.com.intl=MX.lang=es-mx
HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La..., bufsize=4096,
bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
#4 0x0059c676 in print (this=value optimized out,
h=0x2acf6e0e8548, b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
#5 HttpSM::write_header_into_buffer (this=value optimized out,
h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
#6 0x0059e9bb in HttpSM::setup_server_send_request
(this=0x2acf6e0e7dc0) at HttpSM.cc:5576
#7 0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
HttpSM.cc:1508
#8 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
event=6, data=0x0) at HttpSM.cc:1437
#9 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
event=6, data=0x0) at HttpSM.cc:1255
#10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
#11 0x2acf12d247fc in http_hook (contp=value optimized out,
event=value optimized out, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
#12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
event=value optimized out, data=value optimized out) at HttpSM.cc:1362
#13 0x005a618b in HttpSM::state_http_server_open
(this=0x2acf6e0e7dc0, event=value optimized out, data=0x2ad0b88802d0) at
HttpSM.cc:1643
#14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0,
event=200, data=0x2ad0b88802d0) at HttpSM.cc:2501
#15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t=value
optimized out, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
#16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t=value optimized
out, fd=-1) at UnixNetVConnection.cc:1159
#17 0x0070d01f in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=value optimized out, target=value optimized out,
opt=0x2acf1cd09e00,
servername=0x2ad0b88804fc \002) at UnixNetProcessor.cc:255
#18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:87
#19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw=value optimized
out) at HttpSM.cc:4646
#20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at
HttpSM.cc:6975
#21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
HttpSM.cc:1505
#22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
event=6, data=0x0) at HttpSM.cc:1437
#23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
event=6, data=0x0) at HttpSM.cc:1255
#24
[jira] [Comment Edited] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026582#comment-14026582
]
Sudheer Vinukonda edited comment on TS-2883 at 6/11/14 4:19 PM:
With this version that's running commits before June 3, 2014 (and TS-2766
reverted), don't see the core dump in SpdyNV::SpdyNV anymore, but, see a
couple of other kinds of cores (one on each prod host). TS-2882 tracks one core
and the second core has the below stack trace from gdb:
{code}
(gdb) bt
#0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
#1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at ../lib/ts/Allocator.h:117
#2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at InkAPI.cc:7289
#3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
#4 0x005f1faa in spdy_process_syn_stream_frame (session=value
optimized out, type=value optimized out, frame=value optimized out,
user_data=0x2b86821e2120)
at SpdyCallbacks.cc:295
#5 spdy_on_ctrl_recv_callback (session=value optimized out, type=value
optimized out, frame=value optimized out, user_data=0x2b86821e2120) at
SpdyCallbacks.cc:335
#6 0x00738050 in spdylay_session_on_syn_stream_received
(session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
#7 0x00738d57 in spdylay_session_process_ctrl_frame
(session=0x2b865defce10, in=0x2b858f987a90 \200\003, inlen=value optimized
out) at spdylay_session.c:2246
#8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
\200\003, inlen=value optimized out) at spdylay_session.c:2805
#9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
spdylay_session.c:2828
#10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
edata=value optimized out) at SpdyClientSession.cc:279
#11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120, event=100,
edata=value optimized out) at SpdyClientSession.cc:236
#12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event=value
optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 read_signal_and_update (this=0x2b86fc1d2cf0, event=value optimized out)
at UnixNetVConnection.cc:138
#14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0, event=value
optimized out) at UnixNetVConnection.cc:914
#15 0x006fe66f in SSLNetVConnection::net_read_io (this=0x2b86fc1d2cf0,
nh=0x2b858d46bbf0, lthread=0x2b858d468010) at SSLNetVConnection.cc:294
#16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
event=value optimized out, e=value optimized out) at UnixNet.cc:399
#17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
calling_code=5) at I_Continuation.h:146
#18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
at UnixEThread.cc:145
#19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
UnixEThread.cc:269
#20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
#21 0x2b835bf28851 in start_thread () from /lib64/libpthread.so.0
#22 0x00361a0e894d in clone () from /lib64/libc.so.6
{code}
was (Author: sudheerv):
With this version that's running commits before June 3, 2014 (and TS-2766
reverted), don't see the core dump in SpdyNV::SpdyNV anymore, but, see a
couple of other kinds of cores (one on each prod host). Below are the stack
traces from gdb:
{code}
(gdb) bt
#0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
#1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at ../lib/ts/Allocator.h:117
#2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
[jira] [Commented] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027969#comment-14027969
]
Sudheer Vinukonda commented on TS-2883:
---
Looking at the core in gdb, it looks like item.s.pointer is pointing to garbage
- it may not have been reset correctly somewhere.
(gdb) print next
$1 = {s = {pointer = 0x2aae9fe8a7df, version = 233745007561}, data =
0x00366c49c3c92aae9fe8a7df}
(gdb) print item
$2 = {s = {pointer = 0x10ec8348fb894853, version = 13644476}, data =
0x00d032bc10ec8348fb894853}
(gdb) print item.s.pointer
$3 = (void *) 0x10ec8348fb894853
(gdb) print next.s.pointer
$6 = (void *) 0x2aae9fe8a7df
(gdb) x 0x10ec8348fb894853
0x10ec8348fb894853: Cannot access memory at address 0x10ec8348fb894853
(gdb) x 0x2aae9fe8a7df
0x2aae9fe8a7df: 0x3df9e800
(gdb)
core dump in TSFetchCreate()
Key: TS-2883
URL: https://issues.apache.org/jira/browse/TS-2883
Project: Traffic Server
Issue Type: Bug
Components: Core, SPDY
Reporter: Sudheer Vinukonda
{code}
(gdb) bt
#0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
#1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at ../lib/ts/Allocator.h:117
#2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at InkAPI.cc:7289
#3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
#4 0x005f1faa in spdy_process_syn_stream_frame (session=value
optimized out, type=value optimized out, frame=value optimized out,
user_data=0x2b86821e2120)
at SpdyCallbacks.cc:295
#5 spdy_on_ctrl_recv_callback (session=value optimized out, type=value
optimized out, frame=value optimized out, user_data=0x2b86821e2120) at
SpdyCallbacks.cc:335
#6 0x00738050 in spdylay_session_on_syn_stream_received
(session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
#7 0x00738d57 in spdylay_session_process_ctrl_frame
(session=0x2b865defce10, in=0x2b858f987a90 \200\003, inlen=value optimized
out) at spdylay_session.c:2246
#8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
\200\003, inlen=value optimized out) at spdylay_session.c:2805
#9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
spdylay_session.c:2828
#10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
edata=value optimized out) at SpdyClientSession.cc:279
#11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120,
event=100, edata=value optimized out) at SpdyClientSession.cc:236
#12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event=value
optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 read_signal_and_update (this=0x2b86fc1d2cf0, event=value optimized out)
at UnixNetVConnection.cc:138
#14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0,
event=value optimized out) at UnixNetVConnection.cc:914
#15 0x006fe66f in SSLNetVConnection::net_read_io
(this=0x2b86fc1d2cf0, nh=0x2b858d46bbf0, lthread=0x2b858d468010) at
SSLNetVConnection.cc:294
#16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
event=value optimized out, e=value optimized out) at UnixNet.cc:399
#17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
calling_code=5) at I_Continuation.h:146
#18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
at UnixEThread.cc:145
#19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
UnixEThread.cc:269
#20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
#21 0x2b835bf28851 in start_thread () from /lib64/libpthread.so.0
#22 0x00361a0e894d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2884) TSActionCancel() on TSNetAccept() causes spinning thread
[ https://issues.apache.org/jira/browse/TS-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028008#comment-14028008 ] James Peach commented on TS-2884: - We should be able to make a regression rest for this, either using the internal test infrastructure, or an example plugin that can be used for an integration test. TSActionCancel() on TSNetAccept() causes spinning thread Key: TS-2884 URL: https://issues.apache.org/jira/browse/TS-2884 Project: Traffic Server Issue Type: Bug Components: Network Reporter: William Bardwell It looks like the NetAccept::acceptLoopEvent() just loops calling do_blocking_accept() and doesn't check for an error return value... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2884) TSActionCancel() on TSNetAccept() causes spinning thread
[ https://issues.apache.org/jira/browse/TS-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-2884: - Priority: Minor (was: Major) TSActionCancel() on TSNetAccept() causes spinning thread Key: TS-2884 URL: https://issues.apache.org/jira/browse/TS-2884 Project: Traffic Server Issue Type: Bug Components: Network Reporter: William Bardwell Priority: Minor It looks like the NetAccept::acceptLoopEvent() just loops calling do_blocking_accept() and doesn't check for an error return value... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028039#comment-14028039
]
Sudheer Vinukonda commented on TS-2883:
---
A couple of interesting things -
1. Find a lot of these error logs from the production hosts.
[May 8 23:28:13.461] Server {0x2b1d88a09700} ERROR: req null in SpdSM::clear
2. Wondering if some checking may need to be added in the below code to ensure
a req object is released from the req_map before storing a new req object.
{code}
case SPDYLAY_SYN_STREAM:
stream_id = frame-syn_stream.stream_id;
req = spdyRequestAllocator.alloc();
req-init(sm, stream_id);
req-append_nv(frame-syn_stream.nv);
sm-req_map[stream_id] = req;
spdy_process_syn_stream_frame(sm, req);
break;
{code}
So, adding the below debug code to test further.
if (sm-req_map[stream_id] != 0) {
SpdyRequest *dangling_req = sm-req_map[stream_id];
Error(spdy_on_ctrl_recv_callback - dangling req for sm_id %u, stream_id
%u, %u - url %s, %s - req time %lld, %lld,
sm-sm_id, stream_id, dangling_req-stream_id, req-url.c_str(),
dangling_req-url.c_str(),
req-start_time, dangling_req-start_time);
dangling_req-clear();
spdyRequestAllocator.free(dangling_req);
}
core dump in TSFetchCreate()
Key: TS-2883
URL: https://issues.apache.org/jira/browse/TS-2883
Project: Traffic Server
Issue Type: Bug
Components: Core, SPDY
Reporter: Sudheer Vinukonda
{code}
(gdb) bt
#0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
#1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at ../lib/ts/Allocator.h:117
#2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at InkAPI.cc:7289
#3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
#4 0x005f1faa in spdy_process_syn_stream_frame (session=value
optimized out, type=value optimized out, frame=value optimized out,
user_data=0x2b86821e2120)
at SpdyCallbacks.cc:295
#5 spdy_on_ctrl_recv_callback (session=value optimized out, type=value
optimized out, frame=value optimized out, user_data=0x2b86821e2120) at
SpdyCallbacks.cc:335
#6 0x00738050 in spdylay_session_on_syn_stream_received
(session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
#7 0x00738d57 in spdylay_session_process_ctrl_frame
(session=0x2b865defce10, in=0x2b858f987a90 \200\003, inlen=value optimized
out) at spdylay_session.c:2246
#8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
\200\003, inlen=value optimized out) at spdylay_session.c:2805
#9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
spdylay_session.c:2828
#10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
edata=value optimized out) at SpdyClientSession.cc:279
#11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120,
event=100, edata=value optimized out) at SpdyClientSession.cc:236
#12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event=value
optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 read_signal_and_update (this=0x2b86fc1d2cf0, event=value optimized out)
at UnixNetVConnection.cc:138
#14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0,
event=value optimized out) at UnixNetVConnection.cc:914
#15 0x006fe66f in SSLNetVConnection::net_read_io
(this=0x2b86fc1d2cf0, nh=0x2b858d46bbf0, lthread=0x2b858d468010) at
SSLNetVConnection.cc:294
#16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
event=value optimized out, e=value optimized out) at UnixNet.cc:399
#17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
calling_code=5) at I_Continuation.h:146
#18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
at UnixEThread.cc:145
#19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
UnixEThread.cc:269
#20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
#21
[jira] [Comment Edited] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028039#comment-14028039
]
Sudheer Vinukonda edited comment on TS-2883 at 6/11/14 5:24 PM:
A couple of interesting things -
1. Find a lot of these error logs from the production hosts.
[May 8 23:28:13.461] Server {0x2b1d88a09700} ERROR: req null in SpdSM::clear
2. Wondering if some checking may need to be added in the below code to ensure
a req object is released from the req_map before storing a new req object.
{code}
case SPDYLAY_SYN_STREAM:
stream_id = frame-syn_stream.stream_id;
req = spdyRequestAllocator.alloc();
req-init(sm, stream_id);
req-append_nv(frame-syn_stream.nv);
sm-req_map[stream_id] = req;
spdy_process_syn_stream_frame(sm, req);
break;
{code}
So, adding the below debug code to test further.
{code}
if (sm-req_map[stream_id] != 0) {
SpdyRequest *dangling_req = sm-req_map[stream_id];
Error(spdy_on_ctrl_recv_callback - dangling req for sm_id %u, stream_id
%u, %u - url %s, %s - req time %lld, %lld,
sm-sm_id, stream_id, dangling_req-stream_id, req-url.c_str(),
dangling_req-url.c_str(),
req-start_time, dangling_req-start_time);
dangling_req-clear();
spdyRequestAllocator.free(dangling_req);
}
{code}
was (Author: sudheerv):
A couple of interesting things -
1. Find a lot of these error logs from the production hosts.
[May 8 23:28:13.461] Server {0x2b1d88a09700} ERROR: req null in SpdSM::clear
2. Wondering if some checking may need to be added in the below code to ensure
a req object is released from the req_map before storing a new req object.
{code}
case SPDYLAY_SYN_STREAM:
stream_id = frame-syn_stream.stream_id;
req = spdyRequestAllocator.alloc();
req-init(sm, stream_id);
req-append_nv(frame-syn_stream.nv);
sm-req_map[stream_id] = req;
spdy_process_syn_stream_frame(sm, req);
break;
{code}
So, adding the below debug code to test further.
if (sm-req_map[stream_id] != 0) {
SpdyRequest *dangling_req = sm-req_map[stream_id];
Error(spdy_on_ctrl_recv_callback - dangling req for sm_id %u, stream_id
%u, %u - url %s, %s - req time %lld, %lld,
sm-sm_id, stream_id, dangling_req-stream_id, req-url.c_str(),
dangling_req-url.c_str(),
req-start_time, dangling_req-start_time);
dangling_req-clear();
spdyRequestAllocator.free(dangling_req);
}
core dump in TSFetchCreate()
Key: TS-2883
URL: https://issues.apache.org/jira/browse/TS-2883
Project: Traffic Server
Issue Type: Bug
Components: Core, SPDY
Reporter: Sudheer Vinukonda
{code}
(gdb) bt
#0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
#1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at ../lib/ts/Allocator.h:117
#2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at InkAPI.cc:7289
#3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
#4 0x005f1faa in spdy_process_syn_stream_frame (session=value
optimized out, type=value optimized out, frame=value optimized out,
user_data=0x2b86821e2120)
at SpdyCallbacks.cc:295
#5 spdy_on_ctrl_recv_callback (session=value optimized out, type=value
optimized out, frame=value optimized out, user_data=0x2b86821e2120) at
SpdyCallbacks.cc:335
#6 0x00738050 in spdylay_session_on_syn_stream_received
(session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
#7 0x00738d57 in spdylay_session_process_ctrl_frame
(session=0x2b865defce10, in=0x2b858f987a90 \200\003, inlen=value optimized
out) at spdylay_session.c:2246
#8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
\200\003, inlen=value optimized out) at spdylay_session.c:2805
#9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
spdylay_session.c:2828
#10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
edata=value optimized out) at SpdyClientSession.cc:279
[jira] [Commented] (TS-2878) Core dump in mime_field_print
[
https://issues.apache.org/jira/browse/TS-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028069#comment-14028069
]
Brian Geffon commented on TS-2878:
--
Np, I'm not sure how the unit test could cover this specific situation, in this
case the structure of URLImpl was changed, so the unit test could never have
caught this situation. But I can add a check to prevent regressions on just
that string.
Core dump in mime_field_print
-
Key: TS-2878
URL: https://issues.apache.org/jira/browse/TS-2878
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.0.0
Reporter: Sudheer Vinukonda
Found a new core dump on one of our production hosts with the latest master.
{code}
(gdb)
#0 0x00366a489932 in memcpy () from /lib64/libc.so.6
#1 0x006440ec in mime_field_print (field=0x2ad0c12eb398,
buf_start=0x2ad0ccddf6fc
b=4d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--s=l0i=jE4n8cjO._g4wBfgSzBR;
F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-b=pfgj;
Y=v=1n=3kntebmsf6jf7l=43m0h3.2705544@..., buf_length=4096,
buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
MIME.cc:2745
#2 0x0064422c in mime_hdr_print (mh=value optimized out,
buf_start=0x2ad0ccddf000 POST
/w/ygo-mail/msgedit.bp?ci=1.ts=1401981151_httpHost=m.yahoo.com.intl=MX.lang=es-mx
HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La..., buf_length=4096,
buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
MIME.cc:2623
#3 0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010,
hdr=0x2ad0c12eb098,
buf=0x2ad0ccddf000 POST
/w/ygo-mail/msgedit.bp?ci=1.ts=1401981151_httpHost=m.yahoo.com.intl=MX.lang=es-mx
HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La..., bufsize=4096,
bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
#4 0x0059c676 in print (this=value optimized out,
h=0x2acf6e0e8548, b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
#5 HttpSM::write_header_into_buffer (this=value optimized out,
h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
#6 0x0059e9bb in HttpSM::setup_server_send_request
(this=0x2acf6e0e7dc0) at HttpSM.cc:5576
#7 0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
HttpSM.cc:1508
#8 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
event=6, data=0x0) at HttpSM.cc:1437
#9 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
event=6, data=0x0) at HttpSM.cc:1255
#10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
#11 0x2acf12d247fc in http_hook (contp=value optimized out,
event=value optimized out, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
#12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
event=value optimized out, data=value optimized out) at HttpSM.cc:1362
#13 0x005a618b in HttpSM::state_http_server_open
(this=0x2acf6e0e7dc0, event=value optimized out, data=0x2ad0b88802d0) at
HttpSM.cc:1643
#14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0,
event=200, data=0x2ad0b88802d0) at HttpSM.cc:2501
#15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t=value
optimized out, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
#16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t=value optimized
out, fd=-1) at UnixNetVConnection.cc:1159
#17 0x0070d01f in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=value optimized out, target=value optimized out,
opt=0x2acf1cd09e00,
servername=0x2ad0b88804fc \002) at UnixNetProcessor.cc:255
#18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:87
#19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw=value optimized
out) at HttpSM.cc:4646
#20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at
HttpSM.cc:6975
#21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
HttpSM.cc:1505
#22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
event=6, data=0x0) at HttpSM.cc:1437
#23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
event=6, data=0x0) at HttpSM.cc:1255
#24 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
#25 0x2acf13dd3492 in append_own_yca_certificate (txnp=0x2acf6e0e7dc0,
contp=value optimized out, data=value optimized out) at yca_plugin.cpp:266
#26
[jira] [Commented] (TS-2880) Change the permissions on traffic.out to 0644
[
https://issues.apache.org/jira/browse/TS-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028353#comment-14028353
]
ASF subversion and git services commented on TS-2880:
-
Commit 08f6e5e44a00776bc4eb4d1584d0aaa92f9df9ed in trafficserver's branch
refs/heads/master from [~yzlai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=08f6e5e ]
TS-2880 Change the permissions on traffic.out to 0644
Change the permissions on traffic.out to 0644
-
Key: TS-2880
URL: https://issues.apache.org/jira/browse/TS-2880
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Affects Versions: 5.0.0
Reporter: Bryan Call
Fix For: 5.1.0
Currently:
{code}
[bcall@homer trafficserver]$ ll /usr/local/var/log/trafficserver/traffic.out
-rw-r- 1 root root 119 Jun 5 15:18
/usr/local/var/log/trafficserver/traffic.out
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2880) Change the permissions on traffic.out to 0644
[
https://issues.apache.org/jira/browse/TS-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-2880:
--
Assignee: Bryan Call
Change the permissions on traffic.out to 0644
-
Key: TS-2880
URL: https://issues.apache.org/jira/browse/TS-2880
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Affects Versions: 5.0.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.1.0
Currently:
{code}
[bcall@homer trafficserver]$ ll /usr/local/var/log/trafficserver/traffic.out
-rw-r- 1 root root 119 Jun 5 15:18
/usr/local/var/log/trafficserver/traffic.out
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2885) luajit build ignores compiler flags
James Peach created TS-2885:
---
Summary: luajit build ignores compiler flags
Key: TS-2885
URL: https://issues.apache.org/jira/browse/TS-2885
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: James Peach
The luajit build ignores operator-supplied CFLAGS in certain circumstances,
causing the build to break. For example, if you try to build Traffic Server as
a position independent executable:
{code}
# The Q= is to get luajit to emit the complier line :-/
$ ./configure CXXFLAGS=-fPIE CFLAGS=-fPIE Q=
...
Building LuaJIT 2.0.3
make -C src
make[4]: Entering directory `/home/vagrant/trafficserver.git/lib/luajit/src'
DYNLINK libluajit.so
cc -shared -fPIC -Wl,-soname,libluajit-5.1.so.2 -o libluajit.so lj_vm_dyn.o
lj_gc_dyn.o lj_err_dyn.o lj_char_dyn.o lj_bc_dyn.o lj_obj_dyn.o lj_str_dyn.o
lj_tab_dyn.o lj_func_dyn.o lj_udata_dyn.o lj_meta_dyn.o lj_debug_dyn.o
lj_state_dyn.o lj_dispatch_dyn.o lj_vmevent_dyn.o lj_vmmath_dyn.o
lj_strscan_dyn.o lj_api_dyn.o lj_lex_dyn.o lj_parse_dyn.o lj_bcread_dyn.o
lj_bcwrite_dyn.o lj_load_dyn.o lj_ir_dyn.o lj_opt_mem_dyn.o lj_opt_fold_dyn.o
lj_opt_narrow_dyn.o lj_opt_dce_dyn.o lj_opt_loop_dyn.o lj_opt_split_dyn.o
lj_opt_sink_dyn.o lj_mcode_dyn.o lj_snap_dyn.o lj_record_dyn.o lj_crecord_dyn.o
lj_ffrecord_dyn.o lj_asm_dyn.o lj_trace_dyn.o lj_gdbjit_dyn.o lj_ctype_dyn.o
lj_cdata_dyn.o lj_cconv_dyn.o lj_ccall_dyn.o lj_ccallback_dyn.o lj_carith_dyn.o
lj_clib_dyn.o lj_cparse_dyn.o lj_lib_dyn.o lj_alloc_dyn.o lib_aux_dyn.o
lib_base_dyn.o lib_math_dyn.o lib_bit_dyn.o lib_string_dyn.o lib_table_dyn.o
lib_io_dyn.o lib_os_dyn.o lib_package_dyn.o lib_debug_dyn.o lib_jit_dyn.o
lib_ffi_dyn.o lib_init_dyn.o -lm -ldl
/usr/bin/ld: lj_err_dyn.o: relocation R_X86_64_TPOFF32 against `static_uex' can
not be used when making a shared object; recompile with -fPIC
lj_err_dyn.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
{code}
Note that it used {{-fPIC}} instead of {{-fPIE}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2885) luajit build ignores compiler flags
[
https://issues.apache.org/jira/browse/TS-2885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028497#comment-14028497
]
James Peach commented on TS-2885:
-
It would be helpful to have a {{--disable-luajit}} option so that users can
work around this kind of build problem.
luajit build ignores compiler flags
---
Key: TS-2885
URL: https://issues.apache.org/jira/browse/TS-2885
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: James Peach
The luajit build ignores operator-supplied CFLAGS in certain circumstances,
causing the build to break. For example, if you try to build Traffic Server
as a position independent executable:
{code}
# The Q= is to get luajit to emit the complier line :-/
$ ./configure CXXFLAGS=-fPIE CFLAGS=-fPIE Q=
...
Building LuaJIT 2.0.3
make -C src
make[4]: Entering directory `/home/vagrant/trafficserver.git/lib/luajit/src'
DYNLINK libluajit.so
cc -shared -fPIC -Wl,-soname,libluajit-5.1.so.2 -o libluajit.so
lj_vm_dyn.o lj_gc_dyn.o lj_err_dyn.o lj_char_dyn.o lj_bc_dyn.o lj_obj_dyn.o
lj_str_dyn.o lj_tab_dyn.o lj_func_dyn.o lj_udata_dyn.o lj_meta_dyn.o
lj_debug_dyn.o lj_state_dyn.o lj_dispatch_dyn.o lj_vmevent_dyn.o
lj_vmmath_dyn.o lj_strscan_dyn.o lj_api_dyn.o lj_lex_dyn.o lj_parse_dyn.o
lj_bcread_dyn.o lj_bcwrite_dyn.o lj_load_dyn.o lj_ir_dyn.o lj_opt_mem_dyn.o
lj_opt_fold_dyn.o lj_opt_narrow_dyn.o lj_opt_dce_dyn.o lj_opt_loop_dyn.o
lj_opt_split_dyn.o lj_opt_sink_dyn.o lj_mcode_dyn.o lj_snap_dyn.o
lj_record_dyn.o lj_crecord_dyn.o lj_ffrecord_dyn.o lj_asm_dyn.o
lj_trace_dyn.o lj_gdbjit_dyn.o lj_ctype_dyn.o lj_cdata_dyn.o lj_cconv_dyn.o
lj_ccall_dyn.o lj_ccallback_dyn.o lj_carith_dyn.o lj_clib_dyn.o
lj_cparse_dyn.o lj_lib_dyn.o lj_alloc_dyn.o lib_aux_dyn.o lib_base_dyn.o
lib_math_dyn.o lib_bit_dyn.o lib_string_dyn.o lib_table_dyn.o lib_io_dyn.o
lib_os_dyn.o lib_package_dyn.o lib_debug_dyn.o lib_jit_dyn.o lib_ffi_dyn.o
lib_init_dyn.o -lm -ldl
/usr/bin/ld: lj_err_dyn.o: relocation R_X86_64_TPOFF32 against `static_uex'
can not be used when making a shared object; recompile with -fPIC
lj_err_dyn.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
{code}
Note that it used {{-fPIC}} instead of {{-fPIE}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2885) luajit build ignores compiler flags
[
https://issues.apache.org/jira/browse/TS-2885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028497#comment-14028497
]
James Peach edited comment on TS-2885 at 6/11/14 10:30 PM:
---
It would be helpful to have a {{--disable-luajit}} option so that users can
work around this kind of build problem. Alternatively (or in addition),
{{--with-luajit}} to ask the build to use the LuaJIT from the OS rather than
the bundled copy.
was (Author: jamespeach):
It would be helpful to have a {{--disable-luajit}} option so that users can
work around this kind of build problem.
luajit build ignores compiler flags
---
Key: TS-2885
URL: https://issues.apache.org/jira/browse/TS-2885
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: James Peach
The luajit build ignores operator-supplied CFLAGS in certain circumstances,
causing the build to break. For example, if you try to build Traffic Server
as a position independent executable:
{code}
# The Q= is to get luajit to emit the complier line :-/
$ ./configure CXXFLAGS=-fPIE CFLAGS=-fPIE Q=
...
Building LuaJIT 2.0.3
make -C src
make[4]: Entering directory `/home/vagrant/trafficserver.git/lib/luajit/src'
DYNLINK libluajit.so
cc -shared -fPIC -Wl,-soname,libluajit-5.1.so.2 -o libluajit.so
lj_vm_dyn.o lj_gc_dyn.o lj_err_dyn.o lj_char_dyn.o lj_bc_dyn.o lj_obj_dyn.o
lj_str_dyn.o lj_tab_dyn.o lj_func_dyn.o lj_udata_dyn.o lj_meta_dyn.o
lj_debug_dyn.o lj_state_dyn.o lj_dispatch_dyn.o lj_vmevent_dyn.o
lj_vmmath_dyn.o lj_strscan_dyn.o lj_api_dyn.o lj_lex_dyn.o lj_parse_dyn.o
lj_bcread_dyn.o lj_bcwrite_dyn.o lj_load_dyn.o lj_ir_dyn.o lj_opt_mem_dyn.o
lj_opt_fold_dyn.o lj_opt_narrow_dyn.o lj_opt_dce_dyn.o lj_opt_loop_dyn.o
lj_opt_split_dyn.o lj_opt_sink_dyn.o lj_mcode_dyn.o lj_snap_dyn.o
lj_record_dyn.o lj_crecord_dyn.o lj_ffrecord_dyn.o lj_asm_dyn.o
lj_trace_dyn.o lj_gdbjit_dyn.o lj_ctype_dyn.o lj_cdata_dyn.o lj_cconv_dyn.o
lj_ccall_dyn.o lj_ccallback_dyn.o lj_carith_dyn.o lj_clib_dyn.o
lj_cparse_dyn.o lj_lib_dyn.o lj_alloc_dyn.o lib_aux_dyn.o lib_base_dyn.o
lib_math_dyn.o lib_bit_dyn.o lib_string_dyn.o lib_table_dyn.o lib_io_dyn.o
lib_os_dyn.o lib_package_dyn.o lib_debug_dyn.o lib_jit_dyn.o lib_ffi_dyn.o
lib_init_dyn.o -lm -ldl
/usr/bin/ld: lj_err_dyn.o: relocation R_X86_64_TPOFF32 against `static_uex'
can not be used when making a shared object; recompile with -fPIC
lj_err_dyn.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
{code}
Note that it used {{-fPIC}} instead of {{-fPIE}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2885) luajit build ignores compiler flags
[
https://issues.apache.org/jira/browse/TS-2885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2885:
-
Assignee: Leif Hedstrom
luajit build ignores compiler flags
---
Key: TS-2885
URL: https://issues.apache.org/jira/browse/TS-2885
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: James Peach
Assignee: Leif Hedstrom
The luajit build ignores operator-supplied CFLAGS in certain circumstances,
causing the build to break. For example, if you try to build Traffic Server
as a position independent executable:
{code}
# The Q= is to get luajit to emit the complier line :-/
$ ./configure CXXFLAGS=-fPIE CFLAGS=-fPIE Q=
...
Building LuaJIT 2.0.3
make -C src
make[4]: Entering directory `/home/vagrant/trafficserver.git/lib/luajit/src'
DYNLINK libluajit.so
cc -shared -fPIC -Wl,-soname,libluajit-5.1.so.2 -o libluajit.so
lj_vm_dyn.o lj_gc_dyn.o lj_err_dyn.o lj_char_dyn.o lj_bc_dyn.o lj_obj_dyn.o
lj_str_dyn.o lj_tab_dyn.o lj_func_dyn.o lj_udata_dyn.o lj_meta_dyn.o
lj_debug_dyn.o lj_state_dyn.o lj_dispatch_dyn.o lj_vmevent_dyn.o
lj_vmmath_dyn.o lj_strscan_dyn.o lj_api_dyn.o lj_lex_dyn.o lj_parse_dyn.o
lj_bcread_dyn.o lj_bcwrite_dyn.o lj_load_dyn.o lj_ir_dyn.o lj_opt_mem_dyn.o
lj_opt_fold_dyn.o lj_opt_narrow_dyn.o lj_opt_dce_dyn.o lj_opt_loop_dyn.o
lj_opt_split_dyn.o lj_opt_sink_dyn.o lj_mcode_dyn.o lj_snap_dyn.o
lj_record_dyn.o lj_crecord_dyn.o lj_ffrecord_dyn.o lj_asm_dyn.o
lj_trace_dyn.o lj_gdbjit_dyn.o lj_ctype_dyn.o lj_cdata_dyn.o lj_cconv_dyn.o
lj_ccall_dyn.o lj_ccallback_dyn.o lj_carith_dyn.o lj_clib_dyn.o
lj_cparse_dyn.o lj_lib_dyn.o lj_alloc_dyn.o lib_aux_dyn.o lib_base_dyn.o
lib_math_dyn.o lib_bit_dyn.o lib_string_dyn.o lib_table_dyn.o lib_io_dyn.o
lib_os_dyn.o lib_package_dyn.o lib_debug_dyn.o lib_jit_dyn.o lib_ffi_dyn.o
lib_init_dyn.o -lm -ldl
/usr/bin/ld: lj_err_dyn.o: relocation R_X86_64_TPOFF32 against `static_uex'
can not be used when making a shared object; recompile with -fPIC
lj_err_dyn.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
{code}
Note that it used {{-fPIC}} instead of {{-fPIE}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2880) Change the permissions on traffic.out to 0644
[
https://issues.apache.org/jira/browse/TS-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028612#comment-14028612
]
ASF GitHub Bot commented on TS-2880:
Github user yzlai closed the pull request at:
https://github.com/apache/trafficserver/pull/94
Change the permissions on traffic.out to 0644
-
Key: TS-2880
URL: https://issues.apache.org/jira/browse/TS-2880
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Affects Versions: 5.0.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.1.0
Currently:
{code}
[bcall@homer trafficserver]$ ll /usr/local/var/log/trafficserver/traffic.out
-rw-r- 1 root root 119 Jun 5 15:18
/usr/local/var/log/trafficserver/traffic.out
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
