[ntp:questions] Unresolved Symbol

Per Hedeland per at hedeland.org
Tue Aug 21 08:42:10 UTC 2007

In article <1187653764.667735.309710 at m37g2000prh.googlegroups.com> Aggie
<c.kevin.lam at gmail.com> writes:
>On Aug 10, 12:15 pm, p... at hedeland.org (Per Hedeland) wrote:
>> In article <T1186727... at ex.djwhome.demon.co.uk.invalid>
>> da... at ed.djwhome.demon.co.uk.invalid (David Woolley) writes:
>> >In article <1186703380.966947.229... at i38g2000prf.googlegroups.com>,
>> >Aggie <c.kevin.... at gmail.com> wrote:
>> >> Machine Check
>> >Machine check should never be the result of software problems (except
>> >kernel ones which leave the hardware in a diagnostic mode).  It means
>> >you have a broken CPU, memory, or other core part of the hardware.
>> Are you knowledgeable enough about VxWorks to know exactly what
>> conditions it would report as "Machine Check"?
>No, I don't know much things on VxWorks.

Actually my question was directed at David, who asserted that this was a
hardware problem. As I wrote, he may well be right, unfortunately he
didn't answer...

However if you don't know much about VxWorks, trying to get ntpd to work
there may be a bit optimistic.

>> You may well be right (in
>> principle and/or in practice), but from my experience with VxWorks
>> (several years old, muddled by less than perfect memory), that's the
>> kind of message you would get whenever you did something that would
>> result in "segmentation fault" or "bus error" on Unix - basically any
>> kind of invalid memory access. Most commonly dereferencing a NULL
>> pointer.
>Yes, I think you are right on the dereferncing a NULL part.

Hm, if you think so based on the occurrence of NULL in the source,
you're jumping to conclusions - NULL-dereferencing bugs typically happen
when the code *doesn't* check for pointers being NULL.:-)

> Is there a
>NUL?? is it the same as NULL??

NUL normally "means" the char value 0 a.k.a. '\0', the standard string
terminator in C, while NULL is a "null pointer", a.k.a. the value
obtained by conversion of 0 to the pointer type. In practice they may be
the same, but it would of course be confusing to mix them. Also in
practice NUL is rarely used in code and doesn't have a definition in
standard include files AFAIK. The 'libopts' code in current ntpd defines
it in libopts/compat/compat.h.

>Here's the line that gave me error:
>    if ((pOpts->pzCurOpt != NULL) && (*pOpts->pzCurOpt != NUL))

Hm, that line would only cause a NULL dereference if pOpts was NULL, and
if the stack trace in your earlier post is to be believed, that isn't
the case. Of course another possibility is that the address otherwise is
outside your physical (or virtual if you use some MMU functionalilty)
memory range, though it doesn't seem very likely. Or an actual hardware

--Per Hedeland
per at hedeland.org

More information about the questions mailing list