Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005925OCamlOCaml generalpublic2013-02-18 10:082013-04-17 11:12
Reportersmimram 
Assigned Togasche 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionsuspended 
Platformamd64OSLinuxOS Version3.2.0
Product Version4.00.1 
Target VersionFixed in Version 
Summary0005925: Stack overflow in compiler
DescriptionCompiling the attached file with ocamlopt or ocamlopt.opt results in

Fatal error: exception Stack_overflow

Obviously this code was generated... It is not incredibly long (less than 4000 lines), but contains quite large expressions. Excepting by removing a few random lines, all my attempts to get a significantly simpler example have failed, sorry.
TagsNo tags attached.
Attached Files? file icon br.ml [^] (447,547 bytes) 2013-02-18 10:08
diff file icon long-bytecode.diff [^] (8,692 bytes) 2013-02-22 18:51 [Show Content]
diff file icon tailrec-asmcomp.diff [^] (45,817 bytes) 2013-02-22 18:51 [Show Content]

- Relationships
related to 0005626resolved Stack overflow in ocamlopt.opt: Comballoc.combine 
related to 0004405closed ocamlopt, ocaml, ocamlc, Stack Overflow on large hardcoded arrays. 
related to 0005844resolvedgasche stack overflow compiling medium size list constants 
related to 0005920closed ocamlc linking failed due to Invalid_argument of String.create when with -g 

-  Notes
(0008857)
gasche (developer)
2013-02-18 11:31

This is an instance of the well-known issue of "compiler code not being tail-recursive". Marking "resolved > suspended" as this is extremely low-priority. The advice for now is to fix code generators to avoid too deep nestings, or contribute patches that solve the issue without degrading code readability (not necessarily easy).
(0008890)
bvaugon (reporter)
2013-02-22 18:51

To solve your compilation problems, I wrote two patches on OCaml 4.00.1 distribution:
 * long-bytecode.diff: it makes possible to compile programs like yours in bytecode on 32 bits architectures (without Invalid_argument("String.create")). It uses string arrays instead of strings to store bytecode at compile time and link time.
 * tailrec-asmcomp.diff: it makes possible to compile programs like yours in native code (without StackOverflow). It is just a tail recursive version of the ocamlopt assembler generator using continuation passing style. The source code size and readability are not very degradated, and compilation performances seems to be similar.
(0008934)
smimram (reporter)
2013-02-28 11:11

Hi,

Would it be possible to reopen this bug so that Benoit's patches are reviewed (and hopefully integrated)? It is quite important, when developping a library, to know that OCaml can reliably used as a target language and that the work won't have to be done again in C (or some other language whose compiler does not have stack overflows)...

Thanks!
(0008936)
gasche (developer)
2013-02-28 13:57
edited on: 2013-02-28 13:58

I had a look at Benoît's patches, but thanks for the ping, I had forgotten to add some feedback here.

The long-bytecode patch is short and self-contained. I'm wondering what the performance implications of such a change are (my first reaction was: if it's so simple, why don't we define strings in this way in the standard library?). Besides this unknown (Benoît, if you have data on this, do not hesitate to share), it suffers from the problem of only making sense on 32 bits architecture, which makes it quite hard to convince maintainers that it's worth the (even small) increase in code size.

The other patch is a typical example of the easy and boring transformation that *does* hurt readability, and is also relatively invasive. My strictly personal dream is that, someday, we have a reliable monadic notation for OCaml (or a syntax extension mechanism for that that I could use on the compiler itself without getting killed), and *that* would make the CPS version readable and reasonable to use. It's not the case for now.

I'm keeping the bug "resolved > suspended" (means: meh, we probably won't do anything) for now. It's good that the patches are here so that users that really need them can consider using them, but I would still advise you to fix the code generator for now. Sorry.

(0008939)
smimram (reporter)
2013-03-01 09:14

Thanks for your answer! I personally find the CPS quite readable, but I guess there is very little I can argue about style...
(0009155)
gasche (developer)
2013-04-17 11:12

Small update: with help/review from chetsky in PR#5957, I commited the long-bytecode patch. This unfortunately will not alone resolve the issue at hand, but may help with similar code-generation settings -- and affected human users as well.

Thanks, Benoît, for your patch!

- Issue History
Date Modified Username Field Change
2013-02-18 10:08 smimram New Issue
2013-02-18 10:08 smimram File Added: br.ml
2013-02-18 11:27 gasche Relationship added related to 0005626
2013-02-18 11:27 gasche Relationship added related to 0004405
2013-02-18 11:28 gasche Relationship added parent of 0005844
2013-02-18 11:28 gasche Relationship deleted parent of 0005844
2013-02-18 11:28 gasche Relationship added related to 0005844
2013-02-18 11:31 gasche Note Added: 0008857
2013-02-18 11:31 gasche Status new => resolved
2013-02-18 11:31 gasche Resolution open => suspended
2013-02-18 11:31 gasche Assigned To => gasche
2013-02-22 18:51 bvaugon Note Added: 0008890
2013-02-22 18:51 bvaugon File Added: long-bytecode.diff
2013-02-22 18:51 bvaugon File Added: tailrec-asmcomp.diff
2013-02-28 11:11 smimram Note Added: 0008934
2013-02-28 13:57 gasche Note Added: 0008936
2013-02-28 13:58 gasche Note Edited: 0008936 View Revisions
2013-03-01 09:14 smimram Note Added: 0008939
2013-03-17 17:26 gasche Relationship added related to 0005920
2013-03-21 22:04 gasche Relationship added has duplicate 0005957
2013-03-21 22:04 gasche Relationship deleted has duplicate 0005957
2013-04-17 11:12 gasche Note Added: 0009155


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker