Làm thế nào để bạn phát hiện / tránh rò rỉ bộ nhớ trong mã (Không được quản lý) của bạn? [đóng cửa]

Trong mã C / C ++ không được quản lý, các thực tiễn tốt nhất để phát hiện rò rỉ bộ nhớ là gì? Và hướng dẫn mã hóa để tránh? (Như thể nó đơn giản vậy;)

Chúng ta đã sử dụng một chút cách ngớ ngẩn trong quá khứ: có một bộ đếm tăng cho mỗi cuộc gọi và giảm phân bổ bộ nhớ trong khi giải phóng. Vào cuối chương trình, giá trị bộ đếm phải bằng không.

Tôi biết đây không phải là một cách tuyệt vời và có một vài lưu ý. (Ví dụ: nếu bạn đang giải phóng bộ nhớ được cấp phát bởi lệnh gọi API nền tảng, thì số phân bổ của bạn sẽ không khớp chính xác với số lượng giải phóng của bạn.

Tôi đang mong đợi kinh nghiệm, đề xuất của bạn và có thể một số tài liệu tham khảo cho các công cụ đơn giản hóa việc này.

Nếu mã C / C ++ của bạn có thể mang theo * nix, thì có vài thứ tốt hơn Valgrind .

Nếu bạn đang sử dụng Visual Studio, Microsoft cung cấp một số chức năng hữu ích để phát hiện và gỡ lỗi rò rỉ bộ nhớ.

Tôi sẽ bắt đầu với bài viết này: https://msdn.microsoft.com/en-us/l Library / x98tx3cf (v = vs.140) .aspx

Dưới đây là tóm tắt nhanh chóng của những bài viết. Đầu tiên, bao gồm các tiêu đề này:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

Sau đó, bạn cần gọi điều này khi chương trình của bạn thoát:

_CrtDumpMemoryLeaks();

Ngoài ra, nếu chương trình của bạn không thoát ra ở cùng một nơi mỗi lần, bạn có thể gọi đây khi bắt đầu chương trình:

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

Bây giờ khi chương trình thoát khỏi tất cả các phân bổ không miễn phí sẽ được in trong Cửa sổ đầu ra cùng với tệp chúng được phân bổ và xảy ra phân bổ.

Chiến lược này hoạt động cho hầu hết các chương trình. Tuy nhiên, nó trở nên khó khăn hoặc không thể trong một số trường hợp nhất định. Sử dụng các thư viện bên thứ ba thực hiện một số khởi tạo khi khởi động có thể khiến các đối tượng khác xuất hiện trong kết xuất bộ nhớ và có thể khiến việc theo dõi rò rỉ của bạn trở nên khó khăn. Ngoài ra, nếu bất kỳ lớp nào của bạn có các thành viên có cùng tên với bất kỳ thói quen cấp phát bộ nhớ nào (như malloc), các macro gỡ lỗi CRT sẽ gây ra sự cố.

Có các kỹ thuật khác được giải thích trong liên kết MSDN được tham chiếu ở trên cũng có thể được sử dụng.

Trong C ++: sử dụng RAII. Con trỏ thông minh thích std::unique_ptr, std::shared_ptr, std::weak_ptrlà bạn của bạn.

Là một Nhà phát triển C ++, đây là một số hướng dẫn đơn giản:

1. Chỉ sử dụng con trỏ khi thật cần thiết
2. Nếu bạn cần một con trỏ, hãy nhân đôi nếu SmartPulum là một khả năng
3. Sử dụng mẫu GRASP Creator .

Đối với việc phát hiện rò rỉ bộ nhớ cá nhân, tôi đã luôn sử dụng Trình phát hiện rò rỉ Visual và thấy nó rất hữu ích.

Tôi đã sử dụng DevStudio từ rất nhiều năm nay và điều đó luôn làm tôi ngạc nhiên khi có bao nhiêu lập trình viên không biết về các công cụ phân tích bộ nhớ có sẵn trong các thư viện thời gian chạy gỡ lỗi. Dưới đây là một vài liên kết để bắt đầu với:

Theo dõi các yêu cầu phân bổ heap - cụ thể là phần về số yêu cầu phân bổ duy nhất

_CrtSetDbgFlag

_CrtSetBreakAlloc

Tất nhiên, nếu bạn không sử dụng DevStudio thì điều này sẽ không đặc biệt hữu ích.

Tôi ngạc nhiên không ai nhắc đến DebugDiag cho HĐH Windows.
Nó hoạt động trên các bản dựng phát hành, và thậm chí tại trang web của khách hàng.
(Bạn chỉ cần giữ các phiên bản PDB phát hành của mình và định cấu hình DebugDiag để sử dụng máy chủ biểu tượng công khai của Microsoft)

Visual Leak dò là một công cụ rất tốt, tuy nhiên nó không hỗ trợ các cuộc gọi trên thời gian chạy của VC9 (ví dụ MSVCR90D.DLL).

Microsoft VC ++ ở chế độ gỡ lỗi hiển thị rò rỉ bộ nhớ, mặc dù nó không hiển thị nơi rò rỉ của bạn.

Nếu bạn đang sử dụng C ++ bạn luôn có thể tránh sử dụng mới một cách rõ ràng: bạn có vector, string, auto_ptr(pre C ++ 11; thay thế bởi unique_ptrtrong C ++ 11), unique_ptr(C ++ 11) và shared_ptr(C ++ 11) trong kho vũ khí của bạn.

Khi không thể tránh khỏi cái mới, hãy thử ẩn nó trong hàm tạo (và ẩn xóa trong hàm hủy); hoạt động tương tự cho các API của bên thứ 3.

Có nhiều thư viện "malloc" thay thế ngoài kia sẽ cho phép bạn gọi một chức năng ở cuối và nó sẽ cho bạn biết về tất cả các bộ nhớ không tham gia, và trong nhiều trường hợp, người đã mua (hoặc mới) nó ở vị trí đầu tiên .

Nếu bạn đang sử dụng MS VC ++, tôi hoàn toàn có thể giới thiệu công cụ miễn phí này từ bảng mã: rò rỉ của Jochen Kalmbach.

Bạn chỉ cần thêm lớp vào dự án của bạn và gọi

InitAllocCheck(ACOutput_XML)
DeInitAllocCheck()

trước và sau mã bạn muốn kiểm tra rò rỉ.

Khi bạn xây dựng và chạy mã, Jochen cung cấp một công cụ GUI gọn gàng nơi bạn có thể tải tệp .xmlleaks kết quả và điều hướng qua ngăn xếp cuộc gọi nơi mỗi rò rỉ được tạo để tìm ra dòng mã vi phạm.

PurifyPlus của Rational (hiện thuộc sở hữu của IBM) minh họa các rò rỉ theo cách tương tự, nhưng tôi thấy công cụ rò rỉ thực sự dễ sử dụng hơn, với phần thưởng của nó không tốn vài nghìn đô la!

Không bao giờ sử dụng nó cho mình, nhưng bạn bè C của tôi nói với tôi Thanh lọc .

Nếu bạn đang sử dụng Visual Studio, có thể đáng để xem Bound Checker . Nó không miễn phí, nhưng nó cực kỳ hữu ích trong việc tìm kiếm rò rỉ trong mã của tôi. Nó cũng không chỉ rò rỉ bộ nhớ, mà còn rò rỉ tài nguyên GDI, lỗi sử dụng WinAPI và các thứ khác. Nó thậm chí sẽ cho bạn thấy nơi bộ nhớ bị rò rỉ được khởi tạo, giúp việc theo dõi rò rỉ dễ dàng hơn nhiều.

Tôi nghĩ rằng không có câu trả lời dễ dàng cho câu hỏi này. Làm thế nào bạn có thể thực sự tiếp cận giải pháp này phụ thuộc vào yêu cầu của bạn. Bạn có cần một giải pháp đa nền tảng? Bạn đang sử dụng mới / xóa hoặc malloc / miễn phí (hoặc cả hai)? Bạn có thực sự đang tìm kiếm "rò rỉ" hay bạn muốn bảo vệ tốt hơn, chẳng hạn như phát hiện lỗi tràn bộ đệm (hoặc vượt mức)?

Nếu bạn đang làm việc ở phía cửa sổ, các thư viện thời gian chạy gỡ lỗi MS có một số chức năng phát hiện gỡ lỗi cơ bản và như một cách khác đã chỉ ra, có một số trình bao bọc có thể được bao gồm trong nguồn của bạn để giúp phát hiện rò rỉ. Tìm một gói có thể hoạt động với cả mới / xóa và malloc / miễn phí rõ ràng giúp bạn linh hoạt hơn.

Tôi không biết đủ về phía unix để cung cấp trợ giúp, mặc dù một lần nữa, những người khác thì có.

Nhưng ngoài việc phát hiện rò rỉ, còn có khái niệm phát hiện hỏng bộ nhớ thông qua lỗi tràn bộ đệm (hoặc vượt mức). Loại chức năng gỡ lỗi này tôi nghĩ khó khăn hơn phát hiện rò rỉ đơn giản. Kiểu hệ thống này cũng phức tạp hơn nữa nếu bạn đang làm việc với các đối tượng C ++ vì các lớp polymorhpic có thể bị xóa theo nhiều cách khác nhau gây ra sự khó khăn trong việc xác định con trỏ cơ sở thực sự đang bị xóa. Tôi biết không có hệ thống "miễn phí" tốt nào bảo vệ tốt cho việc vượt mức. chúng tôi đã viết một hệ thống (đa nền tảng) và thấy nó khá khó khăn.

Tôi muốn cung cấp một cái gì đó tôi đã sử dụng nhiều lần trong quá khứ: trình kiểm tra rò rỉ thô sơ ở mức nguồn và khá tự động. Tôi đang cho đi điều này vì ba lý do:

1. Bạn có thể thấy nó hữu ích.

2. Mặc dù đó là một chút krufty, tôi không để điều đó làm tôi bối rối.

3. Mặc dù nó được gắn với một số móc win32, nhưng nó sẽ dễ dàng giảm bớt.

Có những điều bạn phải cẩn thận khi sử dụng nó: đừng làm bất cứ điều gì cần dựa vào new mã bên dưới, hãy cẩn thận với các cảnh báo về các trường hợp có thể bỏ lỡ ở đầu rò rỉ.cpp, nhận ra rằng nếu bạn bật trên (và khắc phục mọi sự cố với) mã không xử lý ảnh, bạn có thể tạo một tệp lớn.

Thiết kế có nghĩa là cho phép bạn bật và tắt trình kiểm tra mà không cần biên dịch lại mọi thứ bao gồm tiêu đề của nó. Bao gồm rò rỉ.h nơi bạn muốn theo dõi kiểm tra và xây dựng lại một lần. Sau đó, biên dịch rò rỉ.cpp có hoặc không có LEAKCHECK # xác định và sau đó bật lại để bật và tắt. Bao gồm unleakcheck.h sẽ tắt cục bộ trong một tệp. Hai macro được cung cấp: CLEARALLOCINFO () sẽ tránh báo cáo cùng một tệp và dòng không phù hợp khi bạn duyệt mã phân bổ không bao gồm rò rỉ.h. ALLOCFENCE () chỉ bỏ một dòng trong báo cáo được tạo mà không thực hiện bất kỳ phân bổ nào.

Một lần nữa, xin vui lòng nhận ra rằng tôi đã không sử dụng điều này trong một thời gian và bạn có thể phải làm việc với nó một chút. Tôi đang thả nó vào để minh họa ý tưởng. Nếu có đủ sự quan tâm, tôi sẵn sàng làm một ví dụ, cập nhật mã trong quy trình và thay thế nội dung của URL sau bằng một cái gì đó đẹp hơn bao gồm một danh sách có màu cú pháp.

Bạn có thể tìm thấy nó ở đây: http://www.cse.ucsd.edu/~tkammeye/leakcheck.html

Đối với Linux: Hãy thử Google Perftools

Có rất nhiều công cụ thực hiện phân bổ / đếm miễn phí tương tự, ưu điểm của Goolge Perftools:

• Khá nhanh (so với valgrind: rất nhanh)
• Đi kèm với kết quả hiển thị đồ họa đẹp
• Có các khả năng hữu ích khác: cấu hình cpu, cấu hình sử dụng bộ nhớ ...

Bảo vệ tốt nhất chống rò rỉ là một cấu trúc chương trình giúp giảm thiểu việc sử dụng malloc. Điều này không chỉ tốt từ góc độ lập trình, mà còn cải thiện hiệu suất và khả năng bảo trì. Tôi không nói về việc sử dụng những thứ khác thay cho malloc, nhưng về mặt sử dụng lại các đối tượng và giữ các tab rất rõ ràng trên tất cả các đối tượng được truyền xung quanh thay vì phân bổ willy-nilly như người ta thường sử dụng trong các ngôn ngữ với người thu gom rác như Java.

Ví dụ, một chương trình tôi làm việc có một loạt các đối tượng khung biểu thị dữ liệu hình ảnh. Mỗi đối tượng khung có dữ liệu phụ, mà hàm hủy của khung giải phóng. Chương trình giữ một danh sách tất cả các khung được phân bổ và khi cần một khung mới, hãy kiểm tra danh sách các đối tượng khung không sử dụng để xem liệu nó có thể sử dụng lại khung hiện có thay vì phân bổ khung mới không. Khi tắt máy, nó chỉ lặp đi lặp lại qua danh sách, giải phóng mọi thứ.

Tôi khuyên bạn nên sử dụng Trình xác thực bộ nhớ xác thực từ phần mềm xác minh. Công cụ này đã chứng tỏ là sự trợ giúp vô giá để giúp tôi theo dõi rò rỉ bộ nhớ và cải thiện việc quản lý bộ nhớ của các ứng dụng tôi đang làm việc.

Một công cụ rất đầy đủ và nhanh chóng.

Bạn có đang đếm tất cả các khối và giải phóng bằng cách nội suy các hàm tòa nhà của chính bạn để ghi lại các cuộc gọi và sau đó chuyển cuộc gọi đến hàm thực?

Đây là cách duy nhất bạn có thể theo dõi các cuộc gọi bắt nguồn từ mã mà bạn chưa viết.

Có một cái nhìn vào trang người đàn ông cho ld.so. Hoặc ld.so.1 trên một số hệ thống.

Đồng thời Google LD_PRELOAD và bạn sẽ tìm thấy một số bài viết thú vị giải thích về kỹ thuật này trên www.itworld.com.

Ít nhất là đối với MS VC ++, thư viện C Runtime có một số chức năng mà tôi thấy hữu ích trong quá khứ. Kiểm tra trợ giúp MSDN cho các _Crt*chức năng.

Mmgr của Paul Neling là một công cụ yêu thích từ lâu của tôi. Bạn bao gồm mmgr.h trong các tệp nguồn của mình, xác định TEST_MEMORY và nó cung cấp một tệp văn bản chứa đầy các vấn đề về bộ nhớ xảy ra trong quá trình chạy ứng dụng của bạn.

Hướng dẫn mã hóa chung:

• Các tài nguyên nên được phân bổ ở cùng một "lớp" (hàm / lớp / thư viện) nơi chúng được phân bổ.
• Nếu điều này là không thể, hãy thử sử dụng một số thỏa thuận tự động (tăng con trỏ chia sẻ ...)

Các công cụ gỡ lỗi bộ nhớ đáng giá bằng vàng, nhưng trong nhiều năm qua, tôi đã phát hiện ra rằng hai ý tưởng đơn giản có thể được sử dụng để ngăn chặn hầu hết các rò rỉ bộ nhớ / tài nguyên được mã hóa ngay từ đầu.

1. Viết mã phát hành ngay sau khi viết mã mua lại cho các tài nguyên bạn muốn phân bổ. Với phương pháp này, việc "quên" khó hơn và trong một nghĩa nào đó buộc người ta phải nghiêm túc nghĩ về vòng đời của các tài nguyên được sử dụng trả trước thay vì như một bên.

2. Sử dụng trở lại càng ít càng tốt. Những gì được phân bổ chỉ nên được giải phóng ở một nơi nếu có thể. Con đường có điều kiện giữa việc mua lại tài nguyên và phát hành nên được thiết kế sao cho đơn giản và rõ ràng nhất có thể.

Ở đầu danh sách này (khi tôi đọc nó) là valgrind. Valgrind là tuyệt vời nếu bạn có thể tái tạo rò rỉ trên một hệ thống thử nghiệm. Tôi đã sử dụng nó rất thành công.

Điều gì sẽ xảy ra nếu bạn nhận thấy rằng hệ thống sản xuất bị rò rỉ ngay bây giờ và bạn không biết làm thế nào để tái tạo nó trong thử nghiệm? Một số bằng chứng về những gì sai được ghi lại trong trạng thái của hệ thống sản xuất đó và nó có thể đủ để cung cấp một cái nhìn sâu sắc về vấn đề ở đâu để bạn có thể tái tạo nó.

Đó là nơi lấy mẫu Monte Carlo vào bức tranh. Đọc bài viết trên blog của Raymond Chen, về cách người đàn ông nghèo xác định rò rỉ bộ nhớ và sau đó kiểm tra việc triển khai của tôi (giả sử Linux, chỉ được thử nghiệm trên x86 và x86-64)

http://github.com/tialaramex/leakdice/tree/master

Hoạt động trên hệ điều hành điện thoại di động Motorola, chúng tôi đã chiếm quyền thư viện phân bổ bộ nhớ để quan sát tất cả các cấp phát bộ nhớ. Nó đã giúp tìm ra rất nhiều vấn đề với việc phân bổ bộ nhớ. Vì phòng bệnh tốt hơn nên chữa bệnh, tôi khuyên bạn nên sử dụng công cụ phân tích tĩnh như Klockwork hoặc PC-Lint

Valgrind là một lựa chọn tốt cho Linux. Trong MacOS X, bạn có thể kích hoạt thư viện MallocDebug có một số tùy chọn để gỡ lỗi các vấn đề cấp phát bộ nhớ (xem trang quản lý malloc, phần "ENVIRONMENT" có các chi tiết liên quan). SDK OS X cũng bao gồm một công cụ có tên MallocDebug (thường được cài đặt trong / Nhà phát triển / Ứng dụng / Công cụ hiệu suất /) có thể giúp bạn theo dõi việc sử dụng và rò rỉ.

Phát hiện:

Gỡ lỗi CRT

Tránh:

Con trỏ thông minh, boehm GC

Một thay thế malloc, calloc và reallloc đẹp là rmdebug, nó khá đơn giản để sử dụng. Nó nhanh hơn nhiều so với valgrind, vì vậy bạn có thể kiểm tra mã của mình một cách rộng rãi. Tất nhiên nó có một số nhược điểm, một khi bạn tìm thấy rò rỉ, có lẽ bạn vẫn cần sử dụng valgrind để tìm nơi rò rỉ xuất hiện và bạn chỉ có thể kiểm tra mallocs mà bạn thực hiện trực tiếp. Nếu một lib bị rò rỉ vì bạn sử dụng sai, rmdebug sẽ không tìm thấy nó.

http://www.hexco.de/rmdebug/

Hầu hết các trình định dạng bộ nhớ làm chậm ứng dụng Windows phức tạp lớn của tôi đến mức kết quả là vô ích. Có một công cụ hoạt động tốt để tìm rò rỉ trong ứng dụng của tôi: UMDH - http://msdn.microsoft.com/en-us/l Library / ff560206% 28VS85% 29.aspx

Mtrace dường như là một tích hợp chuẩn cho linux. Các bước là:

1. thiết lập biến môi trường MALLOC_TRACE trong bash
   MALLOC_TRACE = / tmp / mtrace.dat
   export MALLOC_TRACE;
2. Thêm #include <mcheck.h> vào đầu tệp nguồn chính của bạn
3. Thêm mtrace (); khi bắt đầu chính và muntrace ();ở dưới cùng (trước câu lệnh return)
4. biên dịch chương trình của bạn với công tắc -g để biết thông tin gỡ lỗi
5. chạy chương trình của bạn
6. hiển thị thông tin rò rỉ với
   mtrace your_prog_exe_name /tmp/mtrace.dat
   (Trước tiên tôi phải cài đặt tập lệnh mtrace perl trên hệ thống fedora của mình với yum cài đặt glibc_utils   )