Brand new server, brand new installation. No NTP service in the local net, not an option either. The man page of htpdate says using -b option increases accurancy by polling multiple times each web server. And seems true (at least it gives different results), by some ms I saw a diffrence beteween using and not using that switch. The more servers you poll, the more polls it sends to each one to make a better comparison. Quite reasonable. But starting with, let's say, 5 or 6 servers you get segfaults in the 3rd or 4th server polled. I made lots of tests in fact, and I begun having troubles when passing exactly 5 servers in the command line (with more too). It makes a lot of polls to each one (imagine when you give it the maximum -which is 15 and not 16 as I can see). When in the 3rd or 4th server (variable), it crashes with a segmentation fault. The command line I used was: htpdate -4 -d -b -q -a -x -P x.x.x.x:x <SERVERS> Also tried other combination of flags, and with the least neccesary too but always seemed to be the trouble the -b option. grep-ing the kernel log got me these lines: Dec 30 13:05:58 [kernel] [183884.449894] htpdate[15103]: segfault at ffffffe7 ip 00000037db6493bb sp 00007fff2d5d97e0 error 4 in libc-2.11.2.so[37db600000+171000] Dec 30 13:06:55 [kernel] [183941.550566] htpdate[15105]: segfault at ffffffe7 ip 00000037db6493bb sp 00007fffc2612af0 error 4 in libc-2.11.2.so[37db600000+171000] Jan 03 09:12:07 [kernel] [515453.590694] htpdate[22996]: segfault at 4 ip 00000037db6493bb sp 00007fff6c06a690 error 4 in libc-2.11.2.so[37db600000+171000] Jan 03 09:24:40 [kernel] [516205.896385] htpdate[23014]: segfault at d7 ip 00000037db6493bb sp 00007ffff0f423c0 error 4 in libc-2.11.2.so[37db600000+171000] Jan 03 09:37:19 [kernel] [516965.500889] htpdate[23086]: segfault at 22 ip 00000037db6493bb sp 00007fff1e8f4b00 error 4 in libc-2.11.2.so[37db600000+171000] Jan 03 09:38:36 [kernel] [517042.026842] htpdate[23098]: segfault at 21 ip 00000037db6493bb sp 00007fff8ec22220 error 4 in libc-2.11.2.so[37db600000+171000] Jan 04 12:15:20 [kernel] [ 4372.431575] htpdate[3388]: segfault at ffffffde ip 00000037db6493bb sp 00007fff84fdca70 error 4 in libc-2.11.2.so[37db600000+171000] Jan 04 12:38:10 [kernel] [ 80.666456] htpdate[5188]: segfault at ffffffdf ip 00000037db6493bb sp 00007fff04d63a40 error 4 in libc-2.11.2.so[37db600000+171000] Jan 04 12:42:34 [kernel] [ 344.699893] htpdate[7773]: segfault at ffffffdf ip 00000037db6493bb sp 00007fff9c95e8b0 error 4 in libc-2.11.2.so[37db600000+171000] These are just examples. There were more like that. Note that the only commont factor here is the string "libc-2.11.2.so[37db600000+171000]". This pattern repeats through the other lines. Is that a pointer to something in glibc? I'm sure I can get something useful from that but don't know how (help!). It may be a function or something that can be dereferenced with that. I can imagine that ip xxxx is the value of the instruction pointer in the precise moment of the crash, and sp xxxx... another pointer (I don't figure it out yet). The USE flags I used in the compilation of glibc are gd, glibc-omitfp, multilib and nls. None other activated. Just in case, I run it like a daemon using the init-script provided and adding the -b option to the command line in the /etc/conf.d file. Same results. I am currently running it as a daemon with HTPDATE_OPTS="-D -s -4 -a -x" in the /etc/conf.d file and with 15 servers, but I would like to try the -b option in real life. Any information regarding the problem will be provided. Thanks very much for reading. Reproducible: Always
Created attachment 258933 [details] emerge --info
Created attachment 258935 [details] Build log of htpdate Just in case, the build log as saved in PORT_LOGDIR
Is this still a problem? I fail to reproduce this.
(In reply to comment #3) > Is this still a problem? I fail to reproduce this. Hi, we managed to get the admins setup a NTP server so it may be months since we left over htpdate. I guess I could run some tests in the test server we've got. I'll do this and I'll post the version of htpdate as soon as I can when I go back to work. My laptop is really f* up so I can't test there.
Hi again, net-misc/htpdate-1.0.4 segfaults in my laptop as stated in the bug report, but the environment is not entirely gentoo (I think it counts). As I said, my laptop has troubles: X has gone for reasons that don't matter now. I had to do an important job so I setup a debian squeeze to suvive, and for gentoo I chroot. # cat /etc/debian_version 6.0.2 # uname -a Linux diegom 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux So I compiled and run htpdate from the chroot to test. This is the exact command I had run: # htpdate -4 -d -b -q -a -x www.bancodeltucuman.com.ar gentoo.org www.timeanddate.com www.google.com.ar http://www.itau.com.ar/ www.bcra.gov.ar www.bancocolumbia.com.ar www.hipotecario.com.ar This is the last ten lines of output: burst: 8 try: 1 when: 888888 gentoo.org 30 Aug 2011 19:43:11 GMT (0.293) => -5 burst: 8 try: 2 when: 888888 gentoo.org 30 Aug 2011 19:43:12 GMT (0.293) => -5 burst: 1 try: 1 when: 111111 www.timeanddate.com 30 Aug 2011 19:43:13 GMT (0.343) => -5 burst: 1 try: 2 when: 111111 www.timeanddate.com 30 Aug 2011 19:43:14 GMT (0.300) => -5 burst: 2 try: 1 when: 222222 Segmentation fault As promised, tomorrow there'll be more tests.
This looks to me like an upstream bug that should be send to them :/
Sent the bug upstream via email, so awaiting response.
Created attachment 355848 [details] emerge --info Here's some additional information from my end. I am also able to reproduce this issue by running: htpdate -4 -d -b -q -a -x www.bancodeltucuman.com.ar gentoo.org www.timeanddate.com www.google.com.ar http://www.itau.com.ar/ www.bcra.gov.ar www.bancocolumbia.com.ar www.hipotecario.com.ar (It seg faults after about 35 or so trys). I've attached my emerge --info Here's what I found using gdb. It looks as if the host pointer is going out of bounds. Breakpoint 1, getHTTPdate (host=0x7fffffffe6a3 "www.timeanddate.com", port=0x402bec "80", proxy=0x0, proxyport=0x0, httpversion=0x402b9e "1", ipversion=4, when=111111) at htpdate.c:175 175 rc = getaddrinfo( host, port, &hints, &res0 ); (gdb) Continuing. www.timeanddate.com 13 Aug 2013 07:32:22 GMT (0.077) => 13 burst: 1 try: 2 when: 111111 Breakpoint 1, getHTTPdate (host=0x7fffffffe6a3 "www.timeanddate.com", port=0x402bec "80", proxy=0x0, proxyport=0x0, httpversion=0x402b9e "1", ipversion=4, when=111111) at htpdate.c:175 175 rc = getaddrinfo( host, port, &hints, &res0 ); (gdb) Continuing. www.timeanddate.com 13 Aug 2013 07:32:23 GMT (0.077) => 13 burst: 2 try: 1 when: 222222 Breakpoint 1, getHTTPdate (host=0x7fff0000000d <Address 0x7fff0000000d out of bounds>, port=0x402bec "80", proxy=0x0, proxyport=0x0, httpversion=0x402b9e "1", ipversion=4, when=222222) at htpdate.c:175 175 rc = getaddrinfo( host, port, &hints, &res0 ); (gdb) Continuing. Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b09ba8 in getaddrinfo () from /lib64/libc.so.6
Looks as if upstream is unable to reproduce. It might be something with the build system, so I will do some further testing.
Created attachment 358842 [details] gdb output I tested the issue on a few other machines (x86 and amd64) and GNU/Linux distributions, and was able to reproduce the issue. It seems to be an out of bounds issue. At the top of htpdate.c there's an array declared: timedelta[MAX_HTTP_HOSTS] where MAX_HTTP_HOSTS = 15 In the following code, 'validtimes' is increased every time a valid request is made (not necessarily for each different host): if ( timestamp < timelimit && timestamp > -timelimit ) { timedelta[validtimes] = timestamp; validtimes++; } So what happens is validtimes becomes larger than 15, and it starts writing to values outside of timedelta. Adding gdb.txt Issue has been sent upstream.
Upstream says that this issue is fixed in 1.0.7. I have just added this version to tree. Will close this bug when fixed version hits stable
Pavel becomes Gentoo developer, there is nothing for proxy maintainers here :-)
1.0.7, which fixes this issue, has been stabilized; closing issue.
