|Anonymous | Login | Signup for a new account||2019-02-24 05:43 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007165||OCaml||~DO NOT USE (was: OCaml general)||public||2016-03-05 02:45||2017-09-24 17:33|
|Target Version||4.03.1+dev||Fixed in Version||4.04.0 +dev / +beta1 / +beta2|
|Summary||0007165: Lexer raises `Fatal Error` on parsing `#9342101923012312312`|
|Description||ocamlc and ocamlopt crash with `Fatal error: exception Failure("int_of_string")` if the input file just contains `#9342101923012312312`. The `int_of_string` call at  fails due to overflow. |
The failing test case was generated with afl instrumented OCaml .
 https://github.com/ocaml/ocaml/blob/5401ce8473062b19dd3553d022593cc5d91ccbff/lex/lexer.mll#L130 [^]
 https://github.com/ocamllabs/opam-repo-dev/pull/23 [^]
|Steps To Reproduce||$ cat crash.ml |
$ ocamlc crash.ml
Fatal error: exception Failure("int_of_string")
|Attached Files||crash.ml [^] (21 bytes) 2016-03-05 02:45 [Show Content]|
edited on: 2016-03-05 15:21
I proposed a fix for this issue in
I have done some afl-fuzzing with OCaml myself, but I did not take the long and brave route of instrumenting the compiler output. I just compiled the C runtime with instrumentation, and tried to fuzz "input_value". I found plenty of crashes (something like 65 distinct path), but then found out that I completely lack the expertise to analyse them and say whether any of them should be fixed. (I think everyone agree that running input_value on untrusted input is bad form, but there are a range of possible bad behaviors that a buggy C runtime could allow that we may want to prevent nonetheless). Would there be a volunteer to look at those crash reports?
Also, why is the afl-instrumented ocamlopt variant not (yet) submitted as a pull request upstream? I would love to have an -afl-instrument flag in ocamlopt.
Thanks for the fix. I'll prod stedolan to submit a PR upstream.
At the moment, most bugs found are in the lexer since fuzzing tends to explore in a breadth-first fashion. I would like to selectively compile different phases of the compiler with instrumentation to perform better testing.
edited on: 2016-03-05 17:07
I'm a bit skeptical about using afl-fuzz to test the compiler itself in general -- because it finds crashes, which are not the kind of defects I would be primarily concerned about. I suspect you may get more mileage out of a Csmith-style tool generating simple valid OCaml programs, and (for example) checking that the bytecode and native behavior coincide -- especially with flambda, that could be juicy. afl-fuzzing the runtime could be interesting, but I'm not sure how to do it -- we would need a tool reading input files that describe well-defined sequences of runtime calls.
(The afl-instrumentation of the compiler is of course very interesting, as it would allow to easily fuzz *any* OCaml programs, in particular those where finding crashes is important and interesting.)
I definitely want the afl instrumentation widely available, but I'm not sure that upstreaming into the main OCaml distribution is the right choice (although I'm more than happy to do that if it's desired).
The issue is that you generally want to compile a large piece of software and its dependencies with instrumentation turned on. Telling all of the various OCaml build systems that they should pass a new `-afl-instrument` flag to ocamlopt is a bit painful. It seems easier to provide a compiler that can be installed with `opam switch`, which then builds everything with instrumentation turned on without having to muck around with build flags.
So, I'm not sure how best to make this available - possibly a switch in the main opam repo might be better than a flag in the stock compiler.
There are two orthogonal issues at play here: whether the instrumentation logic is included upstream or only in a fork, and the best trick to enable it globally.
If you can propose a clean pull request (I trust you can), it is useful/interesting to other people (count me in), and you can convince the maintainers to have it (I don't know about that part), it should definitely be submitted upstream. The best way to use it might still be to deploy a separate switch, but that switch would just toggle an upstream option by default.
Re. global deployment: I remember that Pierre Chambart and Mark Shinwell proposed, as part of the flambda work, a way to enable compiler options globally in a switch by setting a file somewhere (in `ocamlc -where` iirc.). I don't know what the status of this feature is. You should ask Mark if you have the opportunity to.
You should ask Pierre about the global config file. :)
I believe that code has been included in the 4.03 branch already.
|There is now a pull request for afl instrumentation at https://github.com/ocaml/ocaml/pull/504 [^]|
|2016-03-05 02:45||kayceesrk||New Issue|
|2016-03-05 02:45||kayceesrk||File Added: crash.ml|
|2016-03-05 15:21||gasche||Note Added: 0015436|
|2016-03-05 15:21||gasche||Assigned To||=> gasche|
|2016-03-05 15:21||gasche||Status||new => assigned|
|2016-03-05 15:21||gasche||Note Edited: 0015436||View Revisions|
|2016-03-05 15:21||gasche||Note Edited: 0015436||View Revisions|
|2016-03-05 17:00||kayceesrk||Note Added: 0015437|
|2016-03-05 17:06||gasche||Note Added: 0015438|
|2016-03-05 17:07||gasche||Note Edited: 0015438||View Revisions|
|2016-03-06 00:04||stedolan||Note Added: 0015439|
|2016-03-07 00:08||gasche||Note Added: 0015443|
|2016-03-07 08:23||shinwell||Note Added: 0015444|
|2016-03-07 11:43||kayceesrk||Tag Attached: afl|
|2016-03-11 14:57||stedolan||Note Added: 0015464|
|2016-03-22 14:56||doligez||Severity||crash => minor|
|2016-03-22 14:56||doligez||Target Version||=> 4.03.0+dev / +beta1|
|2016-04-13 17:49||doligez||Target Version||4.03.0+dev / +beta1 => 4.03.1+dev|
|2016-07-11 14:20||frisch||Status||assigned => resolved|
|2016-07-11 14:20||frisch||Fixed in Version||=> 4.04.0 +dev / +beta1 / +beta2|
|2016-07-11 14:20||frisch||Resolution||open => fixed|
|2017-02-23 16:36||doligez||Category||OCaml general => -OCaml general|
|2017-03-03 17:55||doligez||Category||-OCaml general => -(deprecated) general|
|2017-03-03 18:01||doligez||Category||-(deprecated) general => ~deprecated (was: OCaml general)|
|2017-03-06 17:04||doligez||Category||~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)|
|2017-09-24 17:33||xleroy||Status||resolved => closed|
|Copyright © 2000 - 2011 MantisBT Group|