gtkmm/c++ 第一个 hello world 内存泄漏示例 [英] gtkmm/c++ first hello world example leaking memory

问题描述

我正在尝试学习 gtkmm，并决定暂时尝试 gtkmm 2.4，因为在 Debian 上使用 3.0 似乎非常困难.无论如何，我正在尝试的示例是这里的示例:http://developer.gnome.org/gtkmm-tutorial/2.24/sec-helloworld.html.en.它编译得很好，运行也很好，但是当我关闭它时，valgrind 报告了很多泄漏，类似这样的事情(单击一次按钮后):

I'm trying to learn gtkmm, and decided to try gtkmm 2.4 for the time being since it seems to be pretty hard to get 3.0 working on Debian. Anyway, the example I'm trying is the one here: http://developer.gnome.org/gtkmm-tutorial/2.24/sec-helloworld.html.en. It compiles fine and it runs alright aswell, but when i close it valgrind reports a lot of leaks, something along the lines of this (after clicking the button once):

==4254== Memcheck, a memory error detector
==4254== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==4254== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==4254== Command: ./bin/jmb
==4254== 
Hello World
==4254== 
==4254== HEAP SUMMARY:
==4254==     in use at exit: 942,940 bytes in 7,968 blocks
==4254==   total heap usage: 14,191 allocs, 6,223 frees, 3,272,961 bytes allocated
==4254== 
==4254== LEAK SUMMARY:
==4254==    definitely lost: 2,620 bytes in 6 blocks
==4254==    indirectly lost: 5,936 bytes in 187 blocks
==4254==      possibly lost: 358,625 bytes in 1,775 blocks
==4254==    still reachable: 575,759 bytes in 6,000 blocks
==4254==         suppressed: 0 bytes in 0 blocks
==4254== Rerun with --leak-check=full to see details of leaked memory
==4254== 
==4254== For counts of detected and suppressed errors, rerun with: -v
==4254== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 9 from 9)

如果我用 C-c 停止程序或单击关闭窗口按钮(在这种情况下，由于窗口管理器，我必须使用 Shift-Meta-C 关闭窗口)，就会发生这种情况.这是不允许您删除最后一个指针的 MySQL 连接器之类的预期行为吗?在那种情况下，似乎很多内存不被允许"删除?或者我只是错过了一些非常简单的东西?

This happens if i stop the program with C-c or click the close window button (in this case i have to use Shift-Meta-C to close the window because of the window manager). Is this the expected behaviour like MySQL's connector that doesn't allow you to delete that one last pointer? In that case it seems like a lot of memory not being "allowed" to be deleted? Or am i just missing something really simple?

为了它，这是我的代码:(将 HelloWorld 更改为测试)main.cpp:

For the sake of it here's my code: (Changed HelloWorld to Test) main.cpp:

#include "gui/Test.hpp"
#include <gtkmm/main.h>
int main(int argc, char **argv)
{
  Gtk::Main kit(argc, argv);
  Test t;
  Gtk::Main::run(t);
  return 0;
}

测试.hpp:

#pragma once

#include <gtkmm/button.h>
#include <gtkmm/window.h>

class Test
  : public Gtk::Window
{
public:
  Test();
  virtual ~Test();

protected:
  //Signal handlers:
  void on_button_clicked();

  //Member widgets:
  Gtk::Button m_button;
};

测试.cpp:

#include "Test.hpp"
#include <iostream>

Test::Test()
  : m_button("Hello World")   // creates a new button with label "Hello World".
{
  // Sets the border width of the window.
  set_border_width(10);

  // When the button receives the "clicked" signal, it will call the
  // on_button_clicked() method defined below.
  m_button.signal_clicked().connect(sigc::mem_fun(*this,
              &Test::on_button_clicked));

  // This packs the button into the Window (a container).
  add(m_button);

  // The final step is to display this newly created widget...
  m_button.show();
}

Test::~Test()
{

}

void Test::on_button_clicked()
{
  std::cout << "Hello World" << std::endl;
}

提前致谢！

推荐答案

考虑到您没有动态内存分配，泄漏不是来自您的代码.由于您在堆栈上而不是动态定义了 Test t 变量，因此当它超出范围时将被删除.那将是 main() 函数完成的时间，实际上是在整个程序完成之前.Test 类也没有任何直接动态内存分配.提到直接我的意思是直接在那个类中，而不是在它包含的属性(gtk 等)中.

The leak is not from your code, considering you have no dynamic memory allocations. Since you defined your Test t variable on the stack and not dynamically, it will be deleted when it goes out of scope. That would be when the main() function completes, which is actually before the entire program completes. Nor does the Test class have any direct dynamic memory allocations. By mentioning direct I mean directly in that class, but not in the attributes (gtk, etc) it contains.

为了证明您的 Test 实例确实被删除，您可以在析构函数中放置一个 printf .当应用程序退出时，您应该会看到输出.

To demonstrate that your Test instance is indeed being deleted, you can put a printf in the destructor. You should see the output when the application exits.

即使您动态定义/创建了 Test 实例，您也应该养成总是删除您创建的所有内容的习惯.在这种情况下，它只是内存，但它可能是更有价值的资源，如数据库连接、文件系统资源或需要在退出时执行的其他一些逻辑.

Even if you had defined/created the Test instance dynamically, you should get into the habit of always deleting everything you create. In this case its just memory, but it could be more valuable resources like DB connections, File System resources, or some other logic that needs to be executed at exit.

Valgrind 可以为您提供实际内存泄漏发生位置的堆栈跟踪，我很确定您会看到它们在 gtk 代码中.如果是这样，我会考虑提出一个错误.我不会太担心 仍然可达 内存(它实际上不是泄漏)，而是查看 肯定丢失 和 间接丢失.

Its possible for Valgrind to give you stack traces of where the actual memory leaks happen, Im pretty sure you'll see that they are in the gtk code. If so, I would consider raising a bug. I wouldnt be too concerned about the still reachable memory (its not actually a leak), but instead look into the definitely lost and indirectly lost.

这篇关于gtkmm/c++ 第一个 hello world 内存泄漏示例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！