Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by martyb on Tuesday May 02 2017, @10:08AM   Printer-friendly
from the bug++ dept.

Submitted via IRC for TheMightyBuzzard to let us know that a serious bug in GCC.

This post is to inform you about a bug in GCC that may cause memory (or other resource) leaks in your valid C++ programs.

One of the pillars of C++ philosophy is what we often call RAII [Resource Acquisition Is Initialization]: if you use classes to manage resources, use constructors for allocating resources and destructors for releasing them, the language makes sure that whatever happens, however you use such classes the resources will get properly released.

[...] This is the contract: I take care that my classes correctly manage resources, and the language takes care that the resources will always be managed correctly regardless of the complexity of the program.

This is where the bug manifests. Member r1 is initialized but never destroyed. Admittedly, this is a rare case: it requires an exception in the middle of initialization, a temporary and an aggregate initialization. But usually, leaks manifest in the face of exceptions. And the fact that it is rare makes you less prepared for it.

Here is a full example:

#include <cstdio>
#include <stdexcept>

struct Resource
{
  explicit Resource(int) { std::puts("create"); }
  Resource(Resource const&) { std::puts("create"); }
  ~Resource() { std::puts("destroy"); }
};

Resource make_1() { return Resource(1); }
Resource make_2() { throw std::runtime_error("failed"); }

struct User
{
  Resource r1;
  Resource r2;
};

void process (User) {}

int main()
{
  try {
    process({make_1(), make_2()});
  }
  catch (...) {}
}

You can test it online here. It is present in GCC 4, 5, and 6. For a more real-life, and somewhat longer, illustration of the problem, see this example provided by Tomasz KamiƄski.

Interesting but thankfully not my worry at the moment as I'm on a Learn Rust kick and my problem areas of SN are all perl.

Source: https://akrzemi1.wordpress.com/2017/04/27/a-serious-bug-in-gcc/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Tuesday May 02 2017, @12:44PM (2 children)

    by Anonymous Coward on Tuesday May 02 2017, @12:44PM (#502768)

    Compiler has bug. News at 11.

    Seriously, I'm pretty sure you can find a bug in about any compiler for about any language (unless you go the way of "this compiler defines the language, and thus it has no bugs by definition"). And yes, the bugs will usually be rarely triggered because if they weren't triggered only rarely, they likely would already be found and fixed.

    And I certainly prefer bugs causing memory leaks to bugs causing wrong results.

  • (Score: 2) by JoeMerchant on Tuesday May 02 2017, @03:35PM (1 child)

    by JoeMerchant (3937) on Tuesday May 02 2017, @03:35PM (#502894)

    Putting this bug on the compiler seems a little bit of a stretch. I mean, yes, the compiler _should_ handle it, but the example code would have to stretch pretty far to find real-world examples where it is necessary to fail a try-catch in an initialization...

    Personally, I dislike try-catch intensely - they feel like a worse version of goto to me.

    --
    🌻🌻 [google.com]
    • (Score: 2) by Wootery on Wednesday May 03 2017, @08:19AM

      by Wootery (2341) on Wednesday May 03 2017, @08:19AM (#503525)

      It's not a stretch though, because C++ is clear about its RAII rules, and this deviates from what's required.

      On the topic of exceptions' shortfalls, you may enjoy this [joelonsoftware.com] and the various other blog posts it links to. You're not alone thinking that exceptions often make for gnarly non-obvious control-flows.