Bug 116136 - Prelink causes memory access fault with guarddog
Prelink causes memory access fault with guarddog
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: prelink (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-18 10:52 EST by Steffen Schramm
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-28 12:35:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steffen Schramm 2004-02-18 10:52:22 EST
Description of problem:

Prelink causes a memory access fault when guarddog is run.

[root@localhost root]# guarddog
Speicherzugriffsfehler

"Speicherzugriffsfehler" means memory access fault.

Methods to fix: 

- Reinstalling guarddog
- Calling "prelink -u /usr/bin/guarddog"

Version-Release number of selected component (if applicable):

[root@localhost root]# prelink --version
prelink 1.0

[root@localhost root]# guarddog --version
Qt: 3.1.2
KDE: 3.1.4-4 Red Hat
Guarddog: 2.2.0

Used guarddog rpm for Red Hat 9 from
http://www.simonzone.com/software/guarddog/guarddog-2.2.0-1rh9.i386.rpm

How reproducible:

Running guarddog when prelink was run

Steps to Reproduce:
1. Install guarddog from
http://www.simonzone.com/software/guarddog/guarddog-2.2.0-1rh9.i386.rpm
2. Test if it runs
3. Wait for prelink to run with cron or run manually
4. Run guarddog -> memory access fault
  
Actual results:


Expected results:


Additional info:

Perhaps problem exists because of RedHat 9 rpm of guarddog. There was
no special fedora rpm on guarddog site, and no fedora package with
"yum install guarddog", so I chose this. Besides the memory access
fault it works good.
Comment 1 Jakub Jelinek 2004-02-19 04:10:46 EST
First step would be to verify there is no memory management bug
in guarddog.  Can you run
EF_ALLOW_MALLOC_0=1 LD_PRELOAD=libefence.so.0 guarddog
on unprelinked binary and see if it crashes as well?
Comment 2 Steffen Schramm 2004-02-19 05:23:17 EST
Didn't have a libefence.so.0 file. Found one in package called
ElectricFence from
http://www.itp.tu-graz.ac.at/Comp/RPM/rh-9/ElectricFence-2.2.2-15.i386.htm

No idea if this is correct. Then executed the command:

[root@localhost root]# EF_ALLOW_MALLOC_0=1 LD_PRELOAD=libefence.so.0
guarddog
 
  Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens
<bruce@perens.com>


Result: This copyright message is the only output. No guarddog window
appears, and no other message is written to console window.
Comment 3 Steffen Schramm 2004-02-19 05:26:47 EST
Sorry, url is

http://www.itp.tu-graz.ac.at/Comp/RPM/rh-9/ElectricFence-2.2.2-15.i386.html
Comment 4 Jakub Jelinek 2004-02-19 05:27:20 EST
ElectricFence is part of FC1, so just up2date ElectricFence
should be all that is needed.
Please use rather the one in the distribution.
Can you run
gdb `which guarddog`
set env EF_ALLOW_MALLOC_0=1
set env LD_PRELOAD=libefence.so.0
run

and see where it crashes?
Comment 5 Steffen Schramm 2004-02-21 09:40:34 EST
Hm ok, I installed ElectricFence via yum. Didnt really crash with your
commands, so I did following tests

Unprelinked Guarddog, gdb with the set env commands (what you wanted):
Tells about not found debugging symbols, no crash info visible,
guarddog window doesnt show

Unprelinked Guarddog, gdb with direct "run": Same output, but guarddog
window appears

Prelinked guarddog, gdb with the set env commands: No crash info,
guarddog doesnt show..same as with unprelinked

Now to the more interesting: Prelinked guarddog, direct gdb with "run"

[root@localhost] gdb `which guarddog`
(gdb) run

--> Last output lines are:

(no debugging symbols found)...[Thread debugging using libthread_db
enabled]
[New Thread 1073856768 (LWP 4825)]
(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1073856768 (LWP 4825)]
0x03300670 in ?? ()
(gdb)

I hope it helps.
Comment 6 Matthew Miller 2006-07-11 13:37:35 EDT
Fedora Core 1 is maintained by the Fedora Legacy project for security updates
only. If this problem is a security issue, please reopen and reassign to the
Fedora Legacy product. If it is not a security issue and hasn't been resolved in
the current FC5 updates or in the FC6 test release, reopen and change the
version to match.

Thanks!

NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy
project. After Fedora Core 6 Test 2 is released (currently scheduled for July
26th), there will be no more security updates for FC1. Please use these next two
weeks to upgrade any remaining FC1 systems to a current release.

Comment 7 John Thacker 2006-10-28 12:35:23 EDT
Closing per lack of response to previous comment.  Note that FC1 and FC2 are no
longer supported even by Fedora Legacy.  If this still occurs on FC3 or FC4,
please assign to that version and Fedora Legacy.  If it still occurs on FC5 or
FC6, please reopen and assign to the correct version.

Note You need to log in before you can comment on or make changes to this bug.