Bug 173078 - xorg-x11-xfs - "double free or corruption" on error
xorg-x11-xfs - "double free or corruption" on error
Product: Fedora
Classification: Fedora
Component: xorg-x11-xfs (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
Depends On:
Blocks: FC5Target
  Show dependency treegraph
Reported: 2005-11-13 14:47 EST by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-09 10:38:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2005-11-13 14:47:51 EST
Description of problem:

Due to something I missed in some "recovery actions" I managed to set 700
permission on /usr and I failed to notice that right away.  This clearly
put a spanner in xfs works as for every fonts.dir I got something like:

open("/usr/X11R6/lib/X11/fonts/misc/fonts.dir", O_RDONLY) = -1 EACCES
(Permission denied)

when '-droppriv' was in use.

So far so good, although X server got clearly unhappy, but that brought to
light two problems.  One is that I still got "[ OK ]" from /etc/rc.d/init.d/xfs
even if 'service xfs status' was immediately reporting "xfs dead but subsys

The other is that when I tried to run 'xfs -droppriv' but in a foreground I got:

*** glibc detected *** xfs: double free or corruption (!prev):
   0x000000000051cd40 ***

This seems to indicate that something is not right on an error handling path.

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

How reproducible:
always in circumstances described above.
Comment 1 Mike A. Harris 2006-01-20 12:57:56 EST
If possible, could you test FC5test2 or newer to see if the same problem
still occurs?
Comment 2 Michal Jaegermann 2006-01-20 17:37:15 EST
Currently installed xfs is xorg-x11-xfs-1.0.0-2 and I do not see glibc
complaints when fonts directories are unreadable.  A process started with
'-nodaemon -droppriv' just does not terminate.

It still starts with an "OK" status even where is not a single font to serve.
This may be expected.
Comment 3 Mike A. Harris 2006-02-09 04:33:36 EST
Reading comment #2, it sounds like the problem reported in the initial report
is fixed now, can you confirm that?

It isn't clear if comment #2 is also trying to state a second bug is present
or not, however if that is the case, a new bug report should be filed
separately for each bug that is discovered for proper tracking/closure of
each issue.


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