On Tue, Apr 15, 2008 at 03:05:21AM +0200, Josip Rodin wrote:
> On Tue, Apr 15, 2008 at 02:44:25AM +0200, Josip Rodin wrote:
> > I see the culprit in ntpd/ntp_monitor.c:
> >
> > /*
> > * Limits on the number of structures allocated. This limit is picked
> > * with the illicit knowlege that we can only return somewhat less
> > * than 8K bytes in a mode 7 response packet, and that each structure
> > * will require about 20 bytes of space in the response.
> > *
> > * ... I don't believe the above is true anymore ... jdg
> > */
> > #ifndef MAXMONMEM
> > #define MAXMONMEM 600 /* we allocate up to 600 structures */
> > #endif
>
> http://ntp.bkbits.net:8080/ntp-stable/ntpd/ntp_monitor.c?PAGE=anno&REV=4501fb5ciab3mg65AEoxeovMbL3KMg
> and http://ntp.bkbits.net:8080/ntp-stable/ntpd/ntp_monitor.c?PAGE=history
> seem to indicate that this code is over 9 years old (older than the initial
> commit on 1999-05-25)...
>
> http://www.eecis.udel.edu/~ntp/ntp_spool/depredated/xntp2/xntp.tar.Z
> contains a copy where MAXMONMEM is 400, dated 1989-11-06.
> The difference between those two versions also includes this comment:
>
> + * trimmed back memory consumption ... jdg 8/94
>
> Whoa. It looks like this code could use some help. I can't remember what
> could have been too much memory consumption in 1989/1994, but I'm pretty
> sure that we'd all just chuckle at those numbers these days. :)
I've raised this constant to 1024 and then to 2048, resulting in the local
ntpdc monlist lookup returning not 600 but 768 addresses. After that, it
just keeps returning 768. On the other hand, a remote ntpdc lookup keeps
crashing. :(
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
