* xen 4.3 -> 4.4.0 API change / spurious file handle closure
@ 2014-08-18 12:28 Alex Bligh
2014-08-18 12:46 ` Andrew Cooper
0 siblings, 1 reply; 2+ messages in thread
From: Alex Bligh @ 2014-08-18 12:28 UTC (permalink / raw)
To: Xen Devel; +Cc: Alex Bligh
I have an application which works when compiled against
Xen 4.3 but when compiled against Xen 4.4.0 causes a
spurious file handle closure. Specifically fd 0 is
closed when it has nothing to do with Xen. This
happens with a simple call to libxl_ctx_alloc /
libxl_ctx_free.
This can be seen from the snippet below which
simply lists the open fds. In the 'before' call,
the 'ls' command (run from system) opens fd 3
for the directory. In the 'after' call, the
alloc/free has closed fd 0, so fd 0 is reused
for the 'ls' command.
This worked fine under Xen 4.3.
The addition of
#define LIBXL_API_VERSION 0x040200
does not appear to affect things.
Any idea what's up here?
--
Alex Bligh
#include <stdio.h>
#include <stdlib.h>
#include <libxl.h>
/* compile with:
* gcc -g -O0 xentest.c -o xentest -lxenlight
*/
void
test ()
{
libxl_ctx *ctx = NULL;
if (libxl_ctx_alloc (&ctx, LIBXL_VERSION, XTL_NONE, NULL))
{
fprintf (stderr, "libxl_ctx_alloc failed");
exit (1);
}
libxl_ctx_free (ctx);
}
int
main (int argc, char **argv)
{
printf ("Before:\n");
system ("ls -la /proc/self/fd");
test ();
printf ("\nAfter:\n");
system ("ls -la /proc/self/fd");
exit (0);
}
Output:
root@node-10-157-128-19:~# ./xentest
Before:
total 0
dr-x------ 2 root root 0 Aug 18 12:14 .
dr-xr-xr-x 9 root root 0 Aug 18 12:14 ..
lrwx------ 1 root root 64 Aug 18 12:14 0 -> /dev/pts/4
lrwx------ 1 root root 64 Aug 18 12:14 1 -> /dev/pts/4
lrwx------ 1 root root 64 Aug 18 12:14 2 -> /dev/pts/4
lr-x------ 1 root root 64 Aug 18 12:14 3 -> /proc/31986/fd
After:
total 0
dr-x------ 2 root root 0 Aug 18 12:14 .
dr-xr-xr-x 9 root root 0 Aug 18 12:14 ..
lr-x------ 1 root root 64 Aug 18 12:14 0 -> /proc/31988/fd
lrwx------ 1 root root 64 Aug 18 12:14 1 -> /dev/pts/4
lrwx------ 1 root root 64 Aug 18 12:14 2 -> /dev/pts/4
root@node-10-157-128-19:~#
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: xen 4.3 -> 4.4.0 API change / spurious file handle closure
2014-08-18 12:28 xen 4.3 -> 4.4.0 API change / spurious file handle closure Alex Bligh
@ 2014-08-18 12:46 ` Andrew Cooper
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Cooper @ 2014-08-18 12:46 UTC (permalink / raw)
To: Alex Bligh, Xen Devel
On 18/08/14 13:28, Alex Bligh wrote:
> I have an application which works when compiled against
> Xen 4.3 but when compiled against Xen 4.4.0 causes a
> spurious file handle closure. Specifically fd 0 is
> closed when it has nothing to do with Xen. This
> happens with a simple call to libxl_ctx_alloc /
> libxl_ctx_free.
>
> This can be seen from the snippet below which
> simply lists the open fds. In the 'before' call,
> the 'ls' command (run from system) opens fd 3
> for the directory. In the 'after' call, the
> alloc/free has closed fd 0, so fd 0 is reused
> for the 'ls' command.
>
> This worked fine under Xen 4.3.
>
> The addition of
> #define LIBXL_API_VERSION 0x040200
> does not appear to affect things.
>
> Any idea what's up here?
>
Thats antisocial. I have reproduced the issue.
Stracing it (with some extra debugging)...
write(1, "Freeing libxl ctx", 17Freeing libxl ctx) = 17
write(1, "\n", 1
) = 1
close(5) = 0
close(6) = 0
close(7) = 0
close(3) = 0
close(4) = 0
close(0) = 0
write(1, "Finished freeing", 16Finished freeing) = 16
Shows that libxl_ctx_free() is closing fd 0.
I suspect it has an fd which is 0 rather than -1. I will take a look.
~Andrew
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-08-18 12:46 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-18 12:28 xen 4.3 -> 4.4.0 API change / spurious file handle closure Alex Bligh
2014-08-18 12:46 ` Andrew Cooper
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).