Wine-Bugs

By thread

wine-bugs@list.winehq.org

January 2020

1 participants
1682 messages

[Bug 48291] Detroit: Become Human crashes on launch

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #50 from qsniyg <qsniyg(a)mail.com> --- (In reply to Zebediah Figura from comment #49) > Okay, now I'm even more confused. As I described, this approach means we > trap on every syscall, which isn't performant. This is why I wrote that it would be an experiment to see the performance impact. However seccomp - unlike ptrace - does not stop the process when it traps a syscall (it will pause the thread calling it obviously, but that's to be expected). Seccomp's performance overhead per-syscall is also apparently quite minimal according to various sources, so I'm not sure if the performance impact would be very significant. There's actually also the possibility that it will be faster, as it doesn't encode/decode anything, neither does it use sockets. > ...so what do we do about the syscalls that the application makes, if we're > not trapping them? If seccomp is disabled, I'm not sure if there's anything that can be done (other than ptrace, which is probably out of the question for performance reasons). That being said, I've been investigating this further, and I don't think it's possible for the moment, because of a few syscalls that must be performed in the client application, such as memory allocation. One possible solution would be to have a ptrace-like extension for seccomp, where the response would include a syscall to execute on the tracee. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Jan. 1, 2020

[Bug 48291] Detroit: Become Human crashes on launch

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #49 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to qsniyg from comment #48) > (In reply to Zebediah Figura from comment #47) > > You proposed that the implementation of ntdll be moved to wineserver. That's > > a separate process; how exactly are you proposing we communicate with it? We > > currently do so via sockets; that's IPC and requires system calls. > > If seccomp is used, ntdll uses syscalls, as (afaics) that's how windows > works: https://j00ru.vexillium.org/syscalls/nt/64/ . IPC isn't used. > Okay, now I'm even more confused. As I described, this approach means we trap on every syscall, which isn't performant. > If seccomp is not used, IPC is used, and it doesn't matter that it uses > linux syscalls because syscalls aren't being trapped :) ...so what do we do about the syscalls that the application makes, if we're not trapping them? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Jan. 1, 2020

Jump to page: