Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RFE: enable automated continuous integration testing #2

Closed
pcmoore opened this issue Mar 11, 2015 · 6 comments
Closed

RFE: enable automated continuous integration testing #2

pcmoore opened this issue Mar 11, 2015 · 6 comments
Assignees
@pcmoore
Labels
enhancement priority/low

Comments

@pcmoore
Copy link
Member

pcmoore commented Mar 11, 2015

Patch to enable support for the Travis CI service:

https://groups.google.com/forum/#!topic/libseccomp/wuzIVIwKIvU
@pcmoore pcmoore self-assigned this Mar 11, 2015
@pcmoore
Copy link
Member Author

pcmoore commented Mar 13, 2015

Patch to enable support for the Codeship service:

https://groups.google.com/forum/#!topic/libseccomp/75xRW_X5SsA

@pcmoore pcmoore changed the title Enable Travis CI automated testing Enable automated continuous integration testing Mar 13, 2015
@pcmoore pcmoore changed the title Enable automated continuous integration testing RFE: enable automated continuous integration testing Mar 13, 2015
@androm3da
Copy link
Contributor

I tried a couple of different ones mentioned on quora:

  • Travis
  • Shippable
  • Codeship

Travis seems like a popular one, so it seemed reasonable to start there. libseccomp just can't build there since it uses a distro release that's so old. Shippable uses a similar/identical build metadata file as Travis'. Shippable claims to have Ubuntu 13.10 but they don't explicitly support C/C++ (only higher level languages like Java/ruby/python/php/etc). They probably have incidental support since those languages often provide extension mechanisms that expect to be able to use a compiler and linker.

Codeship uses ubuntu 14.04, and unlike the others offers you no superuser access to the target build node. Also, its build metadata is stored with your user's account and not with the project. They offer a convenient ssh-on-demand for build debugging. This is much more convenient than the git-push-trial-and-error required with the others.

All of them work with Github's API to detect a push or a pull request to trigger a new build.

I decided to try Codeship after failing with Travis. I designed the CI script in my patch to the mailing list to be pretty generic. We could invoke it from the Travis or Shippable CI config file. But at least until Travis updates to a newer release it won't work there. It may work on Shippable, though.

@pcmoore
Copy link
Member Author

pcmoore commented Feb 10, 2016

The Fedora team also a Jenkins instance for CI which might be another option:

@pcmoore
Copy link
Member Author

pcmoore commented Aug 23, 2016

Another, easier, first step might to be doing continuous builds using Fedora's Copr infrastructure.

@dkopecek
Copy link

FYI: It's possible to get an Ubuntu 14.04 (trusty) environment on Travis CI. Here are the details: https://docs.travis-ci.com/user/trusty-ci-environment/

@pcmoore
Copy link
Member Author

pcmoore commented Feb 5, 2017

Added initial Travis CI support in 47bdf57. The current Travis configuration tests both the native/C and the Python bindings as well as both the standard and "live" regression tests on Ubuntu Trusty x86_64.

At some point we may want to look at expanding our CI testing to other platforms/architectures, but this is a good first step. I'm going to close this out, we can track any expanded efforts in new issues/PRs.

@pcmoore pcmoore closed this as completed Feb 5, 2017
giuseppe added a commit to giuseppe/libseccomp that referenced this issue Mar 18, 2021
@giuseppe
bpf: fix uninitialized value usage
64ebe8e 
it was reported by clang with the option -fsanitize=memory:

  Uninitialized value was created by a heap allocation
    #0 0x4547ef in realloc (src/crun/tests/tests_libcrun_fuzzer+0x4547ef)
    seccomp#1 0x7f4900a3a903 in _bpf_append_blk src/libseccomp/src/gen_bpf.c:452:10
    seccomp#2 0x7f4900a3a903 in _gen_bpf_build_bpf src/libseccomp/src/gen_bpf.c:2276:8
    seccomp#3 0x7f4900a3a903 in gen_bpf_generate src/libseccomp/src/gen_bpf.c:2324:7

  Uninitialized value was created by a heap allocation
    #0 0x4547ef in realloc (src/crun/tests/tests_libcrun_fuzzer+0x4547ef)
    seccomp#1 0x7f8f755a81c0 in _blk_resize.constprop.0 src/libseccomp/src/gen_bpf.c:362:8

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe added a commit to giuseppe/libseccomp that referenced this issue Mar 18, 2021
@giuseppe
bpf: fix uninitialized value usage
9777751 
it was reported by clang with the option -fsanitize=memory:

Uninitialized bytes in MemcmpInterceptorCommon at offset 0 inside [0x7070000002a0, 56)
==3791089==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x482a2c in memcmp (fuzzer+0x482a2c)
    seccomp#1 0x7fed2f120ebb in _hsh_add src/libseccomp/src/gen_bpf.c:598:9
    seccomp#2 0x7fed2f121715 in _gen_bpf_action_hsh src/libseccomp/src/gen_bpf.c:796:6
    seccomp#3 0x7fed2f121a53 in _gen_bpf_node src/libseccomp/src/gen_bpf.c:831:11
    seccomp#4 0x7fed2f121a53 in _gen_bpf_chain.isra.0 src/libseccomp/src/gen_bpf.c:1072:13
    seccomp#5 0x7fed2f121f16 in _gen_bpf_chain_lvl_res src/libseccomp/src/gen_bpf.c:977:12
    seccomp#6 0x7fed2f121c74 in _gen_bpf_chain.isra.0 src/libseccomp/src/gen_bpf.c:1124:12
    seccomp#7 0x7fed2f12253c in _gen_bpf_syscall src/libseccomp/src/gen_bpf.c:1520:10
    seccomp#8 0x7fed2f12253c in _gen_bpf_syscalls src/libseccomp/src/gen_bpf.c:1615:18
    seccomp#9 0x7fed2f12253c in _gen_bpf_arch src/libseccomp/src/gen_bpf.c:1683:7
    seccomp#10 0x7fed2f12253c in _gen_bpf_build_bpf src/libseccomp/src/gen_bpf.c:2056:11
    seccomp#11 0x7fed2f12253c in gen_bpf_generate src/libseccomp/src/gen_bpf.c:2321:7
    seccomp#12 0x7fed2f11f41c in seccomp_export_bpf src/libseccomp/src/api.c:724:7

  Uninitialized value was created by a heap allocation
    #0 0x4547ef in realloc (fuzzer+0x4547ef)
    seccomp#1 0x7fed2f121244 in _blk_resize src/libseccomp/src/gen_bpf.c:362:8
    seccomp#2 0x7fed2f121244 in _blk_append src/libseccomp/src/gen_bpf.c:394:6

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
@giuseppe giuseppe mentioned this issue Mar 18, 2021
Merged
giuseppe added a commit to giuseppe/libseccomp that referenced this issue Mar 18, 2021
@giuseppe
bpf: fix uninitialized value usage
064e793 
it was reported by clang with the option -fsanitize=memory:

Uninitialized bytes in MemcmpInterceptorCommon at offset 0 inside [0x7070000002a0, 56)
==3791089==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x482a2c in memcmp (fuzzer+0x482a2c)
    seccomp#1 0x7fed2f120ebb in _hsh_add src/libseccomp/src/gen_bpf.c:598:9
    seccomp#2 0x7fed2f121715 in _gen_bpf_action_hsh src/libseccomp/src/gen_bpf.c:796:6
    seccomp#3 0x7fed2f121a53 in _gen_bpf_node src/libseccomp/src/gen_bpf.c:831:11
    seccomp#4 0x7fed2f121a53 in _gen_bpf_chain.isra.0 src/libseccomp/src/gen_bpf.c:1072:13
    seccomp#5 0x7fed2f121f16 in _gen_bpf_chain_lvl_res src/libseccomp/src/gen_bpf.c:977:12
    seccomp#6 0x7fed2f121c74 in _gen_bpf_chain.isra.0 src/libseccomp/src/gen_bpf.c:1124:12
    seccomp#7 0x7fed2f12253c in _gen_bpf_syscall src/libseccomp/src/gen_bpf.c:1520:10
    seccomp#8 0x7fed2f12253c in _gen_bpf_syscalls src/libseccomp/src/gen_bpf.c:1615:18
    seccomp#9 0x7fed2f12253c in _gen_bpf_arch src/libseccomp/src/gen_bpf.c:1683:7
    seccomp#10 0x7fed2f12253c in _gen_bpf_build_bpf src/libseccomp/src/gen_bpf.c:2056:11
    seccomp#11 0x7fed2f12253c in gen_bpf_generate src/libseccomp/src/gen_bpf.c:2321:7
    seccomp#12 0x7fed2f11f41c in seccomp_export_bpf src/libseccomp/src/api.c:724:7

  Uninitialized value was created by a heap allocation
    #0 0x4547ef in realloc (fuzzer+0x4547ef)
    seccomp#1 0x7fed2f121244 in _blk_resize src/libseccomp/src/gen_bpf.c:362:8
    seccomp#2 0x7fed2f121244 in _blk_append src/libseccomp/src/gen_bpf.c:394:6

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pcmoore pcmoore

Labels
enhancement priority/low
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dkopecek @pcmoore @androm3da