segfault in ld-2.14.so running alsa-utils
 

I just built LFS-SVN-20110717,
added a few things from blfs
and now wanted to install alsa.

I first tried using alsa-lib-1.0.24.1
-> installed without problems
and alsa-utils-1.0.24.2
-> 'make' showed, that it required xmlto
-> I tried using the alsa-utils-1.0.21-no_xmlto-1.patch
from blfs.
-> This worked only partially, but compilation
and installation was possible then.

Running speaker-test however gave me a sefault:
I got the same segfault trying to run aplay.

-> I deinstalled alsa-utils-1.0.24.2 and alsa-lib-1.0.24.1
using 'make uninstall'.
-> No error.
-> Tried the same with alsa-lib-1.0.21 and alsa-utils-1.0.21
exactly as described in blfs.
The patch worked completely (with a little offset),
no problems compiling and installing.

-> same segfault as above trying speaker-test or aplay.

What is wrong with this?
How can I fix it?

I did not find anything that helped me
using google yet.

I'm running into the same problem... after upgrading glibc to 2.14 (without the LFS patch, it did compile with gcc-4.5.1).
At first I noticed mplayer would crash when attempting to output thru alsa or oss (oss emulated by alsa on my system) but not when outputting thru libsdl.
Also aplay crashes with a very similar message.

This makes me think that the error-triggering code lays somewhere in alsa-lib. I've upgraded to the latest alsa libs and utils, without solving anything :-( Tried switching back from kernel 3.0.0 to 2.6.39... still no luck. The interesting thing is that does play w/o any troubles.
If it helps, I'm running a pure-64bit system built from scratch. Any ideas are welcome.

Mine is a 32bit system X86 (Athlon?).
I built lfs exactly as the book said,
so I must have applied all the patches
even though, I have no very vivid recall of this glibc patch.

Linux-2.6.39.3 was the only kernel I used with the system in question.

I suspect it could be some bug in glibc or something that made
it kind of incompatible with alsa.
I'm rather ill prepared / ignorant / inexperienced
to investigate such a thing on my own.

But I did not strip the debugging symbols yet
and could possibly help that way,
if someone would be willing to do some serious tutoring with me. ;-)

I'm kind of hoping that, it could only be a small part of glibc
and therefore not require a complete new build of it. ;-)

Edit:
@Aky^: what version of glibc, did you use before this upgrade?

The glibc I've been using before is 2.11.2, and aplay (1.0.22) and everything else alsa-related used to work. One more thing seems to be pointing towards glibc as the guilty one here: been running aplay thru gdb and I've got this: Digging into the glibc changelog, there's been a couple of changes to the do_lookup_x() function, since version 2.13, maybe we should file a bug with redhat?

I'm tempted to rule out the kernel version as being the problem, as the only kernel header included from aplay.c is something which should be invariant for a given CPU architecture (little-endian for us): I'm also tempted to rule out the alsa version, since upgrading 1.0.22 > 1.0.24.1 didn't change anything.

I would have liked to check that issue with gdb myself.
(And post the results)
But I can't find it. :confused:

/usr/share/gdb really is a directory.
I didn't find it in /tool/... either.

I thought it was somehow contained in the lfs
base installation, but it seems not.
There is no entry of gdb in the blfs index either.

OK - I did find it mentioned on the page
about "Other Programming Tools" in blfs.

It is/was kind of hard for me to envision,
that gdb would be a package of its own,
not contained with gcc or somehow installed with lfs/blfs anyways,
as I am/was very convinced otherwise.

I guess, I'll get to installing and using it sometime later on,
when I get back to the other system again...
(No promise about the when yet.)

I installed gdb-7.3 as per the instruction from
wiki.linuxfromscratch.org/blfs/wiki/OtherProgrammingTools
(with ... make -C gdb install not to overwrite binutils files)

Now, I find gdb has fixed the aplay problem.

aplay now works without segfault!
But speaker-test still does segfault.

Maybe I should have installed gdb without the -C switch
and it would have repaired the speaker-test problem as well. ;-)

I uninstalled alsa-*-1.0.21 again and went back to alsa-*-1.0.24*
and got the same behavior.

aplay works:before installing gdb I called aplay without any parameters and it segfaulted.
I was kind of wondering, why nothing would happen, when I tried to run it that way via gdb -
until I found out, the segfault was gone. ;-)

speaker-test still segfaults:only minor differences with version 1.0.24..Does anyone know what that really means?

Why is there "dl-lookup.c: No such file or directory"?

Would this hint to a solution?

Sadly, this is not really the case. :cry:

Based on that assumption I continued building the system.
-> No problems compiling, and installing.
Mostly audio related tools.
Even the test suites run OK.

ogg123 seemed to work,
play (from sox) segfaults when used with parameters
(not when called without).

aplay apparently works, when I do:otherwise it segfaults.
(even when called without parameters)
I set LC_ALL and LANG as above, so I would get generic,
English feedback for posting.
So it was probably that circumstances that led me
to think gdb fixed the "aplay problem".

Some more output:Any help for understanding and fixing the problem would be greatly appreciated!

Something is not perfect with glibc[-2.14].:tisk:

I just took some "hard way" learning experiences:

• Compared do_lookup_x in dl-lookup.c of the last few releases of glibc,
  didn't find a difference there. That would have been too easy
  and probably not have been overlooked be the developers,
  but it seemed worth a try.
• Installed glibc-2.13
  -> saw aplay and play segfault
• Installed glibc-2.12.2
  -> still saw aplay and play segfault
  -> got suspicious ...

Now I realized that the situation to be observed
was a little too equal to the one observed in the beginning. ;-)
Did I see "ld-2.14.so" ?
Shouldn't that be something like "ld-2.12.2.so", if at all?

The "installations" of glibc-{2.13,2.12.2} made(?) links pointing to libraries from another version of glibc! - wtf

Just in case, there is something, I should have read, that says glibc installation
would behave that way (and maybe there is such and such a switch to change that),
someone please point me to that!

It is easily possible, that I have overlooked such,
but I find such behavior very counter intuitive and NOT useful. :(
(If there is no *good* reason for it.)

Nowsuddenly made play and aplay work normally.

So the bug is probably in glibc-2.14!

I believe, you certainly are right about, that a bug report should be filed.

What I am confused about, is that I would never have gotten the idea,
that readhat was the maintainer of glibc...:confused:

:scratch:
I still do have a need for tips about how to really, cleanly
go to another version of glibc!

Obviously the installation instructions in lfs do not cover setting those
links in /lib (/usr/lib ? and where else ?),
as lfs is designed for the initial installation.

???
Can I now just change those links pointing to *-2.14.* libraries
to shift the glibc-version?

I would kind of like that idea,
but how not to overlook something here?

I doubt that I could just uninstall the current version of glibc?
Or maybe that would solve it and point the links to the newest
remaining version of glibc?

(Preferably helpful) feedback is welcome.

a linux system kill switch exposed
 

How to disable a linux system in on quick and easy command. ;-)

I'll describe it for the conditions prepared earlier as mentioned above.
It should not be to difficult to come up with a similar "solution",
that does not require such preparation. ;-) :-) ;-)

Glancing through the docs... that came with the glibc source package,
I came across ways how to detect, what version of glibc is currently installed on the system:

A) ExcecuteThis will output some infos about the current glibc-version
along with copyright and such.
But might not work on all systems.

B) Compile and run a small program
(translated to the lfs way, to make it more comfortable):This will only output the short string of the glibc-version itself,
such as "2.14" in the case of the system used above.
This should work on all systems.

I even found, that I could use that same executable file on my other system as well
and it worked to show the correct glibc-version for that system.

Now, for the system disabling part:This gave me the idea to check whether I would get a different output
for the version, if I pointed libc.so.6 to libc-2.13.so.

I already felt, that this would probably mean trouble
and planed to change it back to its current target asap.

So I entered, what I now know as the "system kill switch":Thereafter E V E R Y T H I N G, I tried to run on that system
resulted in a segfault!

I could not log out or shutdown the system.
I could change to another virtual tty, but had the same situation everywhere.
Not even <Ctrl>+<Alt>+<Del> did anything else but segfault.

However the computers reset switch still worked. lol


What this wanted to teach me, probably was,
that you could not change the glibc-version of a system,
without rebuilding it, or some very similar lesson.

Still, I seem to be able to utilize "ld-linux.so.2 -> ld-2.13.so"
in a glibc-2.14 system and thereby get rid of the problems mentioned above. :-)

You should be able to fix your system if you can boot from another partition (or a live cd) and fix the symbolic link from there. This is an interesting thread with some good detection work. I hadn't noticed that aplay and speaker-test were segfaulting 'cos other audio applications are working normally.

If anyone files a bug about this could they post a link to it in this thread please

Thanks for your kind feedback, Andrew. :-)

Yes, I already did so.
This was rather obvious to me.

In fact, I had to use a (knoppix) live cd to build my new LFS system
as my old system was too old and did not meet the system requirements.

But I used the old system to fix that link issue,
as it is way faster and more comfortable than the live cd.

What (audio) apps segfault under what detailed circumstances
with glibc-2.14, seems not entirely obvious to me.

play (from sox) also segfaulted.
aplay did not segfault, if using some special environment settings. (see above)


If I'd be building a new LFS system,
I'd rather use glibc-2.13 than glibc-2.14!


I agree, this seems to be a good idea.

Been trying to pinpoint the exact commit after which the breakage occured, but after trying out a few snapshots from sourceware's git, they all exhibit the same bug... and since I don't have enough time to build, install and test tens of snapshots, I ended up reverting to glibc-2.13.

So for now I'll just enjoy a working do_lookup_x() and hope that 2.15 will fix this.

cheers!

Now I ran into the limits of this setup (glibc-2.14 using ld-2.13.so):

Trying to install openssl-1.0.0d, configure produced a segfault in ld-2.13.so!

I could set /lib/ld-linux.so.2 back to ld-2.14.so and I could configure ...
and install it without problems.

Then I set ld-linux.so.2 back to ld-2.13.so again.

The commandline tool openssl seemed to work this way.

So I compiled links with ssl support.

Now, when I point links to an https site, I get a segault in ld-2.13.so!

I can make links work with https sites, by switching back to ld-2.14.so.

This way, I would need a tool to dynamically select to version of the
dynamic linker used, depending on the program that will use it.


Did anyone get such things to work with glibc-2.13?

@Aky^: You seem to have a way of completely/cleanly reverting to glibc-2.13.
How can this be achieved?

Bad news, I've just rebuilt with current glibc git head and the problem remains

I rebuilt an LFS system using glibc-2.13, Linux-2.6.39.4.

So far, I did not encounter any major problems.

Alsa, as well as Openssl could be built and worked
without any segmentation errors. :-)