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: 2) by turgid on Tuesday May 02 2017, @03:19PM (2 children)

    by turgid (4318) Subscriber Badge on Tuesday May 02 2017, @03:19PM (#502876) Journal

    C
    (Filter error: Comment too short.)

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by tangomargarine on Tuesday May 02 2017, @03:52PM (1 child)

    by tangomargarine (667) on Tuesday May 02 2017, @03:52PM (#502908)

    Pretty heavily depends on what sort of project you're working on. I get the impression C is a pretty big pain for anything not involving hardware or heavy math stuff like graphics.

    --
    "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
    • (Score: 2) by Zyx Abacab on Tuesday May 02 2017, @11:01PM

      by Zyx Abacab (3701) on Tuesday May 02 2017, @11:01PM (#503257)

      It is. C is rarely a good choice for user-facing, event-driven software. For example: C only works for GUI applications; even with a big framework like GTK+, it takes a hell of a lot of hair-pulling to get it done.

      Something like C++ with Qt is a much better alternative, as long as you're writing modern C++. That said, old C++ (using standards from circa 1999-2003) is nothing short of an embarrassment. (You'd be better off writing C# and using .NET at that point.)

      This is not a disparagement—C is a fine language for many things—but, for the love of god, use the right tool for the job.