[erlang-questions] Bug in epmd_srv.c?

[Klas Johansson]

Hi Dave,

On Mon, Dec 21, 2009 at 4:01 AM, Dave Smith <dizzyd@REDACTED> wrote:
> On Sun, Dec 20, 2009 at 3:06 PM, Klas Johansson
> <klas.johansson@REDACTED> wrote:
>
>> The fix tries to address that.  I'm not too sure about the fix
>> though, since this is in some sense not a backwards compatible
>> fix (since extra and it's length will be different).  However,
>> since the previous version truncated (and garbled) the "extra"
>> field and erl_epmd.erl doesn't seem to care about it it might not
>> be that big a deal.  Perhaps for some other third-party libraries
>> or other parts of Erlang/OTP (ei, jinterface, ...; I haven't
>> checked)?  Also, I'm not that confident in modifying the
>> epmd... :-) I've attached a test case which illustrates the
>> problem.  Get the code here:
>
> It's been a while since I've looked at this, but at first glance it
> seems to me that while your patch solves the case where extra is a
> typical null-terminated string, it does not address the problem where
> extra has binary data with nulls sprinkled throughout. To deal with
> this, you'd need to add a field to track the length of extra (instead
> of depending on strlen) and also replace the strcpy on 627 to a
> memcpy.

True.  I've made a new version, which takes that into account.  I
introduced a new field into the Node/enode struct which remembers
the length of the "extra" when a node is registered in the epmd,
and uses that length together with a memcpy when building the
PORT2_RESP.

I'd love to hear from the Erlang/OTP team and their take on this.
I can push it back to github later on today, if there are no
other things to take into account.

> Hope that helps. :) I am very glad to see someone else looking at it.
> Extra would be quite useful to have working properly.

:-)  Thanks for your feedback.


BR,
Klas