-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

>> First I thought it's a pthread issue because it /always/ hangs in
>> pthread_sigmask() but the call stack contains some rather funny
>> addresses - shouldn't all (function) pointers have 0 in their upper 32
>> bits when compiled with -mmodel=medlow? It's not the dynamic loader's
>
> No.  When you run 64-bit code, application code can use the `medlow'
> model.  The user space mappings are as follows:
>
> 1) The first 1MB or so should be unmapped to prevent NULL pointer
> dereferences.  (Actually it should be mapped with the NFO bit set
> to support speculative loads).
Hmm, the call stack has a 0x0000000000000008 at some point.

> 6) Here's there's a VA hole from 0x000000ffffffffff to
> 0xffffff0000000000.
explains why...
#12 <signal handler called>
#13 0xffffb1a100000000 in ?? ()
... this fired the sig handler...
#14 0x0000000001347bb8 in ?? ()
#15 0xffffffffffffb16d in ?? ()
... but this didn't.

As far as I can tell these 'funny' addresses on the call stack are 
related to function pointers, but I have no idea why they're hosed 
apparently at random. Paging activity seems to trigger the lockup, but 
not always.

thanks for the explanation
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQkifQ8pnzkX8Yg2nAQJq/gf/SMXur/r1opQZme/LiISfGzeOiv3OLngo
nC7+ungniCA3tpnUjiabxVB75ko5/VeKa4xe14J+CAVsXd3hsUp7fRYV4SRc18Dx
98rKgEvnZlBfxFj1Mz6SjgbOfLCNfFfyzS3q255uHp/hGl1Wumo6wjKXICJZT6oy
nhVfBilN1d1zONZHGkKx07O/qMk1sRCD0m4PlgRIhdWraqTD1A04Nybn2qRA2G8w
xLmFJYOZXKedQEh7qFrb+RhTvDkoTDznRFQ7P1KYHXaDlRQ2d2OM4Ql/Y8X+oy06
MXlLgVzhch5dUMogH4DQpGKS7C/IEvZFcI00o2VsajqNk1kEopL+Vg==
=gryO
-----END PGP SIGNATURE-----