diff options
| author | Thomas Schwinge <tschwinge@gnu.org> | 2013-10-27 19:15:06 +0100 |
|---|---|---|
| committer | Thomas Schwinge <tschwinge@gnu.org> | 2013-10-27 19:15:06 +0100 |
| commit | 47e4d194dc36adfcfd2577fa4630c9fcded005d3 (patch) | |
| tree | d16ffd2eeb74d1977fb3e9744e4a38befedb4ddf /community/gsoc/2013/nlightnfotis.mdwn | |
| parent | ca39ad0592e9b99dac9d99c68bb36ef1d27f72df (diff) | |
IRC.
Diffstat (limited to 'community/gsoc/2013/nlightnfotis.mdwn')
| -rw-r--r-- | community/gsoc/2013/nlightnfotis.mdwn | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/community/gsoc/2013/nlightnfotis.mdwn b/community/gsoc/2013/nlightnfotis.mdwn index a9176f51..83e97bc7 100644 --- a/community/gsoc/2013/nlightnfotis.mdwn +++ b/community/gsoc/2013/nlightnfotis.mdwn @@ -3035,3 +3035,18 @@ But not the [[open_issues/libpthread_dlopen]] issue? <nlightnfotis> and we wanna prove that go violates this rule right? That the stack pointer is not pointing at the initial stack <braunr> yes + + +# IRC, freenode, #hurd, 2013-10-09 + + <gnu_srs> braunr: The crash is not in the assembly code, but in the called + function from it: + <gnu_srs> pthread_sigmask (how=2, set=0xf9cac <server_block_set>, + oset=oset@entry=0x0) at ./pthread/pt-sigmask.c:29 + <gnu_srs> 29 struct __pthread *self = _pthread_self (); + <gnu_srs> Program received signal SIGSEGV, Segmentation fault. + <braunr> gnu_srs: ok so, same problem as in gcc go + <braunr> changing the stack pointer prevents libpthread from correctly + fetching thread-specific data (including _pthread_self()) correctly + <braunr> this will be fixed when threadvards are finally replaced with true + tls |