x10an14
commented
3 years ago I'm presuming here that you're in the role of a good samaritan who'd like to let the maintainer know of a (potential) problem. I'd highly recommend you to put some more effort into finding the actual error/crash (in a reproducible manner).
I (for one) can understand if a maintainer would ignore an input such as yours, with all the onus/work on the maintainer to understand your test-harness/setup and reproduce the error herself/himself.
For example, this output of yours doesn't really say anything as far as I can tell (beyond your Dockerfiles ENTRYPOINTmade it crash for an unknown/unspecified reason).
Found ninja-1.9.0 at /usr/bin/ninja
[1/26] Compiling C object 'test-parse-input@exe/color.c.o'
[2/26] Compiling C object 'test-parse-input@exe/parse.c.o'
[3/26] Compiling C object 'test-parse-input@exe/tests_wob_parse_input.c.o'
[4/26] Generating 'wob@exe/xdg-shell-client-protocol.h'.
[5/26] Generating 'wob@exe/wlr-layer-shell-unstable-v1-client-protocol.h'.
[6/26] Generating 'wob@exe/xdg-output-unstable-v1-client-protocol.h'.
[7/26] Generating 'wlr_layer_shell_unstable_v1@sta/wlr-layer-shell-unstable-v1-client-protocol.h'.
[8/26] Generating 'wlr_layer_shell_unstable_v1@sta/wlr-layer-shell-unstable-v1-protocol.c'.
[9/26] Generating 'xdg_output_unstable_v1@sta/xdg-output-unstable-v1-client-protocol.h'.
[10/26] Generating 'xdg_output_unstable_v1@sta/xdg-output-unstable-v1-protocol.c'.
[11/26] Generating 'xdg_shell@sta/xdg-shell-client-protocol.h'.
[12/26] Generating 'xdg_shell@sta/xdg-shell-protocol.c'.
[13/26] Compiling C object 'wlr_layer_shell_unstable_v1@sta/meson-generated_wlr-layer-shell-unstable-v1-protocol.c.o'
[14/26] Compiling C object 'xdg_output_unstable_v1@sta/meson-generated_xdg-output-unstable-v1-protocol.c.o'
[15/26] Compiling C object 'wob@exe/pledge.c.o'
[16/26] Compiling C object 'wob@exe/color.c.o'
[17/26] Compiling C object 'wob@exe/log.c.o'
[18/26] Compiling C object 'wob@exe/buffer.c.o'
[19/26] Compiling C object 'wob@exe/parse.c.o'
[20/26] Compiling C object 'wob@exe/main.c.o'
[21/26] Compiling C object 'xdg_shell@sta/meson-generated_xdg-shell-protocol.c.o'
[22/26] Linking static target libwlr_layer_shell_unstable_v1.a
[23/26] Linking target test-parse-input
[24/26] Linking static target libxdg_output_unstable_v1.a
[25/26] Linking static target libxdg_shell.a
[26/26] Linking target wob
1/1 parse-input FAIL 0.42s (exit status 2)
Ok: 0
Expected Fail: 0
Fail: 1
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Full log written to /wob/build/meson-logs/testlog-valgrind.txt
The command "printf 'set -eu
apk update && apk add meson wayland-dev musl-dev wayland-protocols gcc valgrind
meson build && meson test -C build --wrap="valgrind --leak-check=full --error-exitcode=2"
' | docker run -i -v "$PWD":/wob -w /wob alpine:3.12
" exited with 1.CAVEAT: I might not be too familiar with Travis-CI, but then again I feel that proves my point of the reporter putting the onus on the maintainer to learn/understand the reporter's set-up. Maintainers generally receive enough reports that it's already hard having the capacity to filter (let alone solve) the ones where no understanding-efforts of the problem is required.
I am running the build and test as a part of the Ubuntu distribution for ppc64le. This helps us simplify testing later when distributions are re-building and re-releasing.
During the build and test, I found that alpine, coding style check and static analyzer are passing. However valgrind test is failing with the error as
Could you pl. take a look into the same. Logs can be found at https://travis-ci.com/github/gururajrkatti/wob/jobs/457187995