Bug 879050 - FTBFS: + /usr/bin/ocamllex.opt -q latexscan.mll Command got signal -10
Summary: FTBFS: + /usr/bin/ocamllex.opt -q latexscan.mll Command got signal -10
Alias: None
Product: Fedora
Classification: Fedora
Component: hevea
Version: rawhide
Hardware: ppc64
OS: Linux
Target Milestone: ---
Assignee: Gabriel Kerneis
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-11-21 22:55 UTC by Karsten Hopp
Modified: 2014-01-26 11:55 UTC (History)
5 users (show)

Fixed In Version: hevea-2.12-2.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-01-26 11:55:02 UTC
Type: Bug

Attachments (Terms of Use)

Description Karsten Hopp 2012-11-21 22:55:52 UTC
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):

How reproducible:

Steps to Reproduce:
1. ppc-koji build --scratch f18 hevea-1.10-8.fc18.src.rpm
Actual results:

Expected results:

Additional info:

Comment 1 Gabriel Kerneis 2013-09-04 06:57:28 UTC
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.

Comment 2 Fedora End Of Life 2013-12-21 15:12:15 UTC
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.

Comment 3 Jerry James 2014-01-16 20:11:16 UTC
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)
    at memory.c:530
#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>)
    at main.c:54

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.

Comment 4 Richard W.M. Jones 2014-01-16 21:43:52 UTC
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.

Comment 5 Jerry James 2014-01-16 22:13:06 UTC
Well, look at that.  You're right; adding "ulimit -s unlimited" to %build does the trick.  Thanks, Richard!

Comment 6 Fedora Update System 2014-01-16 23:16:13 UTC
hevea-2.12-2.fc20 has been submitted as an update for Fedora 20.

Comment 7 Fedora Update System 2014-01-18 04:29:33 UTC
Package hevea-2.12-2.fc20:
* 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).

Comment 8 Fedora Update System 2014-01-26 11:55:02 UTC
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.

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