|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [BUG] xs.watch and xs.unwatch are unreliable
I've CC'ed some people who might have an idea whether they are replying
on this behaviour. I doubt that but let's better be sure...
On Tue, Mar 01, 2016 at 11:17:54PM +0300, Sergei Lebedev wrote:
> Hi list,
>
> I’ve initially wanted to report another inconsistency in ``xen.lowlevel.xs``
> documentation, but this time the issue is more subtle.
>
> Both ``xs.watch`` and ``xs.unwatch`` accept two arguments: a path to watch
> and a token. According to the documentation, the second argument must be a
> string, which makes sense, since the token should be sent directly to
> XenStore. Instead of doing the simple thing (transmitting the token as-is),
> the implementation makes a new token from *the pointer* to the token object
> and sends it instead:
>
> PyObject *token;
> char token_str[MAX_STRLEN(unsigned long) + 1];
>
> snprintf(token_str, sizeof(token_str), "%li", (unsigned long)token);
>
> This does work for simple cases, e.g. if a token is a string literal
>
> >>> from xen.lowlevel.xs import xs
> >>> h = xs()
> >>> h.watch(“@introduceDomain”, “token”)
> >>> h.unwatch(“@introduceDomain”, “token”)
>
> or a small number
>
> >>> h.watch(“@introduceDomain”, 42)
> >>> h.unwatch(“@introduceDomain”, 42)
>
> But in the general case this is broken
>
> >>> h.watch("@introduceDomain", 100000000000000000000000000000)
> >>> h.unwatch("@introduceDomain", 100000000000000000000000000000)
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> xen.lowlevel.xs.Error: (2, 'No such file or directory’)
>
> Here’s another example with a string token
>
> >>> token1 = str(100000000000000000000000000000)
> >>> token2 = str(100000000000000000000000000000)
> >>> token1 == token2
> True
> >>> h.watch("@introduceDomain", token1)
> >>> h.unwatch("@introduceDomain", token2)
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> xen.lowlevel.xs.Error: (2, 'No such file or directory’)
>
> I’m not sure what would be the best way to handle this as there might be
> existing code relying on this undocumented behaviour. What do you think?
>
In any case this looks like a real bug.
The fix (as you said) is to transmit the token. I don't think your
proposed fix would break existing users though.
Wei.
> Regards,
> Sergei
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |