Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Processes not cleared when shutting down through close button #105

Closed
Achllle opened this issue Feb 3, 2020 · 6 comments
Closed

Processes not cleared when shutting down through close button #105

Achllle opened this issue Feb 3, 2020 · 6 comments
Assignees
Labels
flexbe_app Actually for repo FlexBE/flexbe_app resolved on develop Resolved on the development branch, no further work expected.

Comments

@Achllle
Copy link
Contributor

Achllle commented Feb 3, 2020

Steps to reproduce

  1. open your system monitor and search for executables related to FlexBE. On my machine, searching python only yields processes related to FlexBE.
  2. launch the app roslaunch flexbe_app flexbe_full.launch
  3. close it by clicking the 'close' button (red X) on the app and then sending a SIGINT to the terminal running the roslaunch command.

Expected behavior

The processes disappear as soon as the app is closed.

Actual behavior

The processes remain, and stack up: if you relaunch FlexBE and close using the same steps as above, additional processes will be created.

Additional info

Processes are mostly similar, take up between 0 and 3% CPU (~30% one core) and around 43MiB of memory. This adds up pretty quick on compute/memory limited devices. One such process has the following 'command line' field:

python -c
import rospy 
import sys 
import importlib 
import json 
import genpy 
import yaml  

def callback(msg): 
    sys.stdout.write(json.dumps(yaml.load(genpy.message.strify_message(msg)))
    sys.stdout.flush()  
    topic = sys.argv[1] 
    msg_def = sys.argv[2].split('/') 
    msg_pkg = msg_def[0] 
    msg_name = msg_def[1]  
    rospy.init_node('flexbe_app_sub_%s' % topic.replace('/', '_'))  
    msg_module = importlib.import_module('%s.msg' % msg_pkg) 
    msg_class = getattr(msg_module, msg_name)  
    sub = rospy.Subscriber(topic, msg_class, callback)  
    rospy.spin()

The log on STDOUT doesn't show any difference, except for [flexbe_app-3] process has finished cleanly. The log file is empty.

@pschillinger
Copy link
Member

I only saw this behavior so far when running the debug mode and restarting from the built-in function, but I will check whether I can reproduce it outside the debug mode as well.

In general, the clean-up happens in the "exit" event of the process. Looks like this event is interrupted/skipped whenever the sub-processes remain active.

@pschillinger pschillinger added the flexbe_app Actually for repo FlexBE/flexbe_app label Feb 9, 2020
@pschillinger pschillinger self-assigned this Feb 9, 2020
@cheffe112
Copy link
Contributor

Thanks for investigating, Philipp!
I can confirm this issue; though it happens only when closing the FlexBE app and not Ctrl+C-ing the roslaunch. It seems like the close() callback in io_stateparser.py doesn't get called in this case. I've experimented with the exit callback, but that didn't get called either.

Even more annoying, on my system the Python processes use 100% CPU once the app is closed and the only way to continue is to manually kill them... My current workaround is to Ctrl+C the roslaunch, but that doesn't feel like a proper solution.

@pschillinger
Copy link
Member

Thinking about it, I guess it kind of makes sense: Closing the window does not exit the process, so the shutdown/close functions are not called.

I added it also to the "close" event of the window on the above commit (separate branch), does this resolve the issue?

@cheffe112
Copy link
Contributor

Looks good code-wise, but meanwhile I cannot reproduce this anymore because I fixed my state definitions following the debug outputs introduced in #99. 😄
So I can't get the Python parsing to crash anymore, hence this problem is gone. Maybe @Achllle can confirm whether this fix works?

@Achllle
Copy link
Contributor Author

Achllle commented Feb 12, 2020

I can confirm that the fix/handle_closed_window branch fixes the issue! This can be closed once that PR goes in.

@pschillinger pschillinger added the resolved on develop Resolved on the development branch, no further work expected. label Mar 1, 2020
@pschillinger
Copy link
Member

Released with flexbe_app 2.2.4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flexbe_app Actually for repo FlexBE/flexbe_app resolved on develop Resolved on the development branch, no further work expected.
Projects
None yet
Development

No branches or pull requests

3 participants