Subject: Re: pkg/32800: wine can't create ~/.wine
To: None <adam@NetBSD.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org,>
From: David Holland <dholland@eecs.harvard.edu>
List: pkgsrc-bugs
Date: 10/22/2006 22:20:02
The following reply was made to PR pkg/32800; it has been noted by GNATS.
From: dholland@eecs.harvard.edu (David Holland)
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/32800: wine can't create ~/.wine
Date: Sun, 22 Oct 2006 18:17:11 -0400 (EDT)
I've found another problem... unfortunately it's still not the whole
problem.
NetBSD's libpthread ignores the per-thread stack size that can be set
with pthread_attr_setstacksize(), and it looks like Wine relies on
this in some fashion. It's not clear to me exactly what's going on,
but:
- when it dumps core, the current thread's stack pointer is 0x7fcefe8c;
- pthread__self() constructs 0x7c000000 from this because
pthread_stacksize is 0x4000000;
- however, the bottom of the current stack as it exists in memory,
as ascertained by poking memory with gdb, is 0x7fbe0000;
- wine uses pthread_attr_setstacksize() - see wine-0.9.23/loader/pthread.c.
I tried working around this by setting $PTHREAD_STACKSIZE to 1152
(0x120000 / 1024) in the hopes that this would cause pthread__self to
return the "right" address. This allows wineprefixcreate, or rather,
the wine invocation inside it, to get past the initial SIGSEGV, but it
still doesn't work - it appears to be back to the infinite loop I was
seeing last spring after the signal fixes.
Sigh.
--
- David A. Holland / dholland@eecs.harvard.edu