| CC: | jluckey@infoblox.com, kvisagamani@infoblox.com |
| Subject: | non-null pointer log message from tree.c |
On Support Ticket #6270, Ramesh Damodaran of Infoblox has informed us:
> Hi,
>
> One of our customers reported a potential problem running dhcpd
> 4.2.4-P2. They are occasionally seeing the following log entries in
> they're syslog:
>
> dhcpd[31485]: err tree.c(2131): non-null pointer
>
> Since the dhcpd has been up and running for a long time and the system
> isn't showing signs of a memory leak we think the problem is due to
> uninitialized data. We know that we could provide a version of the
> daemon with POINTER_DEBUG enabled but that would stop the daemon as soon
> as the message was generated. Since no one has found a way to reproduce
> this problem the POINTER_DEBUG daemon would require the customer to
> closely monitor their system and start a non POINTER_DEBUG version of
> the daemon as soon as the other one died to maintain their service.
>
> With that in mind we went to the source code to see if we could find the
> problem. Unfortunately line 2131 in common/tree.c is a recursive call
> to evaluate_data_expression(). After more digging we found that 13 of
> the 14 calls to buffer_allocate() are passed
> evaluate_data_expression()'s parameters file and line instead of the MDL
> macro. Here's a sample of the code:
>
> if (buffer_allocate (&result -> buffer,
> result -> len + 1, file, line)) {
> result -> data = &result -> buffer -> data [0];
> strcpy ((char *)&result -> buffer -> data [0],
> lease -> host -> name);
> result -> terminated = 1;
> } else {
> log_error ("data: host-decl-name: no memory.");
> return 0;
> }
>
>
> This makes in pretty much impossible to determine if any of the 13
> buffer_allocate() calls in evaluate_data_expression() are generating the
> message. We'd like to see those 13 calls changed to use the MDL macro
> so in the future we could figure out where in the 1000+ line
> evaluate_data_expression() function errors may be generated.
>
> BTW, we also found a similar problems with calls to data_string_copy()
> and get_option() in evaluate_data_expression(). We'd like to see those
> calls changed to use MDL also.
>
> We also verified these issues exist in the latest dhcp, 4.3.0.rc1.
>
> Thanks,
> Ramesh
Since final releases are being spun today and we have hard commitments for
their delivery to some customers, these findings are too late to be included in
the pending releases, but please evaluate and assess for inclusion in the next
set of releases.
Since final releases are being spun today and we have hard commitments for
their delivery to some customers, these findings are too late to be included in
the pending releases, but please evaluate and assess for inclusion in the next
set of releases.