Hi Dan,
I apologize for my tardiness in thanking you for your interest in this.
In desperation, I had sent a cold e-mail to Roland McGrath (content at the end,
section 5).
He seemed to be one of the people most involved in glibc so I said what the
heck.
I left a period of time to account for possible delays; no reply (yet) so this
thread can be considered de facto dead and closed.
However, I'm taking the liberty to add a few extra words in hopes that some
other poor soul might find some useful references if in a similar situation.
1. In my research I found some similar thoughts in a thread at this address:
"overlays.gentoo.org/dev/kevquinn/changeset/176".
If it is hard to reach, here's a few relevant snippets:
<< Things to work out: Why all those mutex/robust (barrier) checks fail on x86
with a hardened kernel (only!)
Didn't expect signal from child: got `Aborted'
This happens when the parent tries to lock the mutex; at this point the child
has finished - well, it has aborted, which it shouldn't have done.
This is consistent with the child process aborting, instead of going to an idle
state waiting to be cleaned up when the parent finishes.
Investigation ongoing... >>
As an aside, I don't know what "x86" means nowadays. Does it include AMD
processors, for example? (BTW, mine is intel P4 3.06 MHz with Hyper Threading
and 1GB memory)
2. The unsettling aspect of current glibc tests is that if you somehow believe
you're "clean" and the failure might be a bug, its submission will be quietly
and unceremoniously dumped into the big round hole #333 (half of 666?) never to
be seen again.
If you then try to talk to someone, my first paragraph above shows what will
happen.
3. Even more annoying for my particular failure, the offending file,
'tst-cpuclock2.c', is dated 2005-04-27. Come to think of it, a lot of kernels
and architectures have come and gone since.
I'm wondering whether those pesky pthreads might be wiggling differently now
than they were expected to in 2005!
4. I'll bite the bullet and install v2.5 despite these two failures. If my
machine goes up in smoke one day at least I'll have only myself to blame for
deliberately enabled a killer pthread to lurk around ready to pounce on the
first favorable opportunity.
5. Here is the relevant text from my e-mail to Roland:
<< I've been trying to upgrade to glibc-2.5.
On tests ('make check') I get failures.
PROBLEM
'libc-2.5/nptl/tst-cancel1.c'
fails with glibc-2.5/test-skeleton's message,
"Didn't expect signal from child: got `Aborted'".
Obviously, I can insert a line in tst-cancel1.c,
"#define EXPECTED_SIGNAL SIGABORT"
and everything will "appear" to be fine.
In my amateurish sleuthing all I could find is
that the child thread, started by the parent on
"pthread_create", aborts at his last step,
"pthread_mutex_lock (&m1)"
when something happens during parent's
"pthread_join" attempt.
QUESTIONS about this problem:
1. Should I ignore it?
2. Is it developers' or
3. Is it mine?
Any help will be highly appreciated. >>
Thanks again,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
