Skip to content
This repository was archived by the owner on May 31, 2025. It is now read-only.

Changed calling_in_this_thread restore mechanism in callOneCB from try-catch to RAII.#811

Merged
dirk-thomas merged 1 commit intoros:kinetic-develfrom
jasonimercer:do-not-catch-user-exception-callOneCB
Jun 1, 2016
Merged

Changed calling_in_this_thread restore mechanism in callOneCB from try-catch to RAII.#811
dirk-thomas merged 1 commit intoros:kinetic-develfrom
jasonimercer:do-not-catch-user-exception-callOneCB

Conversation

@jasonimercer
Copy link
Copy Markdown
Contributor

This PR prevents the try-catch on callOneCB from masking the source of the original exception in a callback. We have encountering this situations here at Clearpath and the community has reported similar problems:

http://answers.ros.org/question/167386/node-crashes-on-spinonce/

@dirk-thomas @mikepurvis

@mikepurvis
Copy link
Copy Markdown
Member

LGTM.

{
// ensure that thread id gets restored, even in case of an exception
tls->calling_in_this_thread = last_calling;
throw;
Copy link
Copy Markdown
Member

@dirk-thomas dirk-thomas Jun 1, 2016

Choose a reason for hiding this comment

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

throw without an exception argument re-throws the current exception and doesn't create a new one. Therefore I don't see why this change is necessary. Can you please provide a minimal example which demonstrates why the current code is not sufficient and "masks" the source of the original exception.

Copy link
Copy Markdown
Contributor Author

@jasonimercer jasonimercer Jun 1, 2016

Choose a reason for hiding this comment

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

Sure, the community link provided shows an exception that was thrown by user code but the strack trace in gdb leads to callOneCB. The exception is the same but the source of the exception is lost.

The last remark of the user in that post was "The stack trace I posted was in Debug mode. It's strange that it didn't lead me to my callback function."

I'll put together a minimal example.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Nvm, I didn't think about it before. While it passes along the same exception it will change the reported line in e.g. gdb which is clearly undesired.

@dirk-thomas
Copy link
Copy Markdown
Member

Thanks for the patch!

Do you want this to be backported to Indigo / Jade as well?

@jasonimercer
Copy link
Copy Markdown
Contributor Author

A backport isn't required for our needs. I'll let you decide if it is of value for the community and timeline accordingly.

Thanks for merging this into kinetic-devel!

@dirk-thomas
Copy link
Copy Markdown
Member

@ros/ros_team I would like your feedback if you think this should be backported. While the patch isn't necessary it would improve the stack trace in the case of problems for users. If we agree that this change doesn't pose a risk for regressions I would move forward with the backport.

@wjwwood
Copy link
Copy Markdown
Member

wjwwood commented Jun 2, 2016

I think should be safe to backport. I can't think of anyway this would affect existing code.

@mikepurvis
Copy link
Copy Markdown
Member

We've been running it already in our overnight testing— it's great getting full stack traces in our crash reporter!

rsinnet pushed a commit to MisoRobotics/ros_comm that referenced this pull request Jun 19, 2017
…ion-callOneCB

Changed calling_in_this_thread restore mechanism in callOneCB from try-catch to RAII.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants