Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005074OCamlOCaml generalpublic2010-06-15 14:272015-11-28 12:14
Reporterygrek 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionsuspended 
PlatformOSOS Version
Product Version3.11.2 
Target VersionFixed in Version 
Summary0005074: wrong backtrace printed when mixing modules with and without debug info
Description$ cat a.ml
exception Error
let fail () = raise Error

$ cat b.ml
let f () =
  ignore (A.fail ())

let () =
  (try failwith "oops" with _ -> ());
  f ()

$ cat run
ocamlc -c a.ml -o a.cmo
ocamlc -c -g b.ml -o b.cmo
ocamlc -g a.cmo b.cmo -o b.byte
ocamlopt -c a.ml -o a.cmx
ocamlopt -c -g b.ml -o b.cmx
ocamlopt -g a.cmx b.cmx -o b.native
OCAMLRUNPARAM=b ./b.byte
OCAMLRUNPARAM=b ./b.native

$ ./run
Fatal error: exception A.Error
Called from file "b.ml", line 2, characters 9-20
Called from file "b.ml", line 6, characters 2-6
Fatal error: exception A.Error
Raised at file "pervasives.ml", line 22, characters 22-33
Called from file "b.ml", line 5, characters 7-22

The backtrace for b.native is absolutely wrong.
Note that a.ml is compiled without -g option.
Additional InformationFunny thing - if module A raises predefined exception instead of newly defined Error - everything is ok.
Minor note - no "Raised at" printed for b.byte
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0011953)
doligez (administrator)
2014-07-31 15:30

Some progress has been made on this issue: now the native code says
  Fatal error: exception A.Error
  Raised by primitive operation at file "b.ml", line 2, characters 9-20
which is basically correct, considering that the "fail" function is probably inlined.

On the other hand, the bytecode result hasn't changed, it's still missing the "Raised by" line.
(0014883)
xleroy (administrator)
2015-11-28 12:13

Yes, the inlining of A.fail produces a decent backtrace. The original problem is still there if a.ml is compiled with ocamlopt -inline 0, though.

I don't see any reasonable fix here. If one compiles with ocamlopt and without -g, it's to get the absolutely fastest implementation of exception raising, which doesn't reset the "last exception raised" global variable. Resetting that variable would defeat the purpose of getting the absolutely fastest implementation of exception raising.

More generally, mixing object files compiled with -g and without -g is not a scenario that I want us to spend implementation efforts on. Suspending this PR.

- Issue History
Date Modified Username Field Change
2010-06-15 14:27 ygrek New Issue
2011-06-01 23:14 doligez Status new => acknowledged
2012-07-10 20:17 doligez Target Version => 4.01.0+dev
2012-07-31 13:36 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-18 13:38 doligez Priority normal => high
2012-09-18 13:38 doligez Target Version 4.00.1+dev => 4.00.2+dev
2013-07-11 12:56 doligez Target Version 4.00.2+dev => 4.01.0+dev
2013-08-12 16:31 doligez Target Version 4.01.0+dev => 4.01.1+dev
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-07-31 15:30 doligez Note Added: 0011953
2014-07-31 15:39 doligez Target Version 4.02.0+dev => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-26 19:34 doligez Target Version undecided => 4.02.2+dev / +rc1
2015-01-16 20:02 doligez Target Version 4.02.2+dev / +rc1 => 4.02.3+dev
2015-07-15 15:33 doligez Target Version 4.02.3+dev => 4.03.0+dev
2015-11-28 12:13 xleroy Note Added: 0014883
2015-11-28 12:13 xleroy Priority high => normal
2015-11-28 12:13 xleroy Status acknowledged => resolved
2015-11-28 12:13 xleroy Resolution open => suspended
2015-11-28 12:14 xleroy Target Version 4.03.0+dev =>


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker