Làm thế nào để theo dõi rò rỉ bộ nhớ khó khăn với fastMM?

Question

Sau khi nâng cấp một dự án từ năm 2007 đến Delphi Delphi 2009 tôi nhận được một rò rỉ bộ nhớ Unknown, cho đến nay tôi đã tryin để theo dõi nó xuống bằng fastMM, đây là những gì fastMM vết đống báo cáo:

A memory block has been leaked. The size is: 20 

This block was allocated by thread 0x111C, and the stack trace (return addresses) 
    at the time was: 
40339E [System.pas][System][@GetMem][3412] 534873 [crtl][_malloc] 
56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918] 
56D316 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3961] 
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085] 
562D48 [DBCommon.pas][DBCommon][TFilterExpr.PutExprNode][1583] 
408E46 [System.pas][System][DynArraySetLength][20464] 
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085] 
408E92 [System.pas][System][@DynArraySetLength][20486] 
528C1B [Forms.pas][Forms][TCustomForm.DoCreate][3260] 
171A1A [GetRawStackTrace] 

The block is currently used for an object of class: Unknown 

The allocation number is: 302844 

Và đôi khi tôi nhận được điều này:

A memory block has been leaked. The size is: 20 

This block was allocated by thread 0x111C, and the stack trace (return addresses) 
    at the time was: 
40339E [System.pas][System][@GetMem][3412] 
534873 [crtl][_malloc] 
56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918] 
56D316 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3961] 
77DC921A [RtlAnsiStringToUnicodeString] 
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085] 
7726B8F5 [GetProcAddress] 
7726B907 [GetProcAddress] 
589B1E [ossrv.cpp][MidasLib][DllGetDataSnapClassObject][3163] 
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085] 
408E92 [System.pas][System][@DynArraySetLength][20486] 

The block is currently used for an object of class: Unknown 

Có cách nào tốt hơn để tìm hiểu điều gì thực sự gây ra rò rỉ bộ nhớ?

Answer 1

rò rỉ bộ nhớ này đã được gây ra bởi một lỗi Delphi, QC #67709

Nó đã được cố định bởi người cuối cùng Delphi 2009 cập nhật, không có thắc mắc tôi đã không thể sửa chữa nó.

Answer 2

IIRC VCL có một vài rò rỉ rất nhỏ như thế này mà bạn có thể bỏ qua mà không phải lo lắng nhiều. Đây có thể là một trong số họ !? Hy vọng ai đó làm rõ điểm này.

Answer 3

Tôi không biết nếu có bất kỳ rò rỉ trong D2009 VCL, vì vậy giả sử rò rỉ là trong mã của bạn, đầu tiên tôi sẽ kiểm tra sau:

• có bất kỳ mảng hoặc danh sách (vì @DynArraySetLength) tạo trong hình thức đó không được phát hành khi bạn vứt bỏ mẫu đơn.
• là có bất kỳ chức năng nào tạo và trả về một số đối tượng cần được người gọi bên ngoài giải phóng và nếu bạn có chức năng kiểm tra đó nếu người gọi giải phóng đối tượng đó.
• nếu điều này không tiết lộ rò rỉ, thì bạn nên kiểm tra xem mỗi đối tượng mà bạn tạo trong mã biểu mẫu của bạn, sẽ bị hủy khi bạn hủy biểu mẫu.

Answer 4

Miễn là kích thước của khối bộ nhớ bị rò rỉ không phát triển được lâu hơn/nhiều hơn chương trình của bạn được sử dụng, thì đó không phải là mối quan tâm. Nếu bạn có các đối tượng sống lâu chỉ được giải phóng khi bạn chấm dứt ứng dụng, nó giống như khi bạn rò rỉ chúng - tất cả bộ nhớ được khai hoang khi chấm dứt (Trừ khi tất nhiên chúng có xử lý tài nguyên ngoài bộ nhớ).

Rò rỉ bộ nhớ mà bạn muốn quan tâm là những dữ liệu tích lũy theo thời gian hoặc cách sử dụng. Nếu nó là 20 byte mọi lúc thì đừng đổ mồ hôi nó.

Answer 5

Tôi sẽ nói rằng bạn có điều gì đó xảy ra trong trình xử lý sự kiện Form OnCreate đang phát triển DynArray.
Và DynArray không được phát hành ở cuối.
Nhưng không thấy mã và thực sự gỡ lỗi bằng FastMM, gần như không thể đoán được điều gì đang thực sự xảy ra.

Answer 6

Lần cuối cùng tôi gặp sự cố khó hiểu dọc theo những dòng này, tôi đã xem bộ nhớ thô của đối tượng vi phạm - và thấy văn bản cho tôi biết loại dữ liệu đó là gì. Khi nó nói nó không biết loại đối tượng nào có thể có nghĩa là nó không phải là một đối tượng ở nơi đầu tiên - vì vậy hãy nhìn vào những thứ được phân bổ động, bao gồm cả các chuỗi.