[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: latest debian-installer fixes: TITAN compatibility, de2104x support

At 10:45 27.02.2006, Steve Langasek wrote:
> Now I am very happy with alpha support, the only thing is the problem
> with multithreaded apps (the bug in glibc that creates defunct
> processes)! Is there any news about that? This is very annoying
> because there is a patch available for that since about 3-4 months!!!
> Why is nobody able to apply this patch to glibc without discussing
> all the time about pros and cons that does not matter?

Sorry, to you have a pointer to the patch for this?  I don't think there are
any alpha porters actively involved in the glibc packaging right now; I
guess there ought to be, but so far alpha has generally been reliable enough
that there hasn't been a need. :/  Of course, I'm sure even with commit
access I can't apply it without figuring out what pros and cons *do* matter,
so you might want to spell out which ones you believe don't matter :)


This one is the patch:

From: Tom Evans
To: Tom Evans <tom@23palmer.net>
Cc: 325600@bugs.debian.org,  debian-alpha@lists.debian.org
Subject: Re: 325600 (<defunct> threads on Alpha).
Date: Tue, 25 Oct 2005 14:59:24 -0400

If I simply change (in

# define waitpid_not_cancel(pid, stat_loc, options) \
  INLINE_SYSCALL (osf_wait4, 4, pid, stat_loc, options, NULL)


# define waitpid_not_cancel(pid, stat_loc, options) \
  wait4( pid, stat_loc, options, NULL )

all is well - I understand the performance benefits of the inlining,
but since x86 is NPTL anyway, perhaps this is an okay solution?

I'm guessing that there is an Alpha-related optimizer bug perhaps?
Or that the inline_syscall4 in sysdep/unix/alpha/sysdep.h is somehow

My problem with applying this to glibc is the wired build of glibc. It patches files, copies directorys,... during dpkg-buildpackge -> no chance for "normal" programmer to get in a patch.

At this time I use Tom's compiled version of libpthread.so as replacement on my alpha and set libc6.1 to HOLD.
> Or the other chance to fix that: What about NPTL - are the buildd's
> now linux2.6 and can compile NPTL libc's?

I think we have 2.6 on the buildds now, but I don't know what the plans are
for NPTL.  We can't reasonably make a complete switch to NPTL-only until we
know what the upgrade path from sarge will look like, or until after etch's
release; there are already problems with circular deps between the kernels
and the initramfs tools, so we need to plan carefully any changes to this

In i386 I think are both versions of libc in the package, the linuxthreads (in /lib) and NPTL (in /lib/tls) one. The loader chooses the right one depending on kernel etc. Why not the same on alpha?

Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de - http://www.schindlers-software.de
eMails: uwe@thetaphi.de (private); info@schindlers-software.de (company)
Tel./Fax: +49 700 PCLATEIN (+49 700 72528346)

Schindlers Software - Home of Schindlers PC-LATEIN 3.20
DIE Software zum Lateinlernen!

Reply to: