gtkmm/C++ bộ nhớ rò rỉ ví dụ thế giới đầu tiên

Question

Tôi đang cố gắng tìm hiểu gtkmm và quyết định thử gtkmm 2.4 trong thời gian này vì có vẻ như rất khó để có được 3.0 làm việc trên Debian. Dù sao, ví dụ tôi đang cố gắng là một ở đây: http://developer.gnome.org/gtkmm-tutorial/2.24/sec-helloworld.html.en. Nó biên dịch tốt và nó chạy là tốt không sao, nhưng khi tôi đóng nó valgrind báo cáo rất nhiều rò rỉ, một cái gì đó dọc theo dòng này (sau khi nhấp vào nút một lần):

==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) 

Điều này xảy ra nếu tôi dừng lại chương trình với Cc hoặc nhấp vào nút đóng cửa sổ (trong trường hợp này tôi phải sử dụng Shift-Meta-C để đóng cửa sổ vì trình quản lý cửa sổ). Đây có phải là hành vi mong đợi như trình kết nối của MySQL không cho phép bạn xóa một con trỏ cuối cùng không? Trong trường hợp đó, có vẻ như rất nhiều bộ nhớ không bị "cho phép" xóa? Hoặc tôi chỉ thiếu một cái gì đó thực sự đơn giản?

Vì lợi ích của nó ở đây là mã của tôi: (Thay đổi HelloWorld để 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; 
} 

Test.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; 
}; 

Test.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; 
} 

Cảm ơn trước!

Answer 1

Sự rò rỉ không phải từ mã của bạn, vì bạn không có phân bổ bộ nhớ động. Vì bạn đã xác định biến số Test t trên ngăn xếp và không tự động, nó sẽ bị xóa khi nó nằm ngoài phạm vi. Điều đó sẽ xảy ra khi hàm main() hoàn thành, trước khi toàn bộ chương trình hoàn thành. Lớp Kiểm tra cũng không có bất kỳ phân bổ bộ nhớ động nào trực tiếp. Bằng cách đề cập trực tiếp, tôi có nghĩa là trực tiếp trong lớp đó, nhưng không có trong thuộc tính (gtk, vv) nó chứa.

Để chứng minh rằng trường hợp Kiểm tra của bạn thực sự bị xóa, bạn có thể đặt printf vào trình hủy. Bạn sẽ thấy đầu ra khi ứng dụng thoát.

Thậm chí nếu bạn đã định nghĩa/tạo Test dụ tự động, bạn sẽ nhận được vào các thói quen của luôn xóa tất cả mọi thứ bạn tạo ra. Trong trường hợp này chỉ là bộ nhớ của nó, nhưng nó có thể là tài nguyên có giá trị hơn như kết nối DB, tài nguyên Hệ thống tệp hoặc một số logic khác cần được thực hiện khi thoát.

Có thể cho Valgrind cung cấp cho bạn dấu vết ngăn xếp nơi rò rỉ bộ nhớ thực sự xảy ra, Im khá chắc chắn bạn sẽ thấy rằng chúng đang ở trong mã gtk. Nếu vậy, tôi sẽ xem xét việc nuôi một con bọ. Tôi sẽ không quá lo lắng về bộ nhớ still reachable (nó không thực sự là một rò rỉ), nhưng thay vì nhìn vào definitely lost và indirectly lost.

Answer 2

Đặt biến môi trường G_SLICE để định cấu hình lại bộ cấp phát bộ nhớ GSlice.

G_SLICE=always-malloc ./your_application 

Nhìn vào this post để biết chi tiết.

Answer 3

Giả sử Gtk-- không bị rò rỉ bộ nhớ, kết quả bạn đăng có thể tương thích với giả định này.

Thực tế là một số bộ nhớ vẫn có thể truy cập được khi thoát khỏi chương trình không giống như rò rỉ bộ nhớ.

Chương trình sau có bị rò rỉ bộ nhớ không?

int main() { 
    int* a = new int[10]; 
    return 0; 
} 

Có vẻ như vậy, nhưng câu trả lời hoàn chỉnh phải là: Phụ thuộc!

Nếu chúng ta không sử dụng MS/DOS và "a" là cần thiết cho đến cuối chương trình, điều này khó có thể xác định rò rỉ ... chúng ta có thể nói rằng lập trình viên có trách nhiệm dọn dẹp hệ điều hành cơ bản.

Hơn nữa Valgrind là một công cụ rất tốt và hữu ích, nhưng có thể báo cáo dương tính giả.