2:10 p.m.
Hi,
I'm a bit worried because we've been seeing a number of issues recently
that seem to be related to prelink. For example, we've been looking at
this bug today:
http://bugzilla.gnome.org/show_bug.cgi?id=151307
Debugging this locally, we found that the hal daemon segfaulted very
quickly on startup, dying inside libdbus. However, it worked inside
valgrind. Havoc yesterday mentioned that if he re-prelinked libdbus, it
worked. We were able to confirm that.
A secondary issue is that we've occasionally seen shared libraries
suddenly not having the right SELinux contexts:
http://bugzilla.redhat.com/show_bug.cgi?id=139860
This has come up on earlier on this list too:
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00526.html
The hal/dbus issue appears to be reproducible on FC3+updates, but not
with stock FC3. My guess is that letting prelink run on stock FC3 might
cause this too, I'm about to check that.
Has anyone else seen any odd issues with their packages that might be
related to prelink? I wonder if there's a common thread here.
2:28 p.m.
On Fri, 19 Nov 2004 15:10:19 -0500, Colin Walters wrote:
Has anyone else seen any odd issues with their packages that might
be
related to prelink? I wonder if there's a common thread here.
I've noticed users [in other message boards] who have had various
applications and/or GNOME segfault until they started the prelink cron
job file manually and let it complete.
--
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.678_FC3
loadavg: 0.61 0.68 0.45
3:48 a.m.
On Fri, 2004-11-19 at 21:28, Michael Schwendt wrote:
On Fri, 19 Nov 2004 15:10:19 -0500, Colin Walters wrote:
> Has anyone else seen any odd issues with their packages that might be
> related to prelink? I wonder if there's a common thread here.
I've noticed users [in other message boards] who have had various
applications and/or GNOME segfault until they started the prelink cron
job file manually and let it complete.
I noticed this and some debugging showed that those gnome apps -
eggcups, and gnome-volume-manager in this case - segfaulted on
hal_initialize().
rpm -V hal screemed about dependecy changes.
To run prelink on hal binaries fixed this issue.
--
Iago Rubio
- Home page * http://www.iagorubio.com
- Last project * http://cssed.sourceforge.net
- GPG Keyserv * pgp.rediris.es id=0x909BD4DD
2:59 p.m.
On Fri, Nov 19, 2004 at 03:10:19PM -0500, Colin Walters wrote:
The hal/dbus issue appears to be reproducible on FC3+updates, but
not
with stock FC3. My guess is that letting prelink run on stock FC3 might
cause this too, I'm about to check that.
If you are able to reproduce it, please create a tarball containing
the binary and all its dependencies (do ldd on the binary and tar
everything up).
Has anyone else seen any odd issues with their packages that might
be
related to prelink? I wonder if there's a common thread here.
Even if packages misbehave when prelinked and don't when not prelinked,
there is no guarantee prelink is at fault.
Prelink changes the memory layout of the application, so if certain
library or binary e.g. has memory management bugs, it can show up
only with certain memory layouts and not with others.
Anyway, if you have a reproducer and tar up the binary, all libraries
and whatever else is necessary for reproduction, that goes away
if you unprelink the binary or its libraries, I'll certainly look at
it.
Jakub
3:33 p.m.
On Fri, 2004-11-19 at 15:59 -0500, Jakub Jelinek wrote:
On Fri, Nov 19, 2004 at 03:10:19PM -0500, Colin Walters wrote:
> The hal/dbus issue appears to be reproducible on FC3+updates, but not
> with stock FC3. My guess is that letting prelink run on stock FC3 might
> cause this too, I'm about to check that.
If you are able to reproduce it, please create a tarball containing
the binary and all its dependencies (do ldd on the binary and tar
everything up).
I just tried a fresh FC3 install, ran prelink -a, didn't have any
problem. I then installed all the FC3 updates, logged out and logged
back in, no problem. (Except the latest FC3 kernel fails to boot on my
machine, but that's another bug)
Even if packages misbehave when prelinked and don't when not
prelinked,
there is no guarantee prelink is at fault.
Right, I understand that.
Prelink changes the memory layout of the application, so if certain
library or binary e.g. has memory management bugs, it can show up
only with certain memory layouts and not with others.
Ok. I'm a bit baffled as to why this should only show up now if that's
what's happening though. I've gotten about 5-6 reports of this against
eggucups upstream just in the last few days.
Anyway, if you have a reproducer and tar up the binary, all
libraries
and whatever else is necessary for reproduction, that goes away
if you unprelink the binary or its libraries, I'll certainly look at
it.
Will do.
3:36 p.m.
On Fri, Nov 19, 2004 at 04:33:00PM -0500, Colin Walters wrote:
> Anyway, if you have a reproducer and tar up the binary, all
libraries
> and whatever else is necessary for reproduction, that goes away
> if you unprelink the binary or its libraries, I'll certainly look at
> it.
Will do.
Note that the important thing is to tar them up before unprelinking,
if the bug goes away after unprelinking, when you prelink -u it is
usually to late.
tar chjf foo.tar.bz2 `LD_TRACE_PRELINKING=1 LD_WARN= /path/to/program | awk '{print
$3}'`
should do the job.
Jakub
3:59 p.m.
On Fri, 2004-11-19 at 16:36 -0500, Jakub Jelinek wrote:
On Fri, Nov 19, 2004 at 04:33:00PM -0500, Colin Walters wrote:
> > Anyway, if you have a reproducer and tar up the binary, all libraries
> > and whatever else is necessary for reproduction, that goes away
> > if you unprelink the binary or its libraries, I'll certainly look at
> > it.
>
> Will do.
Note that the important thing is to tar them up before unprelinking,
if the bug goes away after unprelinking, when you prelink -u it is
usually to late.
tar chjf foo.tar.bz2 `LD_TRACE_PRELINKING=1 LD_WARN= /path/to/program | awk '{print
$3}'`
should do the job.
Jakub
wnck-applet was segfaulting immediately when I logged in to GNOME. After
debugging, I discovered it was dying on a call into libstartup-
notification-1.so.0. For the hell of it, I reversed and then redid wnck-
applet's prelinking, and it worked fine.
So, yes, there is some kind of prelink problem going on.
Of course, I completely forgot to make a backup copy of the mangled
wnck-applet, so this doesn't help you much beyond a "me too!" (Although,
this is an AMD64 system, so that might be another data point).
--
Nicholas Miell <nmiell(a)comcast.net>
9:17 p.m.
RedHat bug #140081 has tarred up libraries attached that are effected by
the prelink bug.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140081
On Fri, 2004-11-19 at 16:36, Jakub Jelinek wrote:
On Fri, Nov 19, 2004 at 04:33:00PM -0500, Colin Walters wrote:
> > Anyway, if you have a reproducer and tar up the binary, all libraries
> > and whatever else is necessary for reproduction, that goes away
> > if you unprelink the binary or its libraries, I'll certainly look at
> > it.
>
> Will do.
Note that the important thing is to tar them up before unprelinking,
if the bug goes away after unprelinking, when you prelink -u it is
usually to late.
tar chjf foo.tar.bz2 `LD_TRACE_PRELINKING=1 LD_WARN= /path/to/program | awk '{print
$3}'`
should do the job.
Jakub
5:11 a.m.
Ok. I'm a bit baffled as to why this should only show up now if
that's
what's happening though. I've gotten about 5-6 reports of this against
eggucups upstream just in the last few days.
Happened here today with a FC3 install plus all updates. Will check this
out if I find further time today or tomorrow morning.
eggcups segfault directly on startup.
greetings,
Florian La Roche
4:51 p.m.
Colin Walters wrote:
A secondary issue is that we've occasionally seen shared
libraries
suddenly not having the right SELinux contexts:
http://bugzilla.redhat.com/show_bug.cgi?id=139860
This is as likely to be that sometimes packages do
%post -p /sbin/ldconfig
and somethimes
%post
/sbin/ldconfig
and sometimes something else entirely handling sonames.
The problem is well known, has poppped up repeatedly, is way too complicated
to analyze back to the root cause (which was that only /bin/sh has
"rpm_script_t" as
exec context type), is "fixed" in rpm-4.3.3 (for FC4), and will be fixed
elsewhere
as soon as I find a "rpm_execcon" symbol in a libselinux that I can link
against,
and the problem is almost certainly going to reappear a few more times
because
of the complicated logistics of matching libselinux, a version of rpm,
and current policy
on user machines with the volume of changes that are now pretty routine
in FC.
So please make sure you're running rpm-4.3.3 and whatever libselinux is
current
in FC4 before claiming anything about *.so file contexts going awry.
Again, just a hunch, I have insufficient detail to chase the problem
home. Wanna bet? ;-)
73 de Jeff
5:05 p.m.
On Fri, 2004-11-19 at 17:51 -0500, Jeff Johnson wrote:
The problem is well known, has poppped up repeatedly, is way too
complicated
to analyze back to the root cause (which was that only /bin/sh has
"rpm_script_t" as
exec context type), is "fixed" in rpm-4.3.3 (for FC4), and will be fixed
elsewhere
as soon as I find a "rpm_execcon" symbol in a libselinux that I can link
against,
I've seen this on targeted machines too, where rpm and scriptlets run as
unconfined_t, correct? The above bug report is against selinux-policy-
targeted too.
5:22 p.m.
Colin Walters wrote:
On Fri, 2004-11-19 at 17:51 -0500, Jeff Johnson wrote:
>The problem is well known, has poppped up repeatedly, is way too complicated
>to analyze back to the root cause (which was that only /bin/sh has
>"rpm_script_t" as
>exec context type), is "fixed" in rpm-4.3.3 (for FC4), and will be fixed
>elsewhere
>as soon as I find a "rpm_execcon" symbol in a libselinux that I can link
>against,
>
>
I've seen this on targeted machines too, where rpm and scriptlets run as
unconfined_t, correct? The above bug report is against selinux-policy-
targeted too.
All machines, all policies, all rpm's earlier than rpm-4.3.3. The
problem is one of
mix-n-match, not any specific flaw.
Dunno about "unconfined_t" symptom, dwalsh knows the problem details
better than I do.
Look for Smalley's rpm_execcon patch post in September for the last
known manifestation
and analysis of the causes if you wish to understand the gory details to
confirm the problem.
73 de Jeff
7105
days inactive
7107
days old
11 comments
8 participants
participants (8)
-
Colin Walters -
Florian La Roche -
Iago Rubio -
Jakub Jelinek -
Jeff Johnson -
John (J5) Palmieri -
Michael Schwendt -
Nicholas Miell