Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006468OCamlOCaml generalpublic2014-06-24 14:242014-12-20 13:06
Assigned Towhitequark 
PlatformOSOS Version
Product Version4.02.0+beta1 / +rc1 
Target VersionFixed in Version 
Summary0006468: Backtraces in toplevel
DescriptionI just realized there appears to be no way to get backtraces in toplevel. This makes it much less useful. I see there is a patch for 3.11; what's holding its integration? [^]
Attached Filespatch file icon backtrace.patch [^] (30,559 bytes) 2014-12-20 13:06 [Show Content]

- Relationships

-  Notes
whitequark (developer)
2014-12-20 13:03
edited on: 2014-12-20 13:07

Reminder sent to: gasche

@gasche, I've reworked the patch to apply on trunk.

$ ocaml
        OCaml version 4.03.0+dev5-2014-10-15

# let f () = raise Not_found;;
val f : unit -> 'a = <fun>
# let g () = f (); 1;;
val g : unit -> int = <fun>
# g ();;
Exception: Not_found.
Raised at file "//toplevel//", line 1, characters 17-26
Called from file "//toplevel//", line 1, characters 11-15

The patch is somewhat complex, so I will explain in detail how it works. Logically, it consists out of four parts:

  * First, the runtime representation of the debug information in backtrace.c is changed, so that new chunks of it, corresponding to newly loaded (and unloaded) code can be added and removed.
  * Second, the startup process is changed so that the debug information, if present in the executable, is loaded at startup and not lazily. This affects startup.c and io.c.
  * Third, the bytecode compiler and the toplevel are changed so as to generate and register the debug information for toplevel phrases. This affects bytecomp/, bytecomp/, toplevel/ and toplevel/ This also requires a bootstrap, as new primitives were added.
  * Fourth, the Dynlink module was extended to also register debug information. This affects otherlibs/dynlink/

The changes to the runtime representation of the debug information are as follows. In trunk, debug information is represented by an array of events, represented as C structures. In the original patch, it's a list of event lists, represented as OCaml structures. I implemented a middle ground between these approaches: there is a global linked list of all registered debug information, but every entry is a custom block containing a C structure. This allows to keep the fast backtrace extraction code that uses binary search intact.

The change to the startup process is necessary, as caml_stash_backtrace walks the stack by looking at every successive value and checking whether it points into a known range of bytecode. Thus, either the debug information could be loaded at startup, or the code would have to handle the "main" bytecode range specially. I think the former is cleaner.

The original patch also exported a variant of caml_input_val function that allows to allocate the space for the blocks from the old generation right away. I'm not sure why was this done--I don't see a reason for it--and the compiler can bootstrap itself just fine without it when built with -g (i.e. stressing the relevant code), so I assume it's not necessary.

The rest of the changes are straightforward.

- Issue History
Date Modified Username Field Change
2014-06-24 14:24 whitequark New Issue
2014-07-16 10:21 doligez Severity minor => feature
2014-07-16 10:21 doligez Status new => acknowledged
2014-07-16 10:21 doligez Tag Attached: patch
2014-12-20 12:35 whitequark Assigned To => whitequark
2014-12-20 12:35 whitequark Status acknowledged => assigned
2014-12-20 12:35 whitequark File Added: backtrace.patch
2014-12-20 13:03 whitequark Note Added: 0012897
2014-12-20 13:03 whitequark File Deleted: backtrace.patch
2014-12-20 13:04 whitequark File Added: backtrace.patch
2014-12-20 13:06 whitequark File Deleted: backtrace.patch
2014-12-20 13:06 whitequark File Added: backtrace.patch
2014-12-20 13:07 whitequark Note Edited: 0012897 View Revisions

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker