Bug 147806 - libicudata requires execmod
Summary: libicudata requires execmod
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-11 15:38 UTC by Colin Walters
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-07 19:59:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 44377 None None None Never

Description Colin Walters 2005-02-11 15:38:18 UTC
*** This bug has been split off bug 147749 ***

------- Original comment by Paul Nasrat on 2005.02.10 17:22 -------

Description of problem:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
/usr/lib/openoffice.org1.9.75/program/soffice.bin: error while loading shared
libraries: /usr/lib/openoffice.org1.9.75/program/libicudata.so.26: cannot
restore segment prot after reloc: Permission denied

Comment 1 Caolan McNamara 2005-02-16 13:13:12 UTC
a) That exact line above can only come from openoffice.org.1.9.75 which is only
available from people.redhat.com/caolanm, so I'd like to handle it.
b) but from a non-selinux person, what exactly an I supposed to do ? :-)

Comment 2 Colin Walters 2005-02-16 15:13:20 UTC
Essentially what's happening, as far as I understand things, is that the
libicudata library is requesting both writable and executable memory.  It is a
bug in the rawhide SELinux policy that this was being denied by default (we are
going to change it to be allowed by default).  However, it is still better to
change libicudata if possible.

Without looking at the code, it's hard to say what exactly is causing this.  One
cause might be assembly code which does not have GNU-stack marker.

I've added Roland to the CC on this bug; he is an expert in this area and
hopefully he can comment more intelligently than I can.  We do need to put
together a FAQ on this issue.

Again, we will be fixing the rawhide SELinux so this is allowed by default, so
it is not a showstopper issue.

Comment 3 Caolan McNamara 2005-03-07 19:59:13 UTC
Apparently its because this lib isn't getting appropiate -fPIC/-fpic which we
missed because it's makefile is generated dynamically during the icu build
progress. Will be fixed in 1.9.83, upstreamed.

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