Memory leak on Mac

[cosmoduff]

I am new to this so sorry if I am missing any information. When sending a notification on a separate thread a program will begin to consume more and more memory. This can be observed by writing a simple program that spawns a thread and then sends a notification from it. I suspect this issue may actually live in mac-notification-sys. I have observed this issue on macOS High Sierra.

Example:

extern crate notify_rust;

use notify_rust::Notification;
use std::thread::{sleep,spawn};
use std::time::Duration;

fn notify() {
   Notification::new()
       .summary("Firefox News")
       .body("This will look like a real notification.")
       .show()
       .unwrap();
}

fn main() {
    println!("Starting loop");
    loop{
        spawn(|| {
            println!("In the thread.");
            notify();
        });
        let dur = Duration::from_secs(5);
        sleep(dur);
    }
}

[hoodie]

thank you - @h4llow3En what do you think?

[h4llow3En]

Did you tried it also on Linux systems? Or do you just noticed it on Mac?
Interestingly the memory usage seems to grow faster if build with the --release flag.
Also all spawned subprocesses seem to stay open.
This need some further investigation - @hoodie Are you able to confirm this on Linux as well?

[h4llow3En]

Over the last 30 Minutes tested the script above using mac-notification-sys directly. The memory usage stayed consistent all the time.

[h4llow3En]

Maybe you should upgrade mac-notification-sys in notify-rust. You are still using v0.1
Unfortunately this is not that easy. The used error crate failure is in conflict with error-chain.

[h4llow3En]

Could be done with #44

[hoodie]

I didn't do that back then because the failure crate caused issues with dbus-rs. So I could probably update that along site. But I might have to ask for a backport of mac-notifications-sys using error-chain, just as a heads up. Thanks for looking into it though @h4llow3En 👍

[cosmoduff]

@h4llow3En I haven't seen the issue on Linux systems. I've tested it on recently patched versions of Void Linux and Arch.

[h4llow3En]

Yes a backport is a possible idea. But you also should consider changing to failure since error-chain seems to be deprecated (rust-lang-nursery/failure#181). If you wish I could have a look into that

[hoodie]

I am currently in the process of migrating to the latest dbus version, in the process of that I'm rewriting about 10% of the code. After that I can take some time to migrate it to failure. If you wish we could pair on that 😄 Any time this week[end] ?

[h4llow3En]

Sure, if I find the time! 🙂 But I can't guarantee it

[cosmoduff]

@h4llow3En I don't know if this will be helpful but the issue does not exist if the program is run with sudo or as root.

[mkroehnert]

Linking #49 and #50, since they seem to originate from this thread.
Hadn't seen this discussion before replying to the failure update ticket, but it would have helped understand the context better.

[hoodie]

the next release will have mac-notification-sys 0.3 will this solve the issue?
@cosmoduff

[cosmoduff]

Sorry for the delay. Yes the issue does not exist in version 3.6. This issue can be closed. Thanks!