<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 October 2014 10:27, Mark Felder <span dir="ltr"><<a href="mailto:feld@feld.me" target="_blank">feld@feld.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I see that this has come up several times before. From a 2007 thread<br>
Henrik mentioned that this can happen randomly and was unsure why. Do we<br>
have any better ideas how to debug this problem? Would be nice to be<br>
able to come up with a permanent solution for everyone so this doesn't<br>
happen and catch people off guard.</blockquote><div><br></div><div>Being a random problem makes it difficult to track down the fault, but if we have a willing participant that can reproduce the fault, we might be able to make progress.  From reading the code, it looks like the ARES library is resolving with success, but when xymonnet is copying the resolved address into its own data structure, it fails to copy.  The troublesome line 120 is:</div><div><br></div><div>memcpy(&dnsc->addr, *(hent->h_addr_list), sizeof(dnsc->addr));<br></div><div><br></div><div>(From my poor knowledge of C) some problems that can arise here are:</div><div>a) dhsc->addr or dsc is null</div><div>b) hent->h_addr_list or hent is null</div><div>c) dnsc->addr is larger than hent->h_addr_list</div><div><br></div><div>Perhaps we need to see the values of these.  Wallace, can you recompile after inserting these lines immediately before line 120:</div><div><br></div><div><div>dbgprintf("ARES host=%s\n", hent->h_name);</div></div><div>dbgprintf("ARES status=%d name=%s\n", status, dnsc->name);<br></div><div>dbgprintf("ARES addr size=%d\n", sizeof(dnsc->addr));</div><div>dbgprintf("ARES addr hex=%#lx\n", dnsc->addr);</div><div>dbgprintf("ARES addr ascii=%s\n", inet_ntoa(dnsc->addr));</div><div><br></div><div>Assuming this compiles correctly for you (it did for me), backup the old xymonnet, and copy the newly compiled on into place.  Then wait for a core dump, and see what's in the logs.</div><div><br></div><div>Warning: This might break your monitoring, so you might not want to use this on a production system, depending on your stability requirements.<br></div><div><br></div><div>Alternatively, you might see if you can reproduce the problem by running the xymonnet binary manually, something like this:</div><div><br></div><div>xymonnet --debug --no-update name.of.server</div><div><br></div><div>If this dumps core, then you should be able to manually run the new binary in the same way, and check the log output for our debug statements.</div><div><br></div><div>J<br></div><div><br></div></div></div></div>