From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: xen 4.3 -> 4.4.0 API change / spurious file handle closure Date: Mon, 18 Aug 2014 13:46:42 +0100 Message-ID: <53F1F5B2.8050604@citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Alex Bligh , Xen Devel List-Id: xen-devel@lists.xenproject.org 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