2012-09-06 22 views
8

Đối với trường hợp đặc biệt này, tôi không thể loại bỏ các rò rỉ.Đối tượng giả bị rò rỉ khi sử dụng GoogleMock cùng với Boost :: Shared Pointers

Tôi nhận được thông báo của các đối tượng giả bị rò rỉ khi thực hiện kiểm tra. Thông báo cụ thể:

ClassElementFixture.h: 102: L ERI: đối tượng giả này (được sử dụng trong kiểm tra ClassElementFixture.initialize) sẽ bị xóa nhưng không bao giờ được. Địa chỉ của nó là @ 0x940a650.

Tôi đã đánh dấu dòng mà lỗi đề cập đến. Dưới đây là một phiên bản đơn giản của mã của tôi:

... 
class ClassElementFixture: public ::testing::Test 
{ 
    public: 
     boost::shared_ptr<fesa::ClassElement> classElement_; 
     boost::shared_ptr<fesa::DeviceElementMock> deviceElement_; 

     ... 

     void SetUp() 
     { 
      classElement_.reset(new fesa::ClassElement()); 
     } 

     void TearDown() 
     { 
     } 

     void initializeFake() 
     { 
      fesa::ParserElementFactoryMock factory; 
      deviceElement_.reset(new fesa::DeviceElementMock()); 

      EXPECT_CALL(factory, createDeviceElement(_)) 
         .WillOnce(Return(deviceElement1_)); 
      EXPECT_CALL(*deviceElement_, initialize(_));//Error refers to here 

      classElement_->initialize(factory); 

      EXPECT_TRUE(Mock::VerifyAndClearExpectations(deviceElement_.get())); 
     } 
} 

Tôi đã tìm thấy Why is GoogleMock leaking my shared_ptr?

tại Stack Overflow-, mà có liên quan. Tuy nhiên những gợi ý từ đó không khắc phục vấn đề của tôi: X

Khả năng duy nhất mà tôi thấy, để ít nhất ngăn chặn các lỗi là:

Mock::AllowLeak(deviceElement_.get()); 

Tuy nhiên đây không phải là một giải pháp rất sạch sẽ =)

Vậy làm cách nào để loại bỏ rò rỉ đúng cách?

+0

Tôi sử dụng google-mock v1.6.0 và google-test v1.6.0 – Alex

+5

bạn đã thử đặt lại() shared_ptrs trong 'TearDown()' chưa? –

+2

Bạn có chu kỳ trong các mối quan hệ shared_ptr của mình không? Có một vấn đề đã biết với các con trỏ được chia sẻ nơi các chu kỳ có thể dẫn đến rò rỉ. –

Trả lời

3

Nếu bạn sử dụng con trỏ thông minh, bạn vẫn cần phải có ý tưởng rõ ràng về quyền sở hữu nếu không bạn có thể có hiệu suất kém, phụ thuộc theo chu kỳ và rò rỉ bộ nhớ.

Tôi đề nghị lựa chọn con trỏ thông minh mặc định phải là unique_ptr cho quyền sở hữu duy nhất và sử dụng con trỏ thô cho người quan sát.

Nếu người quan sát có khả năng sống lâu hơn chủ sở hữu, hãy chuyển đến một số shared_ptr cho chủ sở hữu và weak_ptr cho người quan sát.

Chỉ sử dụng "được chia sẻ" shared_ptr làm phương sách cuối cùng khi bạn không có một chủ sở hữu rõ ràng và cẩn thận với các phụ thuộc theo chu kỳ.

2

Không sử dụng con trỏ được chia sẻ. Hoặc nếu bạn thực sự phải sử dụng chúng, hãy đảm bảo rằng chúng đạt tới 0 và bị phá hủy khi kết thúc thử nghiệm.

1

Đó là một câu hỏi cũ, nhưng tôi không thấy ai đề cập đến giải pháp mà tôi vừa tìm thấy.

Tôi thấy lỗi tương tự cho đến khi tôi thêm một destructor ảo vào lớp tôi đã chế nhạo. Trong trường hợp của bạn, hãy chắc chắn rằng bạn đã có một destructor ảo trên ParserElementFactoryMock. Làm cho tinh thần, như không có destructor ảo đối tượng giả sẽ không giải phóng tài nguyên của họ khi đi ra khỏi phạm vi.

Các vấn đề liên quan