Samuel Thibault, le jeu. 13 avril 2023 23:47:38 +0200, a ecrit:
> Sergey Bugaev, le jeu. 13 avril 2023 15:17:51 +0300, a ecrit:
> > I have now sent the second version of
> > that patch, please try applying it and test if that fixes it.
>
> I'll give it a try.
The first tests seem to be passing, I
Hello,
Sergey Bugaev, le jeu. 13 avril 2023 15:17:51 +0300, a ecrit:
> I have now sent the second version of
> that patch, please try applying it and test if that fixes it.
I'll give it a try.
> Please also check if the other reply port tweak you reverted today is
> also innocent.
The same test
Hello,
Sergey Bugaev, le jeu. 13 avril 2023 16:20:50 +0300, a ecrit:
> On Thu, Apr 13, 2023 at 4:12 PM Samuel Thibault
> wrote:
> at ../sysdeps/mach/hurd/dl-sysdep.c:241
> > 241 __mig_dealloc_reply_port (MACH_PORT_NULL);
>
> Uhh, who deallocs a reply port like that :| You can't pass r
On Thu, Apr 13, 2023 at 4:12 PM Samuel Thibault wrote:
at ../sysdeps/mach/hurd/dl-sysdep.c:241
> 241 __mig_dealloc_reply_port (MACH_PORT_NULL);
Uhh, who deallocs a reply port like that :| You can't pass random crap
into __mig_dealloc_reply_port and rely on its particular
implementation,
Sergey Bugaev, le jeu. 13 avril 2023 14:58:12 +0300, a ecrit:
> NOTE: Completely untested! Do your own testing! You have been warned!
Doesn't work :)
(gdb) bt
#0 0x08000db3 in abort () at ../sysdeps/mach/hurd/dl-sysdep.c:753
#1 0x0802328a in __mig_dealloc_reply_port (arg=)
at ../sysdeps/ma
Alright, here's some more analysis.
I was unable to fetch your core dump (403), but the test case and
libc/ld all 200'ed, and the crash / hang reproduces -- awesome.
and guess what? Firstly, the error we get from mach_port_mod_refs is
EMACH_RCV_INVALID_NAME 268451842 (ipc/rcv) invalid name
so my
Now that the signal code no longer accesses it, the only real user of it
was mig-reply.c, so move the logic for managing the port there.
If we're in SHARED and outside of rtld, we know that __LIBC_NO_TLS ()
always evaluates to 0, and a TLS reply port will always be used, not
__hurd_reply_port0. St
Sergey Bugaev via Libc-alpha, le jeu. 13 avril 2023 13:02:58 +0300, a ecrit:
> this is our very own thread port, the result of mach_thread_self ()
> which was called just several moments ago in hurd_self_sigstate ()!
IIRC this is cached inside glibc... in a TLS variable probably. And thus
if that
Wow, this is great, thank you! You've really gone above and beyond
compared to what I expected you to do.
Some replies below; will reply to other points later.
On Thu, Apr 13, 2023 at 2:47 AM Samuel Thibault wrote:
> > Maybe you're building with some flags that affect this? I'm only doing
> > ..
