Skip to content
This repository has been archived by the owner on May 21, 2024. It is now read-only.

Fix/ostree install memory leaks #1120

Merged
merged 4 commits into from
Mar 1, 2019
Merged

Conversation

pattivacek
Copy link
Collaborator

Actually fix two and suppress two others that look similar to already known issues.

@@ -317,24 +318,24 @@ GObjectUniquePtr<OstreeDeployment> OstreeManager::getStagedDeployment() const {
}

GObjectUniquePtr<OstreeSysroot> OstreeManager::LoadSysroot(const boost::filesystem::path &path) {
OstreeSysroot *sysroot = nullptr;
OstreeSysroot *sysroot_raw = nullptr;
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 you can use .reset() to update the value of a GObjectUniquePtr and forego the sysroot_raw intermediary which can potentially be misused.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good call. Done.

Copy link
Contributor

@lbonn lbonn left a comment

Choose a reason for hiding this comment

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

Looking good, apart from the small style comment!

Also rewrap a pointer from ostree_sysroot_new to try make that cleaner.

Signed-off-by: Patrick Vacek <[email protected]>
This appears to be a false positive, and valgrind just says it is
"possibly" lost anyway.

Signed-off-by: Patrick Vacek <[email protected]>
Valgrind gets really confused by this and spits out a bunch of
complaints in strange places (such as ReportQueue) as well.

Signed-off-by: Patrick Vacek <[email protected]>
@pattivacek pattivacek force-pushed the fix/ostree-install-memory-leaks branch from 8f7347e to 3bb1beb Compare February 28, 2019 16:24
@lbonn
Copy link
Contributor

lbonn commented Feb 28, 2019

Hm I've taken another look and I'm not sure the ioctl error is exactly the same. Though it's also probably a false positive.

Do you have the full valgrind log?

@pattivacek
Copy link
Collaborator Author

pattivacek commented Mar 1, 2019

Do you have the full valgrind log?

--25371-- WARNING: unhandled amd64-linux syscall: 326
--25371-- You may be able to write your own handler.
--25371-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--25371-- Nevertheless we consider this a bug.  Please report
--25371-- it at http://valgrind.org/support/bug_reports.html.
==25371== Syscall param ioctl(generic) points to unaddressable byte(s)
==25371==    at 0x82715D7: ioctl (syscall-template.S:78)
==25371==    by 0x6AAD8CE: ??? (in /usr/lib/x86_64-linux-gnu/libostree-1.so.1.0.0)
==25371==    by 0x6AB0721: ostree_sysroot_write_deployments_with_options (in /usr/lib/x86_64-linux-gnu/libostree-1.so.1.0.0)
==25371==    by 0x6AA95BF: ostree_sysroot_simple_write_deployment (in /usr/lib/x86_64-linux-gnu/libostree-1.so.1.0.0)
==25371==    by 0x156762: OstreeManager::install(Uptane::Target const&) const (ostreemanager.cc:189)
==25371==    by 0x160E8A: SotaUptaneClient::PackageInstall(Uptane::Target const&) (sotauptaneclient.cc:134)
==25371==    by 0x12D361: update_main(Config&, boost::program_options::variables_map const&) (main.cc:90)
==25371==    by 0x12F7EE: main (main.cc:208)
==25371==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

If I remove the suppression (or comment out the call to ostree_sysroot_write_deployments_with_options), then I also get some errors like this:

==25395== 16 bytes in 1 blocks are definitely lost in loss record 841 of 3,326
==25395==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25395==    by 0x733DA28: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.3)
==25395==    by 0x73558E5: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.3)
==25395==    by 0x7355D98: g_slice_alloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.3)
==25395==    by 0x7334E19: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.3)
==25395==    by 0x7338104: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.3)
==25395==    by 0x73385BF: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.3)
==25395==    by 0x73388D1: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.3)
==25395==    by 0x6DC8025: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.5600.3)
==25395==    by 0x7360104: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.3)
==25395==    by 0x5C8B6DA: start_thread (pthread_create.c:463)
==25395==    by 0x827C88E: clone (clone.S:95)

and

==25395== 32 bytes in 1 blocks are definitely lost in loss record 2,002 of 3,326
==25395==    at 0x4C3017F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25395==    by 0x2200C7: _S_make_state<std::thread::_Invoker<std::tuple<std::_Bind<void (ReportQueue::*(ReportQueue*))()> > > > (thread:197)
==25395==    by 0x2200C7: thread<std::_Bind<void (ReportQueue::*(ReportQueue*))()> > (thread:126)
==25395==    by 0x2200C7: ReportQueue::ReportQueue(Config const&, std::shared_ptr<HttpInterface>) (reportqueue.cc:9)
==25395==    by 0x16021D: construct<ReportQueue, Config&, std::shared_ptr<HttpClient>&> (new_allocator.h:136)
==25395==    by 0x16021D: construct<ReportQueue, Config&, std::shared_ptr<HttpClient>&> (alloc_traits.h:475)
==25395==    by 0x16021D: _Sp_counted_ptr_inplace<Config&, std::shared_ptr<HttpClient>&> (shared_ptr_base.h:526)
==25395==    by 0x16021D: __shared_count<ReportQueue, std::allocator<ReportQueue>, Config&, std::shared_ptr<HttpClient>&> (shared_ptr_base.h:637)
==25395==    by 0x16021D: __shared_ptr<std::allocator<ReportQueue>, Config&, std::shared_ptr<HttpClient>&> (shared_ptr_base.h:1295)
==25395==    by 0x16021D: shared_ptr<std::allocator<ReportQueue>, Config&, std::shared_ptr<HttpClient>&> (shared_ptr.h:344)
==25395==    by 0x16021D: allocate_shared<ReportQueue, std::allocator<ReportQueue>, Config&, std::shared_ptr<HttpClient>&> (shared_ptr.h:691)
==25395==    by 0x16021D: make_shared<ReportQueue, Config&, std::shared_ptr<HttpClient>&> (shared_ptr.h:707)
==25395==    by 0x16021D: SotaUptaneClient::newDefaultClient(Config&, std::shared_ptr<INvStorage>, std::shared_ptr<boost::signals2::signal<void (std::shared_ptr<event::BaseEvent>), boost::signals2::optional_last_value<void>, int, std::   less<int>, boost::function<void (std::shared_ptr<event::BaseEvent>)>, boost::function<void (boost::signals2::connection const&, std::shared_ptr<event::BaseEvent>)>, boost::signals2::mutex> >) (sotauptaneclient.cc:32)
==25395==    by 0x12C973: update_main(Config&, boost::program_options::variables_map const&) (main.cc:72)
==25395==    by 0x12F7EE: main (main.cc:208)

@codecov-io
Copy link

Codecov Report

Merging #1120 into master will decrease coverage by 0.01%.
The diff coverage is 45.45%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1120      +/-   ##
==========================================
- Coverage   76.07%   76.06%   -0.02%     
==========================================
  Files         158      158              
  Lines        9544     9544              
==========================================
- Hits         7261     7260       -1     
- Misses       2283     2284       +1
Impacted Files Coverage Δ
src/libaktualizr/package_manager/ostreemanager.cc 53.64% <45.45%> (-0.43%) ⬇️

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 2aa3917...3bb1beb. Read the comment docs.

@lbonn
Copy link
Contributor

lbonn commented Mar 1, 2019

Ok it's from here: https://github.com/ostreedev/ostree/blob/13bcc49603b54f117c44e25dc2b457b9f25d9dc0/src/libostree/ostree-sysroot-deploy.c#L1375,

93: ==3974== Syscall param ioctl(generic) points to unaddressable byte(s)
93: ==3974==    at 0x82A35D7: ioctl (syscall-template.S:78)
93: ==3974==    by 0x6AC9093: fsfreeze_thaw_cycle (ostree-sysroot-deploy.c:1375)
93: ==3974==    by 0x6AC9431: full_system_sync (ostree-sysroot-deploy.c:1439)
93: ==3974==    by 0x6ACB536: write_deployments_bootswap (ostree-sysroot-deploy.c:2133)
93: ==3974==    by 0x6ACBE90: ostree_sysroot_write_deployments_with_options (ostree-sysroot-deploy.c:2350)
93: ==3974==    by 0x6AC1B35: ostree_sysroot_simple_write_deployment (ostree-sysroot.c:1654)
93: ==3974==    by 0x156688: OstreeManager::install(Uptane::Target const&) const (ostreemanager.cc:188)
93: ==3974==    by 0x160E9E: SotaUptaneClient::PackageInstall(Uptane::Target const&) (sotauptaneclient.cc:134)
93: ==3974==    by 0x12D312: update_main(Config&, boost::program_options::variables_map const&) (main.cc:90)
93: ==3974==    by 0x12F78E: main (main.cc:208)
93: ==3974==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

But no big deal anyway, this is definitely false positive.

@lbonn lbonn merged commit ea03a5c into master Mar 1, 2019
@lbonn lbonn deleted the fix/ostree-install-memory-leaks branch March 1, 2019 17:07
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants