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

Fixed leaking compiler->initializer #365

Closed
wants to merge 1 commit into from
Closed

Fixed leaking compiler->initializer #365

wants to merge 1 commit into from

Conversation

Jasper-Bekkers
Copy link

#356

Fixes a big part of that issue.

Someone still needs to fix the leak for InitializeMemoryPools().

@googlebot
Copy link
Collaborator

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.


  • If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
  • If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
  • In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

@Jasper-Bekkers
Copy link
Author

I signed it!

@googlebot
Copy link
Collaborator

CLAs look good, thanks!

@dneto0
Copy link
Collaborator

dneto0 commented Sep 6, 2017

I'd like @AWoloszyn to review this. He designed the original mechanism.

@dneto0
Copy link
Collaborator

dneto0 commented Sep 6, 2017

Oh, wait. I think this completely breaks the protection scheme that GlslangInitializer is supposed to be implementing. Different compiler objects can end up destroying Glslang's internal state while a different compiler instance is still using it.
See the TODO comment at GlslangInitializer's definition.

@@ -449,14 +449,17 @@ void shaderc_compile_options_set_hlsl_register_set_and_binding(
}

shaderc_compiler_t shaderc_compiler_initialize() {
static shaderc_util::GlslangInitializer* initializer =
shaderc_util::GlslangInitializer* initializer =
Copy link
Contributor

@AWoloszyn AWoloszyn Sep 12, 2017

Choose a reason for hiding this comment

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

This will unfortunately fail in the case where you have 2 instances of the compiler at once.
I absolutely understand and agree with what you want to do, and why.

I think the right solution here would be to have the GlslangInitializer be basically a static refcount. In shaderc_compiler_release we decrement the refcount, and clear the state.

There would need to be a bit of extra locking but I think it should work in the general case.

@dneto0
Copy link
Collaborator

dneto0 commented Feb 7, 2018

Closing.
#356 is already on file to address memory leaks.

@dneto0 dneto0 closed this Feb 7, 2018
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

Successfully merging this pull request may close these issues.

4 participants