Hi!
Ping.
On Wed, 14 Nov 2012 15:53:53 +0100, I wrote:
> On Thu, 08 Sep 2011 12:40:30 +0200, Thomas Schwinge
> wrote:
> > This is about fork in glibc. It's leaking port rights.
>
> (We're not leaking port rights, but we're »handling user reference counts
> incorrectly«, as I corrected myself
Hi!
On Thu, 08 Sep 2011 12:40:30 +0200, Thomas Schwinge
wrote:
> This is about fork in glibc. It's leaking port rights.
(We're not leaking port rights, but we're »handling user reference counts
incorrectly«, as I corrected myself later on.)
> Roland, thanks for the good source code commentati
Hi!
On Thu, 8 Sep 2011 15:37:15 +0200, Samuel Thibault
wrote:
> Thomas Schwinge, le Thu 08 Sep 2011 12:40:30 +0200, a écrit :
> > One patch for the TLS code is below; Samuel please have a look.
>
> Agreed.
You fixed this in Debian eglibc r4959, but it regressed in r5011 when
synchronizing to t
Hi!
First, in my other message I said that ``we're leaking port rights''.
This is wrong; we're just handling user reference counts incorrectly.
On Thu, 8 Sep 2011 09:43:58 -0700 (PDT), Roland McGrath
wrote:
> > Here, we've unconditionally used the value of refs, and didn't take into
> > accou
Roland McGrath, le Thu 08 Sep 2011 09:43:58 -0700, a écrit :
> > One patch for the TLS code is below; Samuel please have a look. (Thou
> > shalt not invoke mach_thread_self needlessly -- or is there a reason?)
> > Unfortunately, this is not all. I'm continuing.
>
> Does __mach_thread_self bump t
> Here, we've unconditionally used the value of refs, and didn't take into
> account that record_refs ought to have been used instead, and refs could
> be any value (uninitialized) -- or which detail am I missing here?
> Should refs have simply been initialized to zero (as the zero value is
> nonef
Thomas Schwinge, le Thu 08 Sep 2011 12:40:30 +0200, a écrit :
> One patch for the TLS code is below; Samuel please have a look.
Agreed.
Samuel
Hi!
This is about fork in glibc. It's leaking port rights.
Roland, thanks for the good source code commentation, which is mostly
up-to-date; this has helped a lot for understanding!
On Mon, 22 Nov 2010 11:56:45 +0100, Samuel Thibault
wrote:
> Thomas Schwinge, le Mon 22 Nov 2010 09:38:24 +010
Hello!
On Tue, Nov 30, 2010 at 12:07:05PM +0100, I wrote:
> On Fri, Nov 26, 2010 at 01:22:05AM +0100, I wrote:
> > Should refs have simply been initialized to zero (as the zero value is
> > noneffective, and we'll set the ss->thread, etc. values later on)?
>
> At the moment, I don't have the time
Hello!
I hit this again.
On Fri, Nov 26, 2010 at 01:22:05AM +0100, I wrote:
> Should refs have simply been initialized to zero (as the zero value is
> noneffective, and we'll set the ss->thread, etc. values later on)?
At the moment, I don't have the time to analyze this further, but I'll
simply
Thomas Schwinge, le Tue 30 Nov 2010 12:07:05 +0100, a écrit :
> Samuel: what is the correct invocation to only build one flavor of the
> Debian glibc binary packages, that is, don't build the 686 and xen ones,
> but only good 'ol libc0.3?
I don't know whether there is an invocation for this, but y
Hello!
On Mon, Nov 22, 2010 at 11:56:45AM +0100, Samuel Thibault wrote:
> Thomas Schwinge, le Mon 22 Nov 2010 09:38:24 +0100, a écrit :
> >463(err = __mach_port_mod_refs (newtask, ss->thread,
> >464 MACH_PORT_RIGHT_SEND,
> >
Thomas Schwinge, le Mon 22 Nov 2010 09:38:24 +0100, a écrit :
>463(err = __mach_port_mod_refs (newtask, ss->thread,
>464 MACH_PORT_RIGHT_SEND,
>465 thread_refs)))
and
thread_refs =
Hello!
In the GCC testsuite, `expect` had gone bonkers:
$ ps --all --format=hurd-long -w
PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args
[...]
3567 1000 10295 3567 3567 2 137M 856K 98.2 5hrs 28 hours expect
-- /usr/share/dejagnu/runtest.exp --too
14 matches
Mail list logo
