Closed tyler92 closed 8 months ago
Attention: 9 lines
in your changes are missing coverage. Please review.
Comparison is base (
fe5639a
) 77.92% compared to head (92973b3
) 78.11%. Report is 1 commits behind head on master.:exclamation: Current head 92973b3 differs from pull request most recent head e6f27c2. Consider uploading reports for the commit e6f27c2 to get more accurate results
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
ABI check has failed due to the destructor. I would appreciate any help with it. Also, some clangs check failed, but it looks like the failures aren't related to the PR.
Probably related: https://github.com/pistacheio/pistache/issues/44
Hey @tyler92. Thanks for your PR. Two requests:
valgrind --track-fds=eys
confirms the leak, then that is a good start to replicate the problem and verify that your PR has solved it.@kiplingw Done. I've implemented a simple check of the /proc/self/fd
directory with a message about Valgrind as a fallback. This test passed with the fix and failed without it. The Valgrind report without the fix just for reference:
I see the test http_server_test.multiple_client_with_requests_to_multithreaded_server
is failed due to timeout, but I'm not sure if this is related to my changes
I was going to say the same thing. It seems fine, but it's an area of the code base I'm less familiar with. @dennisjenkins75 thoughts?
@kiplingw @dennisjenkins75 Hi. Do we have any chance to review/merge it?
I'm fine with it. But while we wait for @dennisjenkins75's feedback, I'd suggest bumping the patch version in version.txt
because the one you've got now is already old in lieu of a recent PR.
This needs to be updated in lieu of the most recent merged PR.
Done
Hey @tyler92. Thank you for your PR. While we await @dennisjenkins75, I can probably anticipate at least some of his feedback: I think it would be prudent if you were able to add a unit test somehow to verify the leak and the fix.
You might have to be creative by monitoring /proc/self/fd
. Note that trying to open anything there, there will be, of course, an additional FD created by trying to introspect. So you'll have to think about that.
Hey @tyler92. Thank you for your PR. While we await @dennisjenkins75, I can probably anticipate at least some of his feedback: I think it would be prudent if you were able to add a unit test somehow to verify the leak and the fix.
You might have to be creative by monitoring
/proc/self/fd
. Note that trying to open anything there, there will be, of course, an additional FD created by trying to introspect. So you'll have to think about that.
Oh, yeah, thanks. For some reason, I lost my unit test while rebasing my branch. Please find the unit test in the latest push. The test failed without the patch, and it's passed with it.
Suggestion:
And just so you know @tyler92, we're not trying to give you the runaround. Your PR in principal makes sense. We just want to make sure we don't make new problems.
@kiplingw @dennisjenkins75 I've added new target tests/helpers with the function for getting a count of open file descriptors and tests. I'm not sure about the style for the copyright header, CMakeLists.txt, and meson.build, so please let me know if you don't like something (even minor things)
I can't see any immediate issues that stand out, but interested to hear what @dennisjenkins75 says.
There was no
close
call for the file descriptors created witheventfd
andtimerfd_create
. It led to a file descriptors leak. I'm really not sure if the fix may have a bad impact, but at least there is no leak now.