[Caml-list] Core breaks backtraces

[Caml-list] Core breaks backtraces

[Ivan Gotovchits]

Hi,

I've tried a fabulous core library and it broke my exceptions :) 
All backtraces are now look like this

  backtrace:
  Raised at file "map.ml", line 117, characters 16-25
  Called from file "lib/conv.ml", line 256, characters 19-50

Next, if I enable backtrace recording with OCAMLRUNPARAM environment
variable and compile a .d.byte version of my application than on an
exception occurrence core eats all my memory thus killing my machine.

Any clues, what happens?

P.S. removing Core.Std from project fixes all issues.
P.P.S. My application is rather large and uses lots of processes and
lwt, moreover it enables lwt backtracing via ocamlbuild plugin.

P.P.P.S . By using core I mean just opening Core.Std in a an empty
module, this is enough to broke my system.

Re: [Caml-list] Core breaks backtraces

[Mark Shinwell]

On 18 December 2013 06:17, Ivan Gotovchits <ivg@ieee.org> wrote:
> I've tried a fabulous core library and it broke my exceptions :)
> All backtraces are now look like this
>
>   backtrace:
>   Raised at file "map.ml", line 117, characters 16-25
>   Called from file "lib/conv.ml", line 256, characters 19-50
>
> Next, if I enable backtrace recording with OCAMLRUNPARAM environment
> variable and compile a .d.byte version of my application than on an
> exception occurrence core eats all my memory thus killing my machine.
>
> Any clues, what happens?
>
> P.S. removing Core.Std from project fixes all issues.
> P.P.S. My application is rather large and uses lots of processes and
> lwt, moreover it enables lwt backtracing via ocamlbuild plugin.
>
> P.P.P.S . By using core I mean just opening Core.Std in a an empty
> module, this is enough to broke my system.

Are you always building bytecode?  Which version of the
compiler, which operating system, and on which hardware
platform?  Does this happen when you compile for native code?

I suggest you also try copying the contents of core/lib/std.ml
into your empty module and bisecting to determine which
of the Core modules causes the failure.

Mark

Re: [Caml-list] Core breaks backtraces

[Yaron Minsky]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

Do you need to set OCAMLRUNPARAM to trigger the problem?  I'm curious
because Core enables backspaces by default.

It would be great if you can post precise steps for reproducing this, along
with the platform details, on the bug tracker:

https://github.com/janestreet/core_kernel/issues

To say the obvious, I use core both on Linux and the Mac and have never
seen this, so I suspect something about your setup is tickling this issue.
On Dec 18, 2013 6:45 AM, "Mark Shinwell" <mshinwell@janestreet.com> wrote:

> On 18 December 2013 06:17, Ivan Gotovchits <ivg@ieee.org> wrote:
> > I've tried a fabulous core library and it broke my exceptions :)
> > All backtraces are now look like this
> >
> >   backtrace:
> >   Raised at file "map.ml", line 117, characters 16-25
> >   Called from file "lib/conv.ml", line 256, characters 19-50
> >
> > Next, if I enable backtrace recording with OCAMLRUNPARAM environment
> > variable and compile a .d.byte version of my application than on an
> > exception occurrence core eats all my memory thus killing my machine.
> >
> > Any clues, what happens?
> >
> > P.S. removing Core.Std from project fixes all issues.
> > P.P.S. My application is rather large and uses lots of processes and
> > lwt, moreover it enables lwt backtracing via ocamlbuild plugin.
> >
> > P.P.P.S . By using core I mean just opening Core.Std in a an empty
> > module, this is enough to broke my system.
>
> Are you always building bytecode?  Which version of the
> compiler, which operating system, and on which hardware
> platform?  Does this happen when you compile for native code?
>
> I suggest you also try copying the contents of core/lib/std.ml
> into your empty module and bisecting to determine which
> of the Core modules causes the failure.
>
> Mark
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2960 bytes --]

Re: [Caml-list] Core breaks backtraces

[Ivan Gotovchits]

[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]



> On 18 дек. 2013 г., at 16:01, Yaron Minsky <yminsky@janestreet.com> wrote:
> 
> Do you need to set OCAMLRUNPARAM to trigger the problem?  I'm curious because Core enables backspaces by default. 
> 
No, I didn't. 
> It would be great if you can post precise steps for reproducing this, along with the platform details, on the bug tracker:
> 
> https://github.com/janestreet/core_kernel/issues
> 
> To say the obvious, I use core both on Linux and the Mac and have never seen this, so I suspect something about your setup is tickling this issue.
> 
I'll do my best, but it is only observable with my program. I cannot reproduce it, using simple steps. 

It'll be helpful if you provide some clues on where to dig in core. I'm new to core and it is overwhelmingly large. It will be easier for me to trace the problem, if I  understand what core do with the backtraces.

>> On Dec 18, 2013 6:45 AM, "Mark Shinwell" <mshinwell@janestreet.com> wrote:
>> On 18 December 2013 06:17, Ivan Gotovchits <ivg@ieee.org> wrote:
>> > I've tried a fabulous core library and it broke my exceptions :)
>> > All backtraces are now look like this
>> >
>> >   backtrace:
>> >   Raised at file "map.ml", line 117, characters 16-25
>> >   Called from file "lib/conv.ml", line 256, characters 19-50
>> >
>> > Next, if I enable backtrace recording with OCAMLRUNPARAM environment
>> > variable and compile a .d.byte version of my application than on an
>> > exception occurrence core eats all my memory thus killing my machine.
>> >
>> > Any clues, what happens?
>> >
>> > P.S. removing Core.Std from project fixes all issues.
>> > P.P.S. My application is rather large and uses lots of processes and
>> > lwt, moreover it enables lwt backtracing via ocamlbuild plugin.
>> >
>> > P.P.P.S . By using core I mean just opening Core.Std in a an empty
>> > module, this is enough to broke my system.
>> 
>> Are you always building bytecode?  Which version of the
>> compiler, which operating system, and on which hardware
>> platform?  Does this happen when you compile for native code?
>> 
>> I suggest you also try copying the contents of core/lib/std.ml
>> into your empty module and bisecting to determine which
>> of the Core modules causes the failure.
>> 
>> Mark
>> 
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs

[-- Attachment #2: Type: text/html, Size: 3775 bytes --]

Re: [Caml-list] Core breaks backtraces

[Jeremie Dimino]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

On Wed, Dec 18, 2013 at 6:17 AM, Ivan Gotovchits <ivg@ieee.org> wrote:

>
> Hi,
>
> I've tried a fabulous core library and it broke my exceptions :)
> All backtraces are now look like this
>
>   backtrace:
>   Raised at file "map.ml", line 117, characters 16-25
>   Called from file "lib/conv.ml", line 256, characters 19-50
>

This is from sexplib. The Exn module in Core_kernel registers an exception
printer which looks like this:

  let () =
    Printexc.register_printer (fun exc ->
      match sexp_of_exn_opt exc with
      | None -> None
      | Some sexp ->
        Some (Sexp.to_string_hum ~indent:2 sexp))

Now, if we look at what sexp_of_exn_opt is doing, in sexplib/lib/conv.ml,
line 256:

  match try Some (Addrs.find addr !exn_addr_map) with Not_found -> None with

Where Addrs is a Map.Make(_).

So for any exception that is not registered with sexplib, Addrs.find will
raise Not_found. And since there is one global backtrace buffer, the
backtrace gets replaced by this one. I guess we never had this problem
because we don't use exception much and the few we have are defined "with
sexp". We will work on a fix.

I don't have a precise idea for the second part of the problem (core eating
all memory).

[-- Attachment #2: Type: text/html, Size: 2134 bytes --]