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

[feature-request #7] Make avarice when started inside a gdb session immune to SIGINT #81

Open
avrs-admin opened this issue Jan 27, 2022 · 2 comments

Comments

@avrs-admin
Copy link
Collaborator

johny_flash
2013-02-26 20:58:26.364000

Currently, if avarice is started by means of the shell command within a gdb session you can't stop the uC with Ctrl-C without killing avarice. And thus closing the connection to the remote target.

At least for my workflow it would make debugging a lot easier when avarice ignores SIGINT if started in detached mode.

Unfortunately it seems to be harder than simply put

signal(SIGINT, SIG_IGN);

into the if(detach) condition inside main().

It would be so kind if somebody put some effort into this or rather give a hint how to achieve this.

With best regards

This issue was migrated from https://sourceforge.net/p/avarice/feature-requests/7/

@avrs-admin
Copy link
Collaborator Author

jehle
2015-05-28 10:31:29.422000

Are there any solutions yet? ice-gdb is relies on calling avarice in detached mode - so every ctrl+c doesn't only stop gdb it also stops avarice what is quiet annoying.

I tried to trap SIGINT in start-avarice script or start via "nohup" but was not sucessful

@avrs-admin
Copy link
Collaborator Author

jehle
2015-05-28 12:31:11.691000

Solved it somehow: the problem is the common parent process (don't ask me why...). When you start avarice in a screen session it's working fine.

Change last line in /usr/bin/start-avarice to:
screen -dm avarice $AVARICE_ARGS localhost:6423

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant