Bug#204691: libc6: stacksize is too small
At 30 Aug 2003 19:27:36 +0100,
Philip Blundell wrote:
>
> On Sat, 2003-08-30 at 17:45, GOTO Masanori wrote:
> > I wonder it's really safe. If we create a lot of threads like Java
> > EJB environment, we consume virtual memory four times faster than the
> > current implementation. You find STACK_SIZE is a boundary for each
> > thread. The right way is to support floating stack (thus libc6-686)
> > or nptl + tls, I think. I'm afraid this patch affects badly.
>
> Ah. Does Java really create that many threads?
Yes, especially enterprise Java environment creates more than 100
threads at the same time. Could you drop this patch?
At Sat, 30 Aug 2003 17:30:13 -0400,
Daniel Jacobowitz wrote:
> On Sat, Aug 30, 2003 at 08:02:05PM +0100, Philip Blundell wrote:
> > On Sat, 2003-08-30 at 18:50, Daniel Jacobowitz wrote:
> > > Or get back to having an i686 libc... this is one of the major
> > > advantages.
> >
> > Yes, indeed. Did we ever manage to find a way to make upgrades safe
> > with this? I guess we could ship both the i386 and i686 versions in the
> > same package, which would avoid any problems at the risk of angering
> > non-i686 users.
>
> I think that would be safe. I also think it's a good idea. Doesn't
> dpkg have a filter-directories feature, or did that never happen? Hmm,
> looks like it never happened.
>
> If we had versioned provides, we could do it that way instead...
Yes, I agree. Only concern is where do we put ld-linux.so.2 -
/lib/ld-linux.so.2 (i386) and /lib/i686/ld-linux.so.2 (i686) ?
BTW, the big problem is that application using linuxthreads gets
sigsegv when I use glibc which compiled with -march=i686 option. This
is the reason why I have not introduced libc6-i686 for a long time.
It breaks after issuing modify_ldt instruction. I guess Redhat patch
has some workaround modifications, or it's toolchain issue. It needs
more investigations for supporting i686 libc6, tls, and nptl.
Regards,
-- gotom
Reply to: