I imagine that no one followed up on the bug because the it was marked
as closed with the RESPONSE
that 2.5-exp3 *is* the fix for #325600.
That gave many of us the expectation that a 2.5 series glibc would
make its way into testing and then to
stable with the Etch release, I mean why else would the maintainers
mark such a critical bug as being fixed
in that way?
It really wasn't an issue so long as the glibc in stable was okay - no
one was expecting Etch to be released
with that flawed glibc because it was MARKED as closed (granted with a
2.5 series that made little sense).
I for one don't understand why the patch offered in #325600 and
haven't had
a chance to examine the consequences of the proposed change.
Further, your
comments in the bug that the real bug might be an optimizer bug, or a
broken
inline_syscall4 implementation, don't inspire me to urge the glibc
maintainers to apply such a patch without digging a lot deeper into it
myself.
I do not understand the first sentence above, but I'm so sorry that I
offered a possible list of explanations.
Perhaps it would have been better to have posted fewer details about
the experience of tracking it
down to the single line of code where the problem was located.
Sometimes in complicated software, one cannot always easily find and
understand the root cause failure.
I took it as far as I could in the time I had - I thought that passing
it to the "experts" was the correct thing to do.
I noticed that in newer glibc sources that the not-cancel.h header
file is now separated via architecture.
There is one for i386, sparc, x86_64, etc (they all point to the i386
version at the moment), but that implies
that an alpha specific version is possible and with that, a change
that ONLY affects alpha should be possible.
...tom