[
https://issues.apache.org/jira/browse/TS-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399912#comment-13399912
]
Arno Toell commented on TS-1314:
--------------------------------
One might as well argue using {{ARG_MAX}} unconditionally is wrong.
[POSIX|http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html]
does not give any size hint and so do systems whatever they feel like. Every
platform, kernel, arch and user ({{ulimit -s}}) might have a different value
and some obscure systems like HURD do not define it at all.
Thus it's rather insane to happily allocate a static array of entirely unknown
size. I say unknown, because you should not make any assumptions about the size
of {{ARG_MAX}}. Hence I wonder, what the point of that code is, as you should
know a _bit_ better what adequate size hints for your own data structures are,
since you probably put some data into them which might yield unpredictable
results anyway if it does not meet your expectations.
After all, by looking at the code you use an array of size {{ARG_MAX}} (size
hint: hugeish) to store a simple port (from [[proxy/Main.cc}}):
{code}
{"httpport", 'p', "Port descriptor for HTTP Accept", TS_ARG_MAX_STR_FMT,
http_accept_port_descriptor, "PROXY_HTTP_ACCEPT_PORT", NULL},
{code}
I'm pretty sure you won't need more than 2 bytes to store a TCP port number
(thus, as a string 5 bytes).
Having that said, it appears quite strange to me that Debianish systems have
different limits than other distributions using the same arch and kernel. This
could be some side effect by the use of eglibc instead of glibc.
> ATS 3.2 fails to build from source
> ----------------------------------
>
> Key: TS-1314
> URL: https://issues.apache.org/jira/browse/TS-1314
> Project: Traffic Server
> Issue Type: Bug
> Affects Versions: 3.2.0
> Reporter: Arno Toell
> Fix For: 3.2.1
>
> Attachments: trafficserver_3.2.0-1_amd64.build,
> trafficserver_3.2.0-1_amd64.i386-build,
> trafficserver_3.2.0-1_amd64.verbose-build
>
>
> Building Apache Traffic Server 3.2 on Debian AMD64 (x86_64) using the default
> tool chain (gcc 4.7, binutils 2.22) fails to build from source. However, it's
> not the compiler which fails, but the linker (no, really):
> I'm afraid, but it's far beyond my knowledge where this problem comes from as
> my ELF skills are somewhat limited. This is what I get upon linking:
> {code}
> IPAllow.o: In function `ClassAllocator<Event>::alloc()':
> /«PKGBUILDDIR»/proxy/../lib/ts/Allocator.h:115:(.text+0x70): relocation
> truncated to fit: R_X86_64_32 against symbol `eventAllocator' defined in .bss
> section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> IPAllow.o: In function `memcpy':
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0x96): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xa2): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xad): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xb8): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xc3): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xce): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xd9): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xe4): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xef): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xfa): additional
> relocation overflows omitted from the output
> collect2: error: ld returned 1 exit status
> {code}
> Full build log used in a clean build chroot attached. The very same build
> environment built 3.0.5 just fine less than a week ago.
> And yes, sorry, I know I should have tested when zwoop asked for votes before
> releasing 3.2 :/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
