Skip to content

Conversation

ezyang
Copy link
Contributor

@ezyang ezyang commented Mar 10, 2021

Stack from ghstack:

Without throwing, we can easily segfault trying to access nullptr
storage.

To do this I made set_storage_access_should_throw public so that you
don't have to subclass TensorImpl to do it. An alternative is
to just bite the bullet and add a MetaTensorImpl subclass. Let
me know what is preferred.

Signed-off-by: Edward Z. Yang ezyang@fb.com

Differential Revision: D26955540

Without throwing, we can easily segfault trying to access nullptr
storage.

To do this I made set_storage_access_should_throw public so that you
don't have to subclass TensorImpl to do it.  An alternative is
to just bite the bullet and add a MetaTensorImpl subclass.  Let
me know what is preferred.

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

[ghstack-poisoned]
@facebook-github-bot
Copy link
Contributor

facebook-github-bot commented Mar 10, 2021

💊 CI failures summary and remediations

As of commit 3c77154 (more details on the Dr. CI page):


💚 💚 Looks good so far! There are no failures yet. 💚 💚


This comment was automatically generated by Dr. CI (expand for details).Follow this link to opt-out of these comments for your Pull Requests.

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Without throwing, we can easily segfault trying to access nullptr
storage.

To do this I made set_storage_access_should_throw public so that you
don't have to subclass TensorImpl to do it.  An alternative is
to just bite the bullet and add a MetaTensorImpl subclass.  Let
me know what is preferred.

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

[ghstack-poisoned]
Copy link

@bhosmer bhosmer left a comment

Choose a reason for hiding this comment

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

This seems fine as a lightweight addition to the public API, since it can only go in the unsafe->safe direction.

Is a MetaTensorImpl inevitable and you just want to add safety in the meantime? Or are there reasons to avoid the subclass permanently?

@ezyang
Copy link
Contributor Author

ezyang commented Mar 10, 2021

Is a MetaTensorImpl inevitable and you just want to add safety in the meantime? Or are there reasons to avoid the subclass permanently?

It's not, in fact, I cannot think of any reason why I need to actually make a subclass and would prefer not to.

Without throwing, we can easily segfault trying to access nullptr
storage.

To do this I made set_storage_access_should_throw public so that you
don't have to subclass TensorImpl to do it.  An alternative is
to just bite the bullet and add a MetaTensorImpl subclass.  Let
me know what is preferred.

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Differential Revision: [D26955540](https://our.internmc.facebook.com/intern/diff/D26955540)

[ghstack-poisoned]
Without throwing, we can easily segfault trying to access nullptr
storage.

To do this I made set_storage_access_should_throw public so that you
don't have to subclass TensorImpl to do it.  An alternative is
to just bite the bullet and add a MetaTensorImpl subclass.  Let
me know what is preferred.

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Differential Revision: [D26955540](https://our.internmc.facebook.com/intern/diff/D26955540)

[ghstack-poisoned]
Without throwing, we can easily segfault trying to access nullptr
storage.

To do this I made set_storage_access_should_throw public so that you
don't have to subclass TensorImpl to do it.  An alternative is
to just bite the bullet and add a MetaTensorImpl subclass.  Let
me know what is preferred.

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Differential Revision: [D26955540](https://our.internmc.facebook.com/intern/diff/D26955540)

[ghstack-poisoned]
@facebook-github-bot
Copy link
Contributor

@ezyang merged this pull request in 5648fe6.

@facebook-github-bot facebook-github-bot deleted the gh/ezyang/937/head branch March 15, 2021 14:17
xsacha pushed a commit to xsacha/pytorch that referenced this pull request Mar 31, 2021
Summary:
Pull Request resolved: pytorch#53681

Without throwing, we can easily segfault trying to access nullptr
storage.

To do this I made set_storage_access_should_throw public so that you
don't have to subclass TensorImpl to do it.  An alternative is
to just bite the bullet and add a MetaTensorImpl subclass.  Let
me know what is preferred.

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Test Plan: Imported from OSS

Reviewed By: bhosmer

Differential Revision: D26955540

Pulled By: ezyang

fbshipit-source-id: 8ce22dd07ef1beb042f1d91de981954d59c2f84a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants