Description of problem:
/usr/bin/ocamlc.opt -c -w ZY -o entry.cmi entry.mli
/usr/bin/ocamlopt.opt -c -w ZY -o entry.cmx entry.ml
/usr/bin/ocamldep.opt -modules info.ml > info.ml.depends
/usr/bin/ocamllex.opt -q latexscan.mll
+ /usr/bin/ocamllex.opt -q latexscan.mll
Command got signal -10.
make: *** [ocb-opt] Error 11
error: Bad exit status from /var/tmp/rpm-tmp.HV3MWA (%build)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. ppc-koji build --scratch f18 hevea-1.10-8.fc18.src.rpm
It might be worth upgrading to the latest upstream version (2.09) and see if this bug is still present. I'll give it a try because hevea is the only missing buildreq for ocaml-cil on ppc.
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.
Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
This still happens on ppc64 in Rawhide, with hevea 2.12, ocaml-4.01.0-4.fc21.ppc64 and glibc-2.18.90-17.fc21.ppc64. Running inside gdb shows this backtrace:
#0 0x00000000100440c4 in caml_modify (fp=0x1fffffa3f558, val=35184367108608)
#1 0x0000000010024e20 in .camlLexing__engine_1041 ()
#2 0x000000001001593c in .camlLexer____ocaml_lex_action_rec_1066 ()
#3 0x0000000010015ce4 in .camlLexer__action_1065 ()
#4 0x0000000010015c94 in .camlLexer____ocaml_lex_action_rec_1066 ()
[Frames 3 and 4 repeat, with small variations in the addresses]
#58209 0x0000000010015ce5 in .camlLexer__action_1065 ()
#58210 0x0000000010015c5d in .camlLexer____ocaml_lex_action_rec_1066 ()
#58211 0x0000000010015ce5 in .camlLexer__action_1065 ()
#58212 0x00000000100154e5 in .camlLexer__handle_lexical_error_1023 ()
#58213 0x00000000100172c9 in .camlLexer____ocaml_lex_main_rec_1060 ()
#58214 0x0000000010017565 in .camlLexer__main_1059 ()
#58215 0x00000000100169f1 in .camlLexer____ocaml_lex_main_rec_1060 ()
#58216 0x0000000010017565 in .camlLexer__main_1059 ()
#58217 0x0000000010025b7d in camlParsing__code_begin ()
#58218 0x00000000100265e1 in .camlParsing__yyparse_1071 ()
#58219 0x00000000100059f5 in .camlMain__main_1017 ()
#58220 0x0000000010005e1d in .camlMain__entry ()
#58221 0x0000000010002b19 in caml_startup__code_begin ()
#58222 0x000000001005a181 in .caml_start_program ()
#58223 0x000000001005a8b4 in caml_main (argv=0x3fffffffe8c0) at startup.c:197
#58224 0x00000000100022a4 in main (argc=<optimized out>, argv=<optimized out>)
Apparently, .camlLexer__handle_lexical_error_1023 triggers infinite recursion between .camlLexer__action_1065 and .camlLexer____ocaml_lex_action_rec_1066. Some disassembly from the relevant parts of the code:
0x0000000010015c5c <+2812>: ld r2,40(r1)
0x0000000010015c60 <+2816>: ld r11,176(r1)
0x0000000010015c64 <+2820>: mtlr r11
0x0000000010015c68 <+2824>: ld r1,0(r1)
0x0000000010015c6c <+2828>: blr
0x0000000010015c70 <+2832>: ld r7,144(r1)
0x0000000010015c74 <+2836>: addi r4,r7,-24
0x0000000010015c78 <+2840>: ld r3,128(r1)
0x0000000010015c7c <+2844>: ld r11,-26008(r2)
0x0000000010015c80 <+2848>: std r2,40(r1)
0x0000000010015c84 <+2852>: ld r2,8(r11)
0x0000000010015c88 <+2856>: ld r11,0(r11)
0x0000000010015c8c <+2860>: mtctr r11
0x0000000010015c90 <+2864>: bctrl
0x0000000010015c94 <+2868>: ld r2,40(r1)
0x0000000010015c98 <+2872>: ld r11,176(r1)
0x0000000010015c9c <+2876>: mtlr r11
0x0000000010015ca0 <+2880>: ld r1,0(r1)
0x0000000010015ca4 <+2884>: blr
0x0000000010015ca8 <+2888>: ld r12,-25888(r2)
0x0000000010015cac <+2892>: ld r12,0(r12)
0x0000000010015cb0 <+2896>: mtctr r12
0x0000000010015cb4 <+2900>: bctr
0x0000000010015cb8 <+2904>: mflr r0
0x0000000010015cbc <+2908>: std r0,16(r1)
0x0000000010015cc0 <+2912>: stdu r1,-128(r1)
0x0000000010015cc4 <+2916>: addi r5,r4,24
0x0000000010015cc8 <+2920>: li r4,143
0x0000000010015ccc <+2924>: ld r11,-26056(r2)
0x0000000010015cd0 <+2928>: std r2,40(r1)
0x0000000010015cd4 <+2932>: ld r2,8(r11)
0x0000000010015cd8 <+2936>: ld r11,0(r11)
0x0000000010015cdc <+2940>: mtctr r11
0x0000000010015ce0 <+2944>: bctrl
0x0000000010015ce4 <+2948>: ld r2,40(r1)
0x0000000010015ce8 <+2952>: ld r11,144(r1)
0x0000000010015cec <+2956>: mtlr r11
0x0000000010015cf0 <+2960>: ld r1,0(r1)
0x0000000010015cf4 <+2964>: blr
Adding the ocaml maintainer to the bug, since this looks like a bug in the ocaml compiler for ppc64.
Does increasing the size of the stack help at all?
There are various known cases in the compiler (eg.
http://caml.inria.fr/mantis/view.php?id=5626) where it's
highly recursive, and works on x86-64 but fails on ppc64
where IIRC the default stack size is much smaller or the
default frame size is much bigger.
If it is a case like this then I'm afraid upstream
won't fix it. See that bug report. However you can
easily work around it with ulimit.
Well, look at that. You're right; adding "ulimit -s unlimited" to %build does the trick. Thanks, Richard!
hevea-2.12-2.fc20 has been submitted as an update for Fedora 20.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing hevea-2.12-2.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
hevea-2.12-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.