Skip to content

Conversation

@craigcomstock
Copy link
Contributor

This PR is focused on only increasing code coverage to core as-is for exit() calls. This is in preparation for the refactor away from atexit() for Windows' sake.

Will squash once I get as much coverage as is reasonable.

@craigcomstock craigcomstock added the WIP Work in Progress label Aug 1, 2018
@codecov
Copy link

codecov bot commented Aug 3, 2018

Codecov Report

Merging #3197 into master will increase coverage by 1.27%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #3197      +/-   ##
==========================================
+ Coverage   61.87%   63.14%   +1.27%     
==========================================
  Files         211      212       +1     
  Lines       46332    46360      +28     
==========================================
+ Hits        28669    29276     +607     
+ Misses      17663    17084     -579
Impacted Files Coverage Δ
cf-serverd/server_transform.c 26.08% <ø> (+26.08%) ⬆️
libenv/unix_iface.c 85.49% <100%> (+0.89%) ⬆️
libpromises/files_names.c 72.34% <0%> (-0.71%) ⬇️
libpromises/locks.c 81.66% <0%> (-0.25%) ⬇️
cf-serverd/cf-serverd.c 66.66% <0%> (ø)
libpromises/eval_context.c 86.89% <0%> (+0.15%) ⬆️
libpromises/loading.c 84.52% <0%> (+0.37%) ⬆️
libpromises/policy.c 71.46% <0%> (+0.88%) ⬆️
libutils/string_lib.c 65.97% <0%> (+1.87%) ⬆️
... and 16 more

Impacted file tree graph


Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 11b10fb...c23c55f. Read the comment docs.

@craigcomstock craigcomstock force-pushed the atexit-code-coverage branch 2 times, most recently from e8a8f95 to e5f2cb8 Compare August 8, 2018 14:05
@craigcomstock
Copy link
Contributor Author

craigcomstock commented Aug 8, 2018

Build Status

Copy link
Contributor Author

@craigcomstock craigcomstock Aug 8, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for what it's worth... I tried some

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-label"
...
#pragma GCC diagnostic pop

But it didn't seem to remove the warnings when I was compiling locally. :(

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as it turns out these unused labels don't seem to break travis/jenkins even though -Werror seems to be enabled. I fixed cf-monitor/env_monitor.c label with a gcc Label Attribute like:

__attribute__((unused));

So maybe just to be safe I will add that to these labels as well.

@craigcomstock
Copy link
Contributor Author

Build Status

@craigcomstock craigcomstock removed the WIP Work in Progress label Aug 22, 2018
@craigcomstock
Copy link
Contributor Author

Build Status

Copy link
Contributor

@vpodzime vpodzime left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the line "hard-coded" numbers are an issue. Maybe we should use something like grep -n to get the line numbers of particular labels and then use these "adapting" line numbers in the gdb scripts?

.travis.yml Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also add -ggdb3.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I worked on a grep -n solution for a little while but then dropped it. Will pick it back up now and try to get it done. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vpodzime do you think -g3 (-ggdb3 equivalent I think) would fix the labels problem I had? Maybe academic now since I likely have the grep -n solution working.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whose gonna update these line numbers when the file(s) is/are changed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this about?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was an attempt by me to streamline the test cycle with jenkins and such... by settings a TESTS var and only running the test I wanted to check on. It's half-baked so will remove it. Thanks for the catch.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vpodzime something like the above? It seemed to work pretty well. I will work on the other two instances when I can.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, something like that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vpodzime how about this? I like it pretty well. Need to implement the other two instances and test on travis/jenkins

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using a more noticeable prefix like GDB: would be better. Also it would be nice if the comment was aligned with the code. But it's not a big deal.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be better done with a files: promise, right?

@craigcomstock
Copy link
Contributor Author

@cf-bottom jenkins build please

@cf-bottom
Copy link

Alright, I triggered a build:

Build Status

https://ci.cfengine.com/job/pr-pipeline/1055/

@craigcomstock
Copy link
Contributor Author

@cf-bottom jenkins builds please

@cf-bottom
Copy link

Alright, I triggered a build:

Build Status

https://ci.cfengine.com/job/pr-pipeline/1080/

@craigcomstock craigcomstock added the WIP Work in Progress label Sep 7, 2018
@craigcomstock
Copy link
Contributor Author

made this a WIP in hopes that a combined refactor+tests PR works better: #3252

@craigcomstock
Copy link
Contributor Author

abandoning due to complexity of testing exit() calls.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

WIP Work in Progress

Development

Successfully merging this pull request may close these issues.

3 participants