On several Skylake machines I've observed xl segfaults when running
create or destroy subcommands. Other subcommands may segfault too,
but I've only looked at create and destroy which share a similar
backtrace
Thread 2 (Thread 0x7ffff7ff3700 (LWP 2941)):
at /usr/include/bits/unistd.h:44
at xs.c:398
fd=<optimized out>) at xs.c:1231
Thread 1 has canceled Thread 2 and is waiting for it in pthread_join().
The backtrace smelled of memory/stack overflow, which was verified by
increasing DEFAULT_THREAD_STACKSIZE to 32kb. Presumably the stack
overflow is observed on Skylake due to a broader CPU feature set which
must be saved within _dl_runtime_resolve and friends.
While PTHREAD_STACK_MIN should advertise a suitable stack size based on
the underlying system, increasing the default size makes xenstore a bit
more robust on systems with insufficient/broken minimums.
Signed-off-by: Jim Fehlig <jfeh...@suse.com>
---
tools/xenstore/xs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index abffd9cd80..3891e4907c 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -800,7 +800,7 @@ bool xs_watch(struct xs_handle *h, const char *path, const
char *token)
struct iovec iov[2];
#ifdef USE_PTHREAD
-#define DEFAULT_THREAD_STACKSIZE (16 * 1024)
+#define DEFAULT_THREAD_STACKSIZE (32 * 1024)
#define READ_THREAD_STACKSIZE \
((DEFAULT_THREAD_STACKSIZE < PTHREAD_STACK_MIN) ? \
PTHREAD_STACK_MIN : DEFAULT_THREAD_STACKSIZE)
--
2.16.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
