Bug 1164209

Summary: hevea segfaults when creating docs for ejabberd
Product: [Fedora] Fedora Reporter: Dan Horák <dan>
Component: ocamlAssignee: Richard W.M. Jones <rjones>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: c.david86, normand, rjones
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: Unspecified   
Whiteboard:
Fixed In Version: ejabberd-14.07-6.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-18 12:31:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1071880, 1051573    

Description Dan Horák 2014-11-14 11:05:14 UTC
hevea segfaults when creating docs for ejabberd, see eg. http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2181864 or http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2181914


Version-Release number of selected component (if applicable):
hevea-2.16-2.fc21.ppc64le
hevea-2.16-2.fc21.ppc64

Comment 1 Richard W.M. Jones 2014-11-14 11:11:08 UTC
Do you happen to know if this happens on F22 as well?

CC-ing Michel Normand who wrote the ppc64le backend.

Comment 2 Richard W.M. Jones 2014-11-14 11:12:53 UTC
The other thing to try would be increasing the stack size, since
ppc64 code often needs a lot more stack than is available by default.

Put something like:

%ifarch ppc64 ppc64le
ulimit -a
ulimit -Hs 65536
ulimit -Ss 65536
%endif

(or larger even) before the make.

Comment 3 Dan Horák 2014-11-14 11:38:41 UTC
yeah, the larger stack helps - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2182090

diff --git a/ejabberd.spec b/ejabberd.spec
index 14d374a..55a9e26 100644
--- a/ejabberd.spec
+++ b/ejabberd.spec
@@ -150,6 +150,11 @@ autoreconf -ivf
 make
 %if 0%{?_with_hevea}
 pushd doc
+%ifarch %{power64}
+ulimit -a
+ulimit -Hs 65536
+ulimit -Ss 65536
+%endif
 # remove pre-built docs
 rm -f dev.html features.html
 # See this link - http://thread.gmane.org/gmane.linux.redhat.fedora.devel/198954/focus=198957

Comment 4 Richard W.M. Jones 2014-11-14 11:47:29 UTC
I believe you can coalesce the two ulimit statements into just:

  ulimit -s 65536

This is not the first package we've had to do this for.  I
wonder if we can increase the default stack size on ppc64/le?
Honestly I've never seen the point of limiting stack in the
first place - we don't limit any other type of memory by default.

Comment 5 Dan Horák 2014-11-14 11:57:34 UTC
I have already seen also on s390(x) that the default stack was too small. Is the limit a kernel default? I think there is a relation between the default stack size and the number of available processes/thread before they get memory exhausted. But I agree maybe it is the right time to change the too low deaults.

Comment 6 Fedora Update System 2014-11-14 12:14:06 UTC
ejabberd-14.07-6.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/ejabberd-14.07-6.fc21

Comment 7 Richard W.M. Jones 2014-11-14 12:38:58 UTC
I'm guessing it is a kernel default.  However the best place
to change the default might be in /etc/security/limits.conf
which is in the 'pam' package.  I'm not sure if limits.conf
applies only to logins, or to every process.

Comment 8 Fedora Update System 2014-11-15 09:22:24 UTC
Package ejabberd-14.07-6.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ejabberd-14.07-6.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15140/ejabberd-14.07-6.fc21
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2014-11-18 12:31:31 UTC
ejabberd-14.07-6.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.