diff options
Diffstat (limited to 'community/gsoc/2013/nlightnfotis.mdwn')
| -rw-r--r-- | community/gsoc/2013/nlightnfotis.mdwn | 53 |
1 files changed, 15 insertions, 38 deletions
diff --git a/community/gsoc/2013/nlightnfotis.mdwn b/community/gsoc/2013/nlightnfotis.mdwn index a9176f51..87250c62 100644 --- a/community/gsoc/2013/nlightnfotis.mdwn +++ b/community/gsoc/2013/nlightnfotis.mdwn @@ -429,25 +429,6 @@ License|/fdl]]."]]"""]] <tschwinge> nlightnfotis: But before doing that, please do the diff first, so that we know (hopefully) where the erroneous build results were coming from. - <nlightnfotis> considering the Copyright assignment files, I have sent them - from day 1 (that is the 20th of June). I have not heard anything about - those documents to date (sadly) - <nlightnfotis> what's worst is that although I have a reference number to - track those documents, their (greek postal office) tracking service sucks - so badly, that one day it's offline, the next it suggests it can't find - the object in their database, the next it says it is still in the local - post office - <nlightnfotis> let me check it out now - <nlightnfotis> still nothing from their online service - <nlightnfotis> let me call them - <nlightnfotis> tschwinge: I called the post office regarding the copyright - papers. They told me that the same day (the 20th of June) it left from - Herakleion, Crete to Athens and the same day it must have left the - country heading towards the US. They also told me it takes about 1 week - for it to arrive. - <tschwinge> nlightnfotis: OK, so probably waiting at the FSF office to be - processed. Let's allow for some more time. After all, this is not - critical for your progress. # IRC, freenode, #hurd, 2013-07-10 @@ -826,25 +807,6 @@ License|/fdl]]."]]"""]] worker threads are actually never destroyed on debian (because of a debian specific patch) - <teythoon> youpi, nlightnfotis, hacklu_: btw, what about the copyright - assignment process - <tschwinge> nlightnfotis just got his on file, so there is progress. - <tschwinge> I have email from Donald R Robertson III - <copyright-clerk@fsf.org> about that -- but it is not yet present in the - FSF copyright.list file... - <tschwinge> I think I received that email because I was CCed on - nlightnfotis' submission. - <nlightnfotis> tschwinge: I have got the papers, and they were signed by - the FSF. They stated delivery date 11 of July, but the documents were - signed on the 10th of July :P - <tschwinge> Ah, no, I received it via hurd-maintainers@gnu.org -- and the - strange thing is that not all assignments that got processed got sent - there... - <tschwinge> At the recent GNU Tools Cauldron we also discussed this in the - GCC context; and their experience was the very same. Emails get lost, - and/or take ages to be processed, etc. - <tschwinge> It seems the FSF is undermanned. - # IRC, freenode, #hurd, 2013-07-27 @@ -3035,3 +2997,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 |