haecker-felix / Gradio

GNU General Public License v3.0
326 stars 51 forks source link

[rust_port] Possible: Closures not dying #335

Closed sigmaSd closed 6 years ago

sigmaSd commented 6 years ago

I think there's a memory leak when searching , basically some closures keep running , for example ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 1 <-> Current: 2) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 2 <-> Current: 3) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 3 <-> Current: 4) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 4 <-> Current: 5) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 6 <-> Current: 7) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 7 <-> Current: 8) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 8 <-> Current: 9) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 10 <-> Current: 11) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 11 <-> Current: 12) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 12 <-> Current: 13) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 13 <-> Current: 14) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 15 <-> Current: 16) It can jump more like here

ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 11 <-> Current: 12) ERROR rustio::client > Search ID changed -> cancel this search loop. (This: 19 <-> Current: 20) (I changed debug to error for convenience) some loops aren't mentioned here for example 5,9,14 on the first example and 7 ones in the second example and memory keeps increasing each time I search a new thing , It starts close to 20mb than keeps increasing ,for example I reached 100mb quickly. Not sure if I'm missing something

sigmaSd commented 6 years ago

I added a print statement at the start of gtk::timeout::add closures, they actually all stop , none is left running, so that was wrong but I still cant explain the memory issue. hmm Maybe 100mb is normal I'll just close this issue for now.

haecker-felix commented 6 years ago

This behavior can be explained easily: You don't see a message, if the closure doesn't get aborted.

haecker-felix commented 6 years ago

However, there are still performance and memory issues. Look at the loading spinner. Before the results appear, there is a micro lag.

sigmaSd commented 6 years ago

Yeah the problem is I still can't figure debugging multithreaded programs , the magical combination of step step and breakpoints doesn't help that much in this case. Need more studying!