Author: kevans
Date: Fri Jun 12 18:13:32 2020
New Revision: 362111
URL: https://svnweb.freebsd.org/changeset/base/362111
Log:
posix_spawn: fix for some custom allocator setups
libc cannot assume that aligned_alloc and free come from jemalloc, or that
any application providing its own malloc and free is actually providing
aligned_alloc.
Switch back to malloc and just make sure we're passing a properly aligned
stack into rfork_thread, as an application perhaps can't reasonably replace
just malloc or just free without headaches.
This unbreaks ksh93 after r361996, which provides malloc/free but no
aligned_alloc.
Reported by: freqlabs
Diagnosed by: Andrew Gierth <andrew_tao173.riddles.org.uk>
X-MFC-With: r361996
Modified:
head/lib/libc/gen/posix_spawn.c
Modified: head/lib/libc/gen/posix_spawn.c
==============================================================================
--- head/lib/libc/gen/posix_spawn.c Fri Jun 12 17:48:12 2020
(r362110)
+++ head/lib/libc/gen/posix_spawn.c Fri Jun 12 18:13:32 2020
(r362111)
@@ -276,9 +276,19 @@ do_posix_spawn(pid_t *pid, const char *path,
stacksz += MAX(3, cnt + 2) * sizeof(char *);
stacksz = PSPAWN_STACK_ALIGN(stacksz);
}
- stack = aligned_alloc(PSPAWN_STACK_ALIGNMENT, stacksz);
+
+ /*
+ * aligned_alloc is not safe to use here, because we can't guarantee
+ * that aligned_alloc and free will be provided by the same
+ * implementation. We've actively hit at least one application that
+ * will provide its own malloc/free but not aligned_alloc leading to
+ * a free by the wrong allocator.
+ */
+ stack = malloc(stacksz);
if (stack == NULL)
return (ENOMEM);
+ stacksz = (((uintptr_t)stack + stacksz) & ~PSPAWN_STACK_ALIGNBYTES) -
+ (uintptr_t)stack;
#endif
psa.path = path;
psa.fa = fa;
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
