Skip to content

Test failure when glibc has frame pointers #12587

@jamesjer

Description

@jamesjer

I attempted a test build of OCaml 5.1.0 for the Fedora Linux distribution, but all of the frame-pointers tests failed. The first failure looks like this:

Running tests from 'tests/frame-pointers' ...
 ... testing 'c_call.ml' with 1 (frame_pointers) => passed
 ... testing 'c_call.ml' with 1.1 (native) sh: line 1: : command not found
=> failed (program output /builddir/build/BUILD/ocaml-5.1.0/testsuite/_ocamltest/tests/frame-pointers/c_call/ocamlopt.byte/c_call.opt.output differs from reference /builddir/build/BUILD/ocaml-5.1.0/testsuite/tests/frame-pointers/c_call.reference: 
)
> Specified modules: c_call.ml
> Source modules: c_call.ml
> Running test frame_pointers with 1 actions
> 
> Running action 1/1 (frame_pointers)
> Action 1/1 (frame_pointers) => passed (frame-pointers available)
> Running test native with 8 actions
> 
> Running action 1/8 (setup-ocamlopt.byte-build-env)
> Action 1/8 (setup-ocamlopt.byte-build-env) => passed
> 
> Running action 2/8 (ocamlopt.byte)
> Compiling program /builddir/build/BUILD/ocaml-5.1.0/testsuite/_ocamltest/tests/frame-pointers/c_call/ocamlopt.byte/c_call.opt from modules  fp_backtrace.c c_call_.c c_call.ml
> Commandline: /builddir/build/BUILD/ocaml-5.1.0/runtime/ocamlrun /builddir/build/BUILD/ocaml-5.1.0/ocamlopt -I /builddir/build/BUILD/ocaml-5.1.0/runtime -ccopt -I/builddir/build/BUILD/ocaml-5.1.0/runtime -nostdlib -I /builddir/build/BUILD/ocaml-5.1.0/stdlib -o /builddir/build/BUILD/ocaml-5.1.0/testsuite/_ocamltest/tests/frame-pointers/c_call/ocamlopt.byte/c_call.opt fp_backtrace.c c_call_.c c_call.ml
>   Redirecting stdout to /builddir/build/BUILD/ocaml-5.1.0/testsuite/_ocamltest/tests/frame-pointers/c_call/ocamlopt.byte/ocamlopt.byte.output 
>   Redirecting stderr to /builddir/build/BUILD/ocaml-5.1.0/testsuite/_ocamltest/tests/frame-pointers/c_call/ocamlopt.byte/ocamlopt.byte.output 
> Action 2/8 (ocamlopt.byte) => passed
> 
> Running action 3/8 (check-ocamlopt.byte-output)
> Comparing compiler output /builddir/build/BUILD/ocaml-5.1.0/testsuite/_ocamltest/tests/frame-pointers/c_call/ocamlopt.byte/ocamlopt.byte.output to reference /builddir/build/BUILD/ocaml-5.1.0/testsuite/tests/frame-pointers/c_call.compilers.reference
> Action 3/8 (check-ocamlopt.byte-output) => passed
> 
> Running action 4/8 (run)
> Entering run_hook for hook /builddir/build/BUILD/ocaml-5.1.0/testsuite/tests/frame-pointers/c_call.run
> Hook should write its response to /tmp/ocamltest-1d976d.response
> Action 4/8 (run) => passed
> 
> Running action 5/8 (check-program-output)
> Comparing program output /builddir/build/BUILD/ocaml-5.1.0/testsuite/_ocamltest/tests/frame-pointers/c_call/ocamlopt.byte/c_call.opt.output to reference /builddir/build/BUILD/ocaml-5.1.0/testsuite/tests/frame-pointers/c_call.reference
> Action 5/8 (check-program-output) => failed (program output /builddir/build/BUILD/ocaml-5.1.0/testsuite/_ocamltest/tests/frame-pointers/c_call/ocamlopt.byte/c_call.opt.output differs from reference /builddir/build/BUILD/ocaml-5.1.0/testsuite/tests/frame-pointers/c_call.reference: 
> 
> )

That sh: line 1: : command not found text had me scrambling all over the makefiles, looking for some command being invoked that is not present in the buildroot. That turned out to be a red herring. The real problem is that the expected and actual outputs differ, and the filecompare.ml code reported the difference. When that happens the difference is reported as failure to find a command, which is misleading. But that's not what this issue is about.

Fedora builds all amd64 packages with frame pointers. The output of the c_call test looks like this:

fp_backtrace_many_args
caml_c_call_stack_args
camlC_call.f
camlC_call.entry
caml_program
caml_start_program
caml_main/caml_startup
main
_start
caml_c_call
camlC_call.f
camlC_call.entry
caml_program
caml_start_program
caml_main/caml_startup
main
_start
camlC_call.f
camlC_call.entry
caml_program
caml_start_program
caml_main/caml_startup
main
_start

This differs from the expected output because each stack trace has _start after main, due to glibc having been built with frame pointers. The frame-pointers tests should not fail because of the presence of _start.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions