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

Move jpeg_finish_compress out of destructor #433

Merged
merged 2 commits into from
Feb 19, 2020

Conversation

simmplecoder
Copy link
Contributor

@simmplecoder simmplecoder commented Feb 14, 2020

Description

This pull request removes the jpeg_finish_compress call from destructor, which will ensure no erroring function can be called when an exception is in flight or the destructor can fail. If we would throw out of destructor some time in the future, we will have to put noexcept(false), as destructors are noexcept by default.

Thanks a lot to @misos1 for having productive discussion about the setjmp and longjmp in the original issue.

References

#416

Tasklist

  • Add test case(s) - not applicable ?
  • Ensure all CI builds pass
  • Review and approve

Moving the function out will ensure
that no function that can error will
be called inside a destructor, thus
leaving no chance to get two exceptions
in flight or finishing compression even
if an error occured
@simmplecoder
Copy link
Contributor Author

I've lurked around and haven't spotted resource leak. Could anyone please confirm this? This commit should deal with both undefined behavior, termination and resource leakage if that's right.

Copy link
Member

@mloskot mloskot left a comment

Choose a reason for hiding this comment

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

LGTM!

I think it is a good idea to add comment in ~writer_backend(), something like:

// JPEG compression object destruction does not signal errors,
// unlike jpeg_finish_compress called elsewhere,
// so there is no need for the setjmp bookmark here.
jpeg_destroy_compress(get());

This should help a suspicious reader to avoid an urge to patch it :)

include/boost/gil/extension/io/jpeg/detail/write.hpp Outdated Show resolved Hide resolved
Added comments to explain why finish
compress was moved out of destructor,
and did stylistical changes
@simmplecoder
Copy link
Contributor Author

@mloskot , thanks! I did as you mentioned, and I believe the setjmp/longjmp issues are at least not that critical now. There might be resource leaks somewhere, but otherwise no undefined behavior should occur if the C library underneath errored out.

Copy link
Member

@mloskot mloskot left a comment

Choose a reason for hiding this comment

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

Thanks. Many thanks to @misos1 for his involvement and help

@mloskot mloskot requested review from stefanseefeld and removed request for stefanseefeld February 15, 2020 16:55
@simmplecoder simmplecoder merged commit e684f96 into boostorg:develop Feb 19, 2020
@mloskot mloskot added this to the Boost 1.73 milestone Feb 19, 2020
@mloskot mloskot added cat/bug But reports and bug fixes ext/io boost/gil/extension/io/ labels Feb 19, 2020
@mloskot
Copy link
Member

mloskot commented Feb 19, 2020

Awesome. Thanks again @simmplecoder & @misos1 for your efforts.

@simmplecoder simmplecoder linked an issue Feb 26, 2020 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cat/bug But reports and bug fixes ext/io boost/gil/extension/io/
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JPEG I/O calls jpeg_ functions without proper setjmp
2 participants