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
This commit is contained in:
parent
13dca1937f
commit
ebff66b3c3
@ -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;
|
||||
|
Loading…
Reference in New Issue
Block a user