So... this is getting complicated. I'm starting to think this is actually on OCaml and isn't worth investigating further.

ocamldebug just jumps straight into the segfault without catching it

Right, because it's crashing before it's finished loading the executable, on a major collection while initialising the bytecode runtime's caml_global_data table. OCaml debugging hasn't even started at this point. I consistently get this backtrace from ocamlrun utop 2.10 on OCaml 4.14.0 with nnp:

(gdb) backtrace
#0  caml_darken (v=0, p=0x5555555a7240 <caml_global_data>) at major_gc.c:285
#1  0x0000555555592288 in caml_do_roots (f=0x555555590000 <caml_darken>, do_globals=<optimized out>) at roots_byt.c:91
#2  0x0000555555592305 in caml_darken_all_roots_start () at roots_byt.c:75
#3  0x0000555555590920 in start_cycle () at major_gc.c:407
#4  caml_major_collection_slice (howmuch=howmuch@entry=-1) at major_gc.c:1089
#5  0x0000555555591e01 in caml_gc_dispatch () at minor_gc.c:500
#6  0x0000555555591f11 in caml_check_urgent_gc (extra_root=<optimized out>, extra_root@entry=1) at minor_gc.c:575
#7  0x000055555556c96c in caml_do_pending_actions_exn () at signals.c:267
#8  0x000055555556cd00 in process_pending_actions_with_root_exn (extra_root=<optimized out>) at signals.c:299
#9  caml_process_pending_actions () at signals.c:331
#10 0x0000555555577ce2 in intern_end (res=<optimized out>, whsize=<optimized out>) at intern.c:709
#11 0x0000555555578a63 in caml_input_val (chan=chan@entry=0x5555555de740) at intern.c:808
#12 0x000055555558cb4f in caml_main (argv=0x7fffffffde48) at startup_byt.c:570
#13 0x0000555555569f12 in main (argc=<optimized out>, argv=<optimized out>) at main.c:37

caml_darken v=0 thus implies a naked null pointer has sneaked into the global data. So I tried to dump caml_global_data with the inspect library within utop, expecting it to crash only on 2.10, and discovered that it triggers SIGSEGV on utop 2.10, 2.9.2 and even on raw ocaml!

#use "topfind";;
#require "inspect";;
external get_global_data : unit -> Obj.t = "caml_get_global_data";;
get_global_data () |> Inspect.Sexpr.dump;; (* SIGSEGV *)

Those libraries barely have dependencies, so now I think the naked null pointer is already there from the start, but it doesn't cause issues on nnp until the global data grows large enough that it triggers a major collection before completing initialisation of the bytecode runtime; lambda-term may just contribute a lot to it. Any non-determinism during initialisation could explain @nilsbecker's report as well, if they were running nnp too.

Since OCaml itself is being largely reworked for 5.x, I think we should just close this issue, assume that 4.14.0's bytecode runtime is unsafe to run with nnp and watch out for future issues in the 5.x runtime. Sorry for the headache!

FYI as a tip, you can get English error messages by setting LC_ALL=C

True, so much software ignores C locales nowadays (for good reasons) that I forget about it! J'ai aussi oublié le français.

Segment violation since 2.10.0 #405

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions