[[!meta copyright="Copyright © 2011, 2012, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_libpthread]] IRC, freenode, #hurd, 2011-10-21: maybe i'm missing something... what's the reason for not allowing setting a different stack size in libpthread? 2011-10-23: pinotree: the threadvars implementations which needs to find the variables according to sp value of course, since we now have TLS, threadvards can go away it's simply on the so-long TODO list [[glibc/t/tls-threadvar]]. 2012-12-28: Hurd commit 3a3fcc811e6b50b21124a5c5a128652e788a3b67 `libports: remove the threadvars stack size hack`. IRC, freenode, #hurd, 2014-01-09: braunr: i'm afraid it might be your patch 3a3fcc81 that breaks proc w/ the current debian libc that is braunr: i reverted that patch and now it boots again is alternate stack and arbitrary stack sizes supported by now, or upcoming? gnu_srs: supported well considering what teythoon just said, maybe not need to remove __pthread_stack_default_size from libpthread_hurd_cond_wait patch too i guess teythoon: i don't understand why this change has any negative effect :/ or hm no .. there may be a bug in the latest glibc, where changing the stack is allowed on the ground that threadvars have been replaced with tls, but the libpthread stack handling code does it wrong see 714413a7694ff534855e9e5904899695eac6c9bb in libpthread which the thread destruction patches already did before it was fixed in libpthread and may explain why my packages work IRC, freenode, #hurd, 2014-01-14: teythoon: Mmm, I tried to update to the latest hurd commits, but init dies early at boot exec init proc auth, and then init crashes downgrading libports to previous makes the issue go away youpi: previous ? previous debian package which patch makes it fail ? I'm bisecting i remember teythoon saying he had failures with the patch that removes the threadvars stack size hack I'll try that already, ok yes, boots fine without this change ok perhaps some missing patches in the current 2.17-97 glibc or libpthread reacting badly to new stack sizes is 714413a7694ff534855e9e5904899695eac6c9bb included in your glibc ? (714413a7694ff534855e9e5904899695eac6c9bb from libpthread) or maybe that's not the problem anyway, it's normally fixed with the thread destruction patch i did test it and checked the stack size were correct sizes* yes, debian's glibc has it ok so that can wait is 959f7365fccd1c89be9938c2655eba9122171e6a (Drop threadvars entirely) also in your glibc ? yes that's weird :/ the only thing i can think of is __pthread_stack_alloc miserably failing with 2M stacks and "many" threads for some odd reason .. anyway, see you tomorrow hurd-i386/libpthread_hurd_cond_wait.diff keeps using __pthread_stack_default_size. isn't it the problem? * youpi wonders what that change is doing there and it's there from the start of that patch... + if (&__pthread_stack_default_size != NULL) checks if the symbol is actually resolved that's what allows regular applications to work it should be the same for hurd servers # sigaltstack Likewise, `sigaltstack` is not usable at the moment. IRC, freenode, #hurd, 2014-02-25: braunr: are the split/alternate stack etc problems solved by now so gccgo can work properly? i don't know i suspect it wouldn't require much work now that tls is well supported alternate stack is supposed to be working