[jira] [Created] (TS-4919) traffic_ctl ignores records.config and environment variables
Jason Kenny created TS-4919: --- Summary: traffic_ctl ignores records.config and environment variables Key: TS-4919 URL: https://issues.apache.org/jira/browse/TS-4919 Project: Traffic Server Issue Type: Bug Reporter: Jason Kenny traffic_ctrl does not process values for custom directory layout that can be set in records.config or via environment variables. This prevents traffic_ctl from being used correctly in such setups. What is worse is that it make it harder to correctly test traffic server as runtime sandboxes are ignored. The only value it does respond to is TS_ROOT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4901) PROXY_CONFIG_LOCAL_STATE_DIR is not documented
Jason Kenny created TS-4901: --- Summary: PROXY_CONFIG_LOCAL_STATE_DIR is not documented Key: TS-4901 URL: https://issues.apache.org/jira/browse/TS-4901 Project: Traffic Server Issue Type: Bug Reporter: Jason Kenny PROXY_CONFIG_LOCAL_STATE_DIR or the traffic_layout value for RUNTIMEDIR is not documented. I had to find the magic value for the all knowing AMC to get testing to work better. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4868) latest master requires config value in file
Jason Kenny created TS-4868: --- Summary: latest master requires config value in file Key: TS-4868 URL: https://issues.apache.org/jira/browse/TS-4868 Project: Traffic Server Issue Type: Bug Reporter: Jason Kenny <1473896704.> [FATAL]: could not find integer variable proxy.local.cluster.type in records.config This is a regression. Our configuration system allows for defaults to be defined. records.config needs to stay optional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4152) Build failure when curses is not available
[
https://issues.apache.org/jira/browse/TS-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468893#comment-15468893
]
Jason Kenny commented on TS-4152:
-
Ignore previous comments. I did not process this correctly. This is about not
having ncurses installed and getting a build failure. I was under the
understanding that it was and it did not link.
I looked more into this and there seems to be a bug in AX_WITH_CURSES in which
it prints that warning but does not set ax_cv_curses to no ( it stays a yes
value)
I have a fix to address this, will update once pull request is done
> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
> Labels: newbie
> Fix For: 7.0.0
>
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
> CXX traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header
> file required"
> #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not
> available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2583) Invalid argument for option '-m when compiling with Intel compilers
[ https://issues.apache.org/jira/browse/TS-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431468#comment-15431468 ] Jason Kenny commented on TS-2583: - icc going to use it if it can without you asking. The issue with gcc was if you build on a vm it might know it can add it. Newer gcc shouldn't need this added. > Invalid argument for option '-m when compiling with Intel compilers > > > Key: TS-2583 > URL: https://issues.apache.org/jira/browse/TS-2583 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom >Assignee: Jason Kenny > Labels: newbie > Fix For: 7.1.0 > > > This is because of the -mcx16 that gets added. That really should be done (I > think?) only when the compiler supports it (e.g. gcc). The 128-bit CAS seems > to work in ICC without this option (obviously it doesn't support / use the > option). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4027) Incorrect usage of mmap
[
https://issues.apache.org/jira/browse/TS-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431441#comment-15431441
]
Jason Kenny commented on TS-4027:
-
I think we can close this issue. From what I can tell the issue this was
causing is resolved.
> Incorrect usage of mmap
> ---
>
> Key: TS-4027
> URL: https://issues.apache.org/jira/browse/TS-4027
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 6.0.0
>Reporter: Jason Kenny
>Assignee: Jason Kenny
> Fix For: 7.0.0
>
>
> The specific type of the crash caused by this failure (whether it is the
> SCT_SetReg assertion, or Unexpected memory deallocation error) is pretty
> random.
> This is because the crash is caused by the application’s problematic/buggy
> behavior in a way I’ll describe below.
> This is a trace of the syscalls invoked by traffic_server as generated with
> strace (running without Pin) - I highlighted the important syscalls:
> open("/tmp/yts/var/trafficserver/host.db", O_RDWR|O_CREAT, 0644) = 118
> fstat(118, {st_mode=S_IFREG|0644, st_size=25935872, ...}) = 0
> open("/dev/zero", O_RDONLY) = 119
> 1. mmap(NULL, 25935872, PROT_READ, MAP_SHARED|MAP_NORESERVE, 119, 0) =
> 0x7fffef935000
> 2. munmap(0x7fffef935000, 25935872) = 0
> 3. mmap(0x7fffef935000, 966656, PROT_READ|PROT_WRITE,
> MAP_SHARED|MAP_FIXED|MAP_NORESERVE, 118, 0) = 0x7fffef935000
> mmap(0x7fffefa21000, 7675904, PROT_READ|PROT_WRITE,
> MAP_SHARED|MAP_FIXED|MAP_NORESERVE, 118, 0xec000) = 0x7fffefa21000
> mmap(0x70173000, 17285120, PROT_READ|PROT_WRITE,
> MAP_SHARED|MAP_FIXED|MAP_NORESERVE, 118, 0x83e000) = 0x70173000
> mmap(0x711ef000, 8192, PROT_READ|PROT_WRITE,
> MAP_SHARED|MAP_FIXED|MAP_NORESERVE, 118, 0x18ba000) = 0x711ef000
> close(119) = 0
> close(118) = 0
> 1. You can see that the application is first calling mmap with “addr”
> argument equal to NULL in order to get a memory region that covers the whole
> region requested for mapping of the file host.db (25935872 bytes).
> 2. The application unmaps the allocated region (at address
> 0x7fffef935000), but remembers this region as a “free” region.
> 3. Then, the application tries to mmap each region of the file to
> addresses inside the region (from step 1) that it considers as “free”. These
> mmaps are called with the MAP_FIXED flag – meaning that if there is already a
> memory mapped in the requested region then the kernel should still map the
> requested memory in a way that the already mapped region will be discarded
> (zeroed).
>
> As you probably guess, Between step 2 and 3 Pin is asking the OS to allocate
> memory for its own purpose and get some memory inside the unmapped region
> that the application considers as “free”.
> This will cause the mapping in step 3 to overwrite Pin’s memory and corrupt
> it – leading to this crash.
> This is a bug in the application (traffic_server) that needs to be fixed.
> In a multi-threaded environment (traffic_server is multi-threaded) another
> thread can request memory mapping (by mmap) between step 2 and 3, and get a
> memory region that intersects with the problematic region.
> This allocated memory will eventually be corrupted.
> You don’t need Pin and dynamic instrumentation environment in order to
> reproduce this bug!
>
> BTW, the application call-stack of this crash, as reported by Inspector is:
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4114) ASAN based build fails with gcc 5
[ https://issues.apache.org/jira/browse/TS-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15424999#comment-15424999 ] Jason Kenny commented on TS-4114: - What? It reproduces easy. Did you build the c code with ASAN or did you skip that step hoping it would be good enough? > ASAN based build fails with gcc 5 > - > > Key: TS-4114 > URL: https://issues.apache.org/jira/browse/TS-4114 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Jason Kenny >Assignee: Jason Kenny > Labels: ASAN > > When building with gcc 5.x and asan on, the build will fail with memory leak > issues in lua. > ==1442==ERROR: LeakSanitizer: detected memory leaks > Direct leak of 4112 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c8d in build_code host/buildvm.c:204 > #2 0x407c8d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 1304 byte(s) in 1 object(s) allocated from: > #0 0x47fa51 in calloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47fa51) > #1 0x405666 in build_code host/buildvm.c:177 > #2 0x405666 in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 372 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407cae in build_code host/buildvm.c:206 > #2 0x407cae in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 296 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x40568d in build_code host/buildvm.c:182 > #2 0x40568d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 16 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c58 in sym_decorate host/buildvm.c:122 > #2 0x407c58 in build_code host/buildvm.c:203 > #3 0x407c58 in main host/buildvm.c:446 > #4 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 14758 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407bbc in build_code host/buildvm.c:199 > #2 0x407bbc in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 2425 byte(s) in 156 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407ed5 in build_code host/buildvm.c:230 > #4 0x407ed5 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1082 byte(s) in 93 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407e72 in build_code host/buildvm.c:217 > #4 0x407e72 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 525 byte(s) in 37 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b4722 in sym_decorate host/buildvm.c:122 > #2 0x4b4722 in collect_reloc host/buildvm.c:140 > #3 0x4b4722 in dasm_encode ../dynasm/dasm_x86.h:425 > #4 0x407bce in build_code host/buildvm.c:200 > #5 0x407bce in main host/buildvm.c:446 > #6 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407fc9 in build_code host/buildvm.c:235 > #4 0x407fc9 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > SUMMARY: AddressSanitizer: 24891 byte(s) leaked in 293 allocation(s). > make[5]:
[jira] [Commented] (TS-4152) Build failure when curses is not available
[
https://issues.apache.org/jira/browse/TS-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15424990#comment-15424990
]
Jason Kenny commented on TS-4152:
-
I will need to get a centOS box to verify the same behavior as i get with RHEL
6.
The issue as I see it was that the compiler did not add some default link
flags. We had to add them manually
> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
> Labels: newbie
> Fix For: 7.0.0
>
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
> CXX traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header
> file required"
> #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not
> available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4152) Build failure when curses is not available
[
https://issues.apache.org/jira/browse/TS-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15424976#comment-15424976
]
Jason Kenny commented on TS-4152:
-
I think if you add
CURSES_LIB="-ltermcap -lcursesw"\
to the configure call it will work
> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
> Labels: newbie
> Fix For: 7.0.0
>
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
> CXX traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header
> file required"
> #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not
> available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4687) ATS fails to start in a useful way with no config files ( or miniumn set so it starts)
Jason Kenny created TS-4687:
---
Summary: ATS fails to start in a useful way with no config files (
or miniumn set so it starts)
Key: TS-4687
URL: https://issues.apache.org/jira/browse/TS-4687
Project: Traffic Server
Issue Type: Bug
Reporter: Jason Kenny
While making the new testing system for ATS it was found that even with a empty
remap.conf and a storage.conf file, ATS does not start in a useful way. This
issue is to help track the goal of getting ATS to a useful running state.
Current testing shows this in diags.log(below). The result is that ATS starts
and is a brick not accepting anything form what I can tell. This setup is done
via using TS_ROOT to redirect ATS to a "clean" space to run in as we would want
when running in a test environment
[Jul 18 16:40:41.946] {0x7fd969a10780} STATUS: opened
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/log/diags.log
[Jul 18 16:40:41.946] {0x7fd969a10780} NOTE: updated diags config
[Jul 18 16:40:41.947] Server {0x7fd969a10780} WARNING: Unable to determine local host 'DESKTOP-9TV9KQF' address information
- Invalid argument
[Jul 18 16:40:41.950] Server {0x7fd969a10780} NOTE: cache
clustering disabled
[Jul 18 16:40:41.973] Server {0x7fd969a10780} ERROR: [CacheControl] Can not open
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/cache.config
file : No such file or directory
[Jul 18 16:40:41.973] Server {0x7fd969a10780} NOTE: ip_allow.config updated, reloading
[Jul 18 16:40:41.973] Server {0x7fd969a10780} ERROR: IpAllow Can not open
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ip_allow.config
file : No such file or directory
[Jul 18 16:40:41.973] Server {0x7fd969a10780} WARNING: IpAllow Failed to read
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ip_allow.config.
All IP Addresses will be blocked
[Jul 18 16:40:41.974] Server {0x7fd969a10780} ERROR: [ParentSelection] Can not open
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/parent.config
file : No such file or directory
[Jul 18 16:40:41.979] Server {0x7fd969a10780} WARNING: configuration changed: [hostdb.config] : reinitializing
database
[Jul 18 16:40:41.979] Server {0x7fd969a10780} NOTE:
reconfiguring host database
[Jul 18 16:40:42.025] Server {0x7fd969a10780} WARNING: unable to DNS DESKTOP-9TV9KQF: 1
[Jul 18 16:40:42.027] Server {0x7fd969a10780} NOTE: cache clustering disabled
[Jul 18 16:40:42.029] Server {0x7fd969a10780} NOTE: logging initialized[3], logging_mode = 3
[Jul 18 16:40:42.049] Server {0x7fd969a10780} NOTE: Error parsing log config file
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/logs_xml.config;
ensure that it is XML-based
[Jul 18 16:40:42.049] Server {0x7fd969a10780} WARNING: unable to open plugin config file
'/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/plugin.config':
2, No such file or directory
[Jul 18 16:40:42.051] Server {0x7fd969a10780} NOTE: loading SSL certificate configuration from
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ssl_multicert.config
[Jul 18 16:40:42.051] Server {0x7fd969a10780} ERROR: SSLParseCertificateConfiguration Can not open
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ssl_multicert.config
file : No such file or directory
[Jul 18 16:40:42.051] Server {0x7fd969a10780} ERROR: failed to read SSL certificate
configuration from
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ssl_multicert.config
[Jul 18 16:40:42.052] Server {0x7fd969a10780} ERROR: [CacheVolition] Can not open
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/volume.config
file : No such file or directory
[Jul 18 16:40:42.053] Server {0x7fd969a10780} WARNING: Cannot read the config file:
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/volume.config
[Jul 18 16:40:42.060] Server {0x7fd965900700} WARNING: disk header different for disk
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/var/trafficserver/cache.db:
clearing the disk
[Jul 18 16:40:42.060] Server {0x7fd969a10780} WARNING: Unable to access() directory
'/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/etc/trafficserver/body_factory':
2, No such file or directory
[Jul 18 16:40:42.061] Server {0x7fd969a10780} WARNING: Please set 'proxy.config.body_factory.template_sets_dir'
[Jul 18 16:40:42.061] Server {0x7fd9657f0700} NOTE: Clearing Disk:
/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/var/trafficserver/cache.db
[Jul 18 16:40:42.061] Server {0x7fd969a10780} WARNING: can't open response template directory
'/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/etc/trafficserver/body_factory'
(No such file or directory)
[Jul 18 16:40:42.061] Server {0x7fd969a10780} WARNING: no r
[jira] [Updated] (TS-4585) Traffic_server will not start with out remap.config
[ https://issues.apache.org/jira/browse/TS-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Kenny updated TS-4585: Priority: Minor (was: Major) > Traffic_server will not start with out remap.config > --- > > Key: TS-4585 > URL: https://issues.apache.org/jira/browse/TS-4585 > Project: Traffic Server > Issue Type: Bug >Reporter: Jason Kenny >Priority: Minor > > When starting traffic_server with no configuration files, it was discovered > that remap.config has to exist on disk. This file can be empty or contain > nothing. However traffic_server will not start if the file is not found. > From a testing point of view it would be nice to not require an empty file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4586) Traffic_server will not start without storage.config
[ https://issues.apache.org/jira/browse/TS-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Kenny updated TS-4586: Priority: Minor (was: Major) > Traffic_server will not start without storage.config > > > Key: TS-4586 > URL: https://issues.apache.org/jira/browse/TS-4586 > Project: Traffic Server > Issue Type: Bug >Reporter: Jason Kenny >Priority: Minor > > This file must exist and contain information about the location and size of > the cache file. At least one must exist. > For testing it would be nice to not require this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4586) Traffic_server will not start without storage.config
Jason Kenny created TS-4586: --- Summary: Traffic_server will not start without storage.config Key: TS-4586 URL: https://issues.apache.org/jira/browse/TS-4586 Project: Traffic Server Issue Type: Bug Reporter: Jason Kenny This file must exist and contain information about the location and size of the cache file. At least one must exist. For testing it would be nice to not require this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4585) Traffic_server will not start with out remap.config
Jason Kenny created TS-4585: --- Summary: Traffic_server will not start with out remap.config Key: TS-4585 URL: https://issues.apache.org/jira/browse/TS-4585 Project: Traffic Server Issue Type: Bug Reporter: Jason Kenny When starting traffic_server with no configuration files, it was discovered that remap.config has to exist on disk. This file can be empty or contain nothing. However traffic_server will not start if the file is not found. >From a testing point of view it would be nice to not require an empty file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4450) Syntax error in CI test script test_https.py.
[ https://issues.apache.org/jira/browse/TS-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291934#comment-15291934 ] Jason Kenny commented on TS-4450: - Ya looks like a bad ) is here. looks like jpeach had a bad check in on this test 25 days ago. Do these tests get run to verify they work? https://github.com/apache/trafficserver/pull/650 > Syntax error in CI test script test_https.py. > - > > Key: TS-4450 > URL: https://issues.apache.org/jira/browse/TS-4450 > Project: Traffic Server > Issue Type: Bug > Components: CI >Reporter: Peter Chou >Assignee: Jason Kenny > Fix For: 7.0.0 > > > I don't know Python, but the parenthesis seems to be un-needed or at least > un-balanced here. Sorry about the formatting, the caret is pointing to the > parenthesis. > File "/usr/src/git/trafficserver/ci/tsqa/tests/test_https.py", line 318 > signal_cmd = [traffic_ctl, 'config', 'reload')] > ^ > SyntaxError: invalid syntax -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3690) ar errors with latest gcc / Fedora 22
[
https://issues.apache.org/jira/browse/TS-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232562#comment-15232562
]
Jason Kenny commented on TS-3690:
-
This is related to using autotool to do our build. It being fixed in a newer
drop of libtool
> ar errors with latest gcc / Fedora 22
> -
>
> Key: TS-3690
> URL: https://issues.apache.org/jira/browse/TS-3690
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Jason Kenny
> Fix For: sometime
>
>
> I see a fair amount of this:
> {code}
> ar: `u' modifier ignored since `D' is the default (see `U')
> ar: `u' modifier ignored since `D' is the default (see `U')
> ar: `u' modifier ignored since `D' is the default (see `U')
> ar: `u' modifier ignored since `D' is the default (see `U')
> ar: `u' modifier ignored since `D' is the default (see `U')
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4114) ASAN based build fails with gcc 5
[ https://issues.apache.org/jira/browse/TS-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150615#comment-15150615 ] Jason Kenny commented on TS-4114: - who own Lua? ideally this makefile needs to be fixed to separate options from the tools being built as part of the build to build lua, or the lua code should be fixed to not leak memory. > ASAN based build fails with gcc 5 > - > > Key: TS-4114 > URL: https://issues.apache.org/jira/browse/TS-4114 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Jason Kenny > Fix For: 6.2.0 > > > When building with gcc 5.x and asan on, the build will fail with memory leak > issues in lua. > ==1442==ERROR: LeakSanitizer: detected memory leaks > Direct leak of 4112 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c8d in build_code host/buildvm.c:204 > #2 0x407c8d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 1304 byte(s) in 1 object(s) allocated from: > #0 0x47fa51 in calloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47fa51) > #1 0x405666 in build_code host/buildvm.c:177 > #2 0x405666 in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 372 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407cae in build_code host/buildvm.c:206 > #2 0x407cae in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 296 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x40568d in build_code host/buildvm.c:182 > #2 0x40568d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 16 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c58 in sym_decorate host/buildvm.c:122 > #2 0x407c58 in build_code host/buildvm.c:203 > #3 0x407c58 in main host/buildvm.c:446 > #4 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 14758 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407bbc in build_code host/buildvm.c:199 > #2 0x407bbc in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 2425 byte(s) in 156 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407ed5 in build_code host/buildvm.c:230 > #4 0x407ed5 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1082 byte(s) in 93 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407e72 in build_code host/buildvm.c:217 > #4 0x407e72 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 525 byte(s) in 37 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b4722 in sym_decorate host/buildvm.c:122 > #2 0x4b4722 in collect_reloc host/buildvm.c:140 > #3 0x4b4722 in dasm_encode ../dynasm/dasm_x86.h:425 > #4 0x407bce in build_code host/buildvm.c:200 > #5 0x407bce in main host/buildvm.c:446 > #6 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407fc9 in build_code host/buildvm.c:235 > #4 0x407fc9 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > SUMMARY: AddressSanitizer: 24891 byte(s) leake
[jira] [Commented] (TS-3939) Add a --with-asan (and perhaps --with-tsan) configure options
[ https://issues.apache.org/jira/browse/TS-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150614#comment-15150614 ] Jason Kenny commented on TS-3939: - There is another jira issue TS-4114 that is open about fixing the makefile for LUA. This needs to be addressed before we can add full ASAN and TSAN support. > Add a --with-asan (and perhaps --with-tsan) configure options > - > > Key: TS-3939 > URL: https://issues.apache.org/jira/browse/TS-3939 > Project: Traffic Server > Issue Type: New Feature > Components: Build >Reporter: Leif Hedstrom >Assignee: Randall Meyer > Labels: newbie > Fix For: 6.2.0 > > > It might be useful to make these options, to make it simpler / easier to add > a build that uses ASan (or TSan). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4157) traffic_via uses files names in it tests that are illegal on shared drives
Jason Kenny created TS-4157: --- Summary: traffic_via uses files names in it tests that are illegal on shared drives Key: TS-4157 URL: https://issues.apache.org/jira/browse/TS-4157 Project: Traffic Server Issue Type: Bug Components: Tests Reporter: Jason Kenny traffic_via has a test directory which file uses names with a : in it. This value will not work on shared drivers as : is an illegal character. This makes certain cases in which it is nice to check out traffic server on shared drives impossible. fixing this to not use : would make life better. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4114) ASAN based build fails with gcc 5
[ https://issues.apache.org/jira/browse/TS-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092453#comment-15092453 ] Jason Kenny commented on TS-4114: - so the command I had to build ats with dts v3 was: ./configure CC=/opt/rh/devtoolset-3/root/usr/bin/gcc\ CXX=/opt/rh/devtoolset-3/root/usr/bin/g++\ CXXFLAGS="-fno-omit-frame-pointer -fsanitize=address -pthread -static-libasan"\ CFLAGS="-fno-omit-frame-pointer -fsanitize=address -pthread -static-libasan"\ --disable-freelist\ CURSES_LIB="-ltermcap -lcursesw"\ LUA_LDFLAGS="-fno-omit-frame-pointer -fsanitize=address -pthread -static-libasan" ... This older version of asan with rhel6 or rhel7 works fine. anything newer fails. > ASAN based build fails with gcc 5 > - > > Key: TS-4114 > URL: https://issues.apache.org/jira/browse/TS-4114 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Jason Kenny >Assignee: Kit Chan > Fix For: 6.2.0 > > > When building with gcc 5.x and asan on, the build will fail with memory leak > issues in lua. > ==1442==ERROR: LeakSanitizer: detected memory leaks > Direct leak of 4112 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c8d in build_code host/buildvm.c:204 > #2 0x407c8d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 1304 byte(s) in 1 object(s) allocated from: > #0 0x47fa51 in calloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47fa51) > #1 0x405666 in build_code host/buildvm.c:177 > #2 0x405666 in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 372 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407cae in build_code host/buildvm.c:206 > #2 0x407cae in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 296 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x40568d in build_code host/buildvm.c:182 > #2 0x40568d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 16 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c58 in sym_decorate host/buildvm.c:122 > #2 0x407c58 in build_code host/buildvm.c:203 > #3 0x407c58 in main host/buildvm.c:446 > #4 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 14758 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407bbc in build_code host/buildvm.c:199 > #2 0x407bbc in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 2425 byte(s) in 156 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407ed5 in build_code host/buildvm.c:230 > #4 0x407ed5 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1082 byte(s) in 93 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407e72 in build_code host/buildvm.c:217 > #4 0x407e72 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 525 byte(s) in 37 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b4722 in sym_decorate host/buildvm.c:122 > #2 0x4b4722 in collect_reloc host/buildvm.c:140 > #3 0x4b4722 in dasm_encode ../dynasm/dasm_x86.h:425 > #4 0x407bce in build_code host/buildvm.c:200 > #5 0x407bce in main host/buildvm.c:446 > #6 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea
[jira] [Commented] (TS-4114) ASAN based build fails with gcc 5
[ https://issues.apache.org/jira/browse/TS-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092223#comment-15092223 ] Jason Kenny commented on TS-4114: - I was able to get this to build with an older version of of ASAN that comes with Developer tools v3 from Red Hat. When using a newer version with gcc 5 new features to report non-freed memory reports issues. The tool in question is just allocating memory and not freeing it. But given what it does in the build I can only assume no one thought it would be an issue as it only runs for a second or so. The only two way to fix it are : 1) clean up your memory allocs 2) hack the lua custom make file to use different settings when making tools to build lua I was more in favor in 1) as it does not require new special logic in the build files. It also follows what my mom told me, ie put back stuff when your are done with it. I tend to find that was good advice :-) > ASAN based build fails with gcc 5 > - > > Key: TS-4114 > URL: https://issues.apache.org/jira/browse/TS-4114 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Jason Kenny >Assignee: Kit Chan > Fix For: 6.2.0 > > > When building with gcc 5.x and asan on, the build will fail with memory leak > issues in lua. > ==1442==ERROR: LeakSanitizer: detected memory leaks > Direct leak of 4112 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c8d in build_code host/buildvm.c:204 > #2 0x407c8d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 1304 byte(s) in 1 object(s) allocated from: > #0 0x47fa51 in calloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47fa51) > #1 0x405666 in build_code host/buildvm.c:177 > #2 0x405666 in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 372 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407cae in build_code host/buildvm.c:206 > #2 0x407cae in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 296 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x40568d in build_code host/buildvm.c:182 > #2 0x40568d in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Direct leak of 16 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407c58 in sym_decorate host/buildvm.c:122 > #2 0x407c58 in build_code host/buildvm.c:203 > #3 0x407c58 in main host/buildvm.c:446 > #4 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 14758 byte(s) in 1 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x407bbc in build_code host/buildvm.c:199 > #2 0x407bbc in main host/buildvm.c:446 > #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 2425 byte(s) in 156 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407ed5 in build_code host/buildvm.c:230 > #4 0x407ed5 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 1082 byte(s) in 93 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b129c in sym_decorate host/buildvm.c:122 > #2 0x4b129c in sym_insert host/buildvm.c:166 > #3 0x407e72 in build_code host/buildvm.c:217 > #4 0x407e72 in main host/buildvm.c:446 > #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) > Indirect leak of 525 byte(s) in 37 object(s) allocated from: > #0 0x47f8ea in __interceptor_malloc > (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) > #1 0x4b4722 in sym_decorate host/buildvm.c:122 > #2 0x4b4722 in collect_reloc host/buildvm.c:140 > #3 0x4b4722 in dasm_encode ../dynasm/dasm_x86.h:425 > #4 0x407bce in build_code host/buildvm.c:200 >
[jira] [Created] (TS-4114) ASAN based build fails with gcc 5
Jason Kenny created TS-4114: --- Summary: ASAN based build fails with gcc 5 Key: TS-4114 URL: https://issues.apache.org/jira/browse/TS-4114 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Jason Kenny When building with gcc 5.x and asan on, the build will fail with memory leak issues in lua. ==1442==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4112 byte(s) in 1 object(s) allocated from: #0 0x47f8ea in __interceptor_malloc (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) #1 0x407c8d in build_code host/buildvm.c:204 #2 0x407c8d in main host/buildvm.c:446 #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) Direct leak of 1304 byte(s) in 1 object(s) allocated from: #0 0x47fa51 in calloc (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47fa51) #1 0x405666 in build_code host/buildvm.c:177 #2 0x405666 in main host/buildvm.c:446 #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) Direct leak of 372 byte(s) in 1 object(s) allocated from: #0 0x47f8ea in __interceptor_malloc (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) #1 0x407cae in build_code host/buildvm.c:206 #2 0x407cae in main host/buildvm.c:446 #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) Direct leak of 296 byte(s) in 1 object(s) allocated from: #0 0x47f8ea in __interceptor_malloc (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) #1 0x40568d in build_code host/buildvm.c:182 #2 0x40568d in main host/buildvm.c:446 #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x47f8ea in __interceptor_malloc (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) #1 0x407c58 in sym_decorate host/buildvm.c:122 #2 0x407c58 in build_code host/buildvm.c:203 #3 0x407c58 in main host/buildvm.c:446 #4 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) Indirect leak of 14758 byte(s) in 1 object(s) allocated from: #0 0x47f8ea in __interceptor_malloc (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) #1 0x407bbc in build_code host/buildvm.c:199 #2 0x407bbc in main host/buildvm.c:446 #3 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) Indirect leak of 2425 byte(s) in 156 object(s) allocated from: #0 0x47f8ea in __interceptor_malloc (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) #1 0x4b129c in sym_decorate host/buildvm.c:122 #2 0x4b129c in sym_insert host/buildvm.c:166 #3 0x407ed5 in build_code host/buildvm.c:230 #4 0x407ed5 in main host/buildvm.c:446 #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) Indirect leak of 1082 byte(s) in 93 object(s) allocated from: #0 0x47f8ea in __interceptor_malloc (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) #1 0x4b129c in sym_decorate host/buildvm.c:122 #2 0x4b129c in sym_insert host/buildvm.c:166 #3 0x407e72 in build_code host/buildvm.c:217 #4 0x407e72 in main host/buildvm.c:446 #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) Indirect leak of 525 byte(s) in 37 object(s) allocated from: #0 0x47f8ea in __interceptor_malloc (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) #1 0x4b4722 in sym_decorate host/buildvm.c:122 #2 0x4b4722 in collect_reloc host/buildvm.c:140 #3 0x4b4722 in dasm_encode ../dynasm/dasm_x86.h:425 #4 0x407bce in build_code host/buildvm.c:200 #5 0x407bce in main host/buildvm.c:446 #6 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) Indirect leak of 1 byte(s) in 1 object(s) allocated from: #0 0x47f8ea in __interceptor_malloc (/home/jkenny/yats_build/asan_build/lib/luajit/src/host/buildvm+0x47f8ea) #1 0x4b129c in sym_decorate host/buildvm.c:122 #2 0x4b129c in sym_insert host/buildvm.c:166 #3 0x407fc9 in build_code host/buildvm.c:235 #4 0x407fc9 in main host/buildvm.c:446 #5 0x3a5201ed5c in __libc_start_main (/lib64/libc.so.6+0x3a5201ed5c) SUMMARY: AddressSanitizer: 24891 byte(s) leaked in 293 allocation(s). make[5]: *** [lj_ffdef.h] Error 23 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2917) luajit ignores --disable-silent-rules
[
https://issues.apache.org/jira/browse/TS-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15060477#comment-15060477
]
Jason Kenny commented on TS-2917:
-
Ya, I was just noticing this issue myself this week trying to get ASAN builds
working. The Lua make file is a custom job, so it does not follow any practices
that make would in generating silent rules. There is a E and Q that can be set
to help with output
Q will control the command being executed. I set it to Q="" when I want a
verbose build. There is an E that control the simulated terse commands Make can
do. So it we don't want to see the "CC foo.o" messages we can set E="@#".
> luajit ignores --disable-silent-rules
> -
>
> Key: TS-2917
> URL: https://issues.apache.org/jira/browse/TS-2917
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Arno Toell
>Assignee: Jason Kenny
>Priority: Minor
> Fix For: sometime
>
>
> When compiling ATS with --disable-silent-rules the luajit tree ignores that
> configure flag. Excerpt:
> {code}
> ./configure --enable-layout=Debian --sysconfdir=/etc/trafficserver
> --libdir=/usr/lib/trafficserver --with-user=root --with-group=root
> --disable-silent-rules --enable-experimental-plugins
> --enable-reclaimable-freelist CFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security"
> CPPFLAGS="-D_FORTIFY_SOURCE=2" CXXFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security" FCFLAGS="-g -O2
> -fstack-protector --param=ssp-buffer-size=4" FFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4" GCJFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4" LDFLAGS="-Wl,-z,relro" OBJCFLAGS="-g -O2
> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security"
> OBJCXXFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security" --enable-wccp --enable-linux-native-aio
> ...
> make[3]: Entering directory
> '/home/arno/trafficserver/trafficserver/iocore/eventsystem'
> depbase=`echo EventSystem.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> c++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../lib -I../../lib/records
> -I../../lib/ts -D_FORTIFY_SOURCE=2 -Dlinux -D_LARGEFILE64_SOURCE=1
> -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/tcl8.6
> -I/usr/include/libxml2 -Wunused-parameter -g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security -std=c++11 -pipe
> -Wall -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -mcx16 -MT EventSystem.o -MD -MP -MF $depbase.Tpo -c -o
> EventSystem.o EventSystem.cc &&\
> mv -f $depbase.Tpo $depbase.Po
> ...
> make[4]: Entering directory
> '/home/arno/trafficserver/trafficserver/lib/luajit'
> Building LuaJIT 2.0.3
> make -C src
> make[5]: Entering directory
> '/home/arno/trafficserver/trafficserver/lib/luajit/src'
> HOSTCChost/minilua.o
> HOSTLINK host/minilua
> DYNASMhost/buildvm_arch.h
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4027) incorrect usage of mmap
Jason Kenny created TS-4027:
---
Summary: incorrect usage of mmap
Key: TS-4027
URL: https://issues.apache.org/jira/browse/TS-4027
Project: Traffic Server
Issue Type: Bug
Reporter: Jason Kenny
The specific type of the crash caused by this failure (whether it is the
SCT_SetReg assertion, or Unexpected memory deallocation error) is pretty random.
This is because the crash is caused by the application’s problematic/buggy
behavior in a way I’ll describe below.
This is a trace of the syscalls invoked by traffic_server as generated with
strace (running without Pin) - I highlighted the important syscalls:
open("/tmp/yts/var/trafficserver/host.db", O_RDWR|O_CREAT, 0644) = 118
fstat(118, {st_mode=S_IFREG|0644, st_size=25935872, ...}) = 0
open("/dev/zero", O_RDONLY) = 119
1. mmap(NULL, 25935872, PROT_READ, MAP_SHARED|MAP_NORESERVE, 119, 0) =
0x7fffef935000
2. munmap(0x7fffef935000, 25935872) = 0
3. mmap(0x7fffef935000, 966656, PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED|MAP_NORESERVE, 118, 0) = 0x7fffef935000
mmap(0x7fffefa21000, 7675904, PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED|MAP_NORESERVE, 118, 0xec000) = 0x7fffefa21000
mmap(0x70173000, 17285120, PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED|MAP_NORESERVE, 118, 0x83e000) = 0x70173000
mmap(0x711ef000, 8192, PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED|MAP_NORESERVE, 118, 0x18ba000) = 0x711ef000
close(119) = 0
close(118) = 0
1. You can see that the application is first calling mmap with “addr”
argument equal to NULL in order to get a memory region that covers the whole
region requested for mapping of the file host.db (25935872 bytes).
2. The application unmaps the allocated region (at address
0x7fffef935000), but remembers this region as a “free” region.
3. Then, the application tries to mmap each region of the file to
addresses inside the region (from step 1) that it considers as “free”. These
mmaps are called with the MAP_FIXED flag – meaning that if there is already a
memory mapped in the requested region then the kernel should still map the
requested memory in a way that the already mapped region will be discarded
(zeroed).
As you probably guess, Between step 2 and 3 Pin is asking the OS to allocate
memory for its own purpose and get some memory inside the unmapped region that
the application considers as “free”.
This will cause the mapping in step 3 to overwrite Pin’s memory and corrupt it
– leading to this crash.
This is a bug in the application (traffic_server) that needs to be fixed.
In a multi-threaded environment (traffic_server is multi-threaded) another
thread can request memory mapping (by mmap) between step 2 and 3, and get a
memory region that intersects with the problematic region.
This allocated memory will eventually be corrupted.
You don’t need Pin and dynamic instrumentation environment in order to
reproduce this bug!
BTW, the application call-stack of this crash, as reported by Inspector is:
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
