https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #19 from Paul Gofman pgofman@codeweavers.com --- The log suggests that there is something on 0x32d9a1b56d (and then 0x32d9a1b634, 0x32d9a1b737) having syscall instruction, and the intent of that code is probably to execute native Linux syscalls (judging by syscall numbers), that is, it is some native library. The usual reason for such things is stated right in the patch: "The known reasons are /proc/sys/vm/legacy_va_layout set to 1 or 'ulimit -s' being 'unlimited", but I doubt this is exactly the case here because there is a specific check during seccomp filters installation and it looks like glibc loaded at high addresses as patch expects.
Do you have some way to see what code (library) is loaded at those addresses? Not sure if it is easy to do remotely with additional patches, needs some extra logging to show at least Unix libs load addresses. Maybe +pid,+seh,+unwind,+virtual log can tell something, but only if it is *not* our Unix lib.
Not sure offhand what can it be (I guess it is clean prefix already), maybe something unusual in LD_PRELOAD? And just in case I would check ulimit -s and /proc/sys/vm/legacy_va_layout first.