magic-trace trace decoding fails on OCaml programs compiled on my system

[gasche]

$ cat test.ml
let () = print_endline "Hello World"

$ ~/.opam/4.13.1/bin/ocamlopt -o test ./test.ml

$ magic-trace trace -o test.trace ./test
[Couldn't find symbol. Will still snapshot on end]
Hello World
[ perf record: Woken up 1 times to write data ]
[Finished recording!]
[Snapshot taken!]
[ perf record: Captured and wrote 0.002 MB /tmp/magic_trace.tmp.e5ca22/perf.data ]
[Decoding, this may take 30s or so...]
(monitor.ml.Error
 ("Owee_buf.Invalid_format(\"unknown .debug_line version\")")
 ("Raised at Owee_buf.invalid_format in file \"src/owee_buf.ml\", line 22, characters 25-51"
  "Called from Owee_buf.assert_format in file \"src/owee_buf.ml\" (inlined), line 26, characters 4-22"
  "Called from Owee_debug_line.read_header in file \"src/owee_debug_line.ml\", line 54, characters 2-80"
  "Called from Owee_debug_line.read_chunk in file \"src/owee_debug_line.ml\", line 82, characters 12-27"
  "Called from Magic_trace_core__Elf.addr_table.(fun).load_table_next in file \"core/elf.ml\", line 103, characters 12-45"
  "Called from Base__Option.iter in file \"src/option.ml\" (inlined), line 68, characters 14-17"
  "Called from Magic_trace_core__Elf.addr_table in file \"core/elf.ml\", line 90, characters 2-1023"
  "Called from Magic_trace_lib__Trace.Make_commands.decode_to_trace.(fun) in file \"src/trace.ml\", line 70, characters 25-43"
  "Called from Tracing__Tool_output.write_and_view in file \"src/tool_output.ml\", line 32, characters 16-19"
  "Called from Async_kernel__Deferred0.bind.(fun) in file \"src/deferred0.ml\", line 54, characters 64-69"
  "Called from Async_kernel__Job_queue.run_jobs in file \"src/job_queue.ml\", line 167, characters 6-47"
  "Caught by monitor Monitor.protect"))

this is magic-trace v0.15.0 as packaged on opam
System: Fedora 34
owee is version 0.4 (I don't know if 0.5 would fix it, but the magic-trace package on opam requires owee 0.4)

[Xyene]

Thanks for the report. I believe this is #2, which was fixed in let-def/owee#18 (i.e. owee 0.5). The opam magic-trace release is currently out of date, you'll get more mileage either building from source or grabbing the static binary from the release page.

[gasche]

Thanks for the clarification. Do you have any plans to make a new release?

[Xyene]

Yes, likely in a small number of weeks. We've been iterating quickly towards a 1.0 release (https://github.com/janestreet/magic-trace/milestone/1) and are getting close, at which point we'll push out a new version on opam.

[gasche]

Thanks! I guess this can be closed, then. I'll wait for the new release for further experiments.

[cgaebel]

@gasche magic-trace 1.0 has been released to opam: ocaml/opam-repository#21227. Would you mind taking a look and seeing if it fixed your problem?

[gasche]

Thanks for the ping! When I received it, the cached opam-repository had not been updated yet, but it has now, and I can confirm that the testcase I posted above now works correctly.

(I had to use magic-trace run ... instead of magic-trace trace ..., and a message encourages me to use an online website and upload my trace there, when I guess some people might prefer to learn about local-option first, but those are all small details and I have much still to learn about the tool.)

Thanks for the new release!

[cgaebel]

@gasche You really do need to use that website to visualize your trace. The trace is not uploaded anywhere, it's processed locally in your browser. You can either take my word for it, confirm it in your browser's developer tools, go read the source code at https://github.com/janestreet/perfetto, or disconnect your internet after loading the page but before opening your trace.

[gasche]

The fact that magic-trace depends on cohttp gave me the impression that maybe it would embed a local way to run the viewer (which is not, in itself, a guarantee that the data stays local, as a local script will also query remote servers). In any case I'm only thinking of using the tool on open source projects, so I don't worry about it myself, but I've heard it leveled as a criticism of other tools in the past -- maybe not a dealbraker, but it can make people slightly uncomfortable.

While I'm taking your time on a not-relevant-anymore issue, I can mention another quick feedback point on the trace viewer: I clicked an element of the tree, and I expected to find a way to "zoom" on this element automatically (have the elements fill the full horizontal space, so that I see only it and its children), but I didn't find it (I tried double-clicking at first, then I read the "keyboard shortcut" documentation one can get with ?, I wasn't sure what some of the actions meant but I tried everything I believe, and I didn't find anything that would do what I expected). I can zoom manually with w/a/s/d but it's not easy to focus on a single element and its children. From the description I thought f would do this, but it seems to do something different (for most items I can click it does nothing, and sometimes it puts the selected item in the middle of the window but I'm not sure how it selects what interval to show).

[cgaebel]

Don't worry about my time. I'm happy to walk you through any sticking point. As one of our first external users, I learn as much from you as you do from me.

The cohttp dependency is so that people can run their own local trace viewer, with some effort. We intend for people to set this up if they want to unlock the -serve command, which lets you immediately serve up a trace locally after it's captured. You can find more information about how to do that here. It's not a privacy feature (it behaves the same as the magic-trace.org website), it's for convenience.

r.e. zooming effectively on a particular subset of the trace: Zooming in happens around the region that your mouse is hovering over. Hover your mouse cursor over the interesting part of your trace, and you'll zoom into that.

You've probably already seen it, but we've also heavily revised the project's README since you originally filed this issue. Do check it out if you haven't already.