Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005941OCamlOCaml runtime systempublic2013-03-11 21:232014-04-18 17:38
Reporterdim 
Assigned Todim 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version4.01.0+dev 
Target VersionFixed in Version4.02.0+dev 
Summary0005941: OCaml handler for uncaught exception
DescriptionThe attached patch allows the user to register an OCaml function to handle uncaught exceptions. The default handler does the same as the C function except that it calls [Printexc.to_string], which uses user-defined exception printers.

The new function is:

Printexc.set_uncaught_exception_handler: (exn -> raw_backtrace option -> unit) -> unit

The backtrace is [None] when the debugger is active.
Tagspatch
Attached Filespatch file icon uncaught-exception-handler.patch [^] (3,515 bytes) 2013-03-11 21:23 [Show Content]
patch file icon uncaught-exception-handler-v2.patch [^] (4,502 bytes) 2013-03-14 11:22 [Show Content]

- Relationships
related to 0005040resolveddim The default exception handler doesn't use functions registered with Printexc.register_printer 

-  Notes
(0008958)
gasche (developer)
2013-03-11 23:49

I'm a bit confused by your caml_callback2 invokation: the second parameter is Val_bool(DEBUGGER_IN_USE), while the OCaml type expects an argument of type (raw_backtrace option).

Otherwise I'm impressed by the speed at which you made use of the new raw_backtrace type :-)

Could you explain what the debugger test is there for? I am not familiar with its interaction with the backtrace code.

When developing the raw_backtrace interface, Jacques-Henri Jourdan and I wondered if we should expose whether the backtrace was correctly recorded or not directly in Printexc.get_raw_backtrace, by having it return a `raw_backtrace option` to indicate validity (instead of embedding failure in the type by just returning empty allocated space). We eventually decided to follow what had been done for the rest of the interface, that has explicit no representation of failure to collect traces (we weren't sure we could make sure that the backtrace is valid in all cases), but if you have a different opinion I'd like to know: it's still possible to change the interface in trunk.
(0008960)
dim (developer)
2013-03-12 12:15

> I'm a bit confused by your caml_callback2 invokation: the second parameter is Val_bool(DEBUGGER_IN_USE), while the OCaml type expects an argument of type (raw_backtrace option).

caml_callback2 is applied on Printexc.handle_uncaught_exception, which is a wrapper around the user provided function.

> Otherwise I'm impressed by the speed at which you made use of the new raw_backtrace type :-)

;-)

> Could you explain what the debugger test is there for? I am not familiar with its interaction with the backtrace code.

I'm not 100% sure, but looking at startup.c the debugger interactive loop is called before caml_fatal_uncaught_exception, so that maybe related (the test was already there). Actually I don't think the latter will ever be called when using ocamldebug.

> When developing the raw_backtrace interface, Jacques-Henri Jourdan and I wondered if we should expose whether the backtrace was correctly recorded or not directly in Printexc.get_raw_backtrace, by having it return a `raw_backtrace option` to indicate validity (instead of embedding failure in the type by just returning empty allocated space). We eventually decided to follow what had been done for the rest of the interface, that has explicit no representation of failure to collect traces (we weren't sure we could make sure that the backtrace is valid in all cases), but if you have a different opinion I'd like to know: it's still possible to change the interface in trunk.

I used an option because of this debugger test, but I should probably follow the same convention as for get_raw_backtrace. I have no strong opinion about whether it should be an option or not, but if get_raw_backtrace cannot be made to return None exactly when the backtrace is invalid I think it is better to just return an empty one.
(0011291)
dim (developer)
2014-04-16 11:49

I worked a bit more on the patch and posted the final version on github for more review. If there is no objection I'll commit it.
(0011305)
dim (developer)
2014-04-18 17:37

Committed, revision 14643.

- Issue History
Date Modified Username Field Change
2013-03-11 21:23 dim New Issue
2013-03-11 21:23 dim Status new => assigned
2013-03-11 21:23 dim Assigned To => dim
2013-03-11 21:23 dim File Added: uncaught-exception-handler.patch
2013-03-11 21:24 dim Relationship added related to 0005040
2013-03-11 23:49 gasche Note Added: 0008958
2013-03-12 12:15 dim Note Added: 0008960
2013-03-14 11:22 dim File Added: uncaught-exception-handler-v2.patch
2013-12-16 14:28 doligez Tag Attached: patch
2014-04-16 11:49 dim Note Added: 0011291
2014-04-18 17:37 dim Note Added: 0011305
2014-04-18 17:38 dim Status assigned => resolved
2014-04-18 17:38 dim Fixed in Version => 4.02.0+dev
2014-04-18 17:38 dim Resolution open => fixed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker