|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] fix assert fail in libxl__sigchld_installhandler
Bamvor Jian Zhang writes ("[PATCH] fix assert fail in
libxl__sigchld_installhandler"):
> when libxl_sigchld_owner_libxl_always is used in libvirt or other
> tools stack, there is a assertion fail in restore in
> libxl__sigchld_installhandler during the following sequence:
> create -> save -> restore.
>
> here is the backtrace:
> #0 0x00007f7a522453d5 in raise () from /lib64/libc.so.6
> #1 0x00007f7a52246858 in abort () from /lib64/libc.so.6
> #2 0x00007f7a5223e2e2 in __assert_fail_base () from /lib64/libc.so.6
> #3 0x00007f7a5223e392 in __assert_fail () from /lib64/libc.so.6
> #4 0x00007f7a48008113 in libxl__sigchld_installhandler (
> gc=gc@entry=0x7f7a4f080480) at libxl_fork.c:225
> #5 0x00007f7a480081f4 in perhaps_installhandler
> (gc=gc@entry=0x7f7a4f080480,
> creating=creating@entry=false) at libxl_fork.c:272
> #6 0x00007f7a4800851f in libxl_childproc_setmode (ctx=0x7f7a400c0ee0,
> hooks=hooks@entry=0x7f7a482694a0 <childproc_hooks>,
> user=user@entry=0x7f7a48474f80 <child_info>) at libxl_fork.c:427
>
> the sigchld_owner exists but it is not the same as the new CTX.
> meanwhile the old sigchild is not removed in perhaps_removehandler.
I think the assertion has detected a bug in your use of libxl, not a
bug in libxl.
If you use libxl_sigchld_owner_libxl_always you're telling libxl that
this libxl_ctx should always own the entire application's SIGCHLDs.
That is obviously not compatible with having multiple different
libxl_ctx's.
If you are running multiple different long-running libxl operations in
parallel, then either:
(a) they must all use the same libxl ctx
or
(b) you must specify libxl_sigchld_owner_mainloop and demultiplex
SIGCHLD yourself
This wasn't 100% clear from the doc comment. I propose the patch
below to fix this.
Thanks,
Ian.
From 73b6484cbd5409101308c6c640eb7597f63256b9 Mon Sep 17 00:00:00 2001
From: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date: Mon, 25 Nov 2013 11:53:28 +0000
Subject: [PATCH] libxl: doc comment: clarify SIGCHLD demultiplexing
requirements
Update the comment to clarify that libxl_sigchld_owner_libxl_always
implies having only one libxl_ctx, and that
libxl_sigchld_owner_mainloop requires one call to
libxl_childproc_exited per ctx.
Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
---
tools/libxl/libxl_event.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 27a65dc..5b2c689 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -446,13 +446,15 @@ void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void
*for_libxl)
*
* libxl_sigchld_owner_mainloop:
* The application must install a SIGCHLD handler and reap (at
- * least) all of libxl's children and pass their exit status
- * to libxl by calling libxl_childproc_exited.
+ * least) all of libxl's children and pass their exit status to
+ * libxl by calling libxl_childproc_exited. (If the application
+ * has multiple libxl ctx's, it must call libxl_childproc_exited
+ * on each ctx.)
*
* libxl_sigchld_owner_libxl_always:
* The application expects libxl to reap all of its children,
* and provides a callback to be notified of their exit
- * statues.
+ * statues. The application must have only one libxl_ctx.
*
* An application which fails to call setmode, or which passes 0 for
* hooks, while it uses any libxl operation which might
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |