2017-05-16 8 views
0

Windows 7 64 비트 버전에서 SFML 2.4.2로 작업하면 sf::Text::setOutlineThickness(float)과 관련된 문제점을 발견했습니다. 기본값 0을 제외하고 프로그램에서이 코드가 사용되면 crtdbg는 다양한 크기의 메모리 누수를 덤프하지만 항상 동일한 양을 덤프합니다. 나는 텍스트가 그려 도착하면이 문자열의 크기와 관련이 믿고, if the parameter of setOutlineThickness is accepted 여기 시연 :sf :: Text :: setOutlineThickness가 사용될 때 crtdbg가 메모리 누수를 덤프합니다.

{8601} normal block at 0x0000000005CA5C90, 60 bytes long. 
Data: <    > 03 00 07 00 0B 00 0F 00 13 00 17 00 1B 00 1F 00 
{8600} normal block at 0x0000000005E03A20, 120 bytes long. 
Data: <    > 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 
{8599} normal block at 0x0000000005E2A680, 960 bytes long. 
Data: <    > 00 00 00 00 80 07 00 00 0D 01 00 00 80 07 00 00 
{8598} normal block at 0x0000000005CA36B0, 72 bytes long. 
Data: <  h  > F0 1A 9D 05 00 00 00 00 68 AE 83 DB FE 07 00 00 

test.setString("B"); 경우, 여전히 네있다 : 이것은 누수를 생산

/// Initial set-up 
sf::Text test; 
test.setString("A"); 
// ... Set charactersize, font, fillcolor, etc ... 
test.setOutlineThickness(1); 
test.setOutlineColor(sf::Color::Black); 

/// Make a drawcall for test later in the program 
void Game::draw(sf::RenderTarget & target, sf::RenderStates states) const 
{ 
    target.draw(test, states); 
} 

문자열이 다른 문자를 사용하기 때문에 바이트 크기가 다릅니다.
68 바이트, 136 바이트, 1088 바이트, 72 바이트.
마지막으로 test.setString("AB"); 경우, 예상 크기 8 개 블록이 있습니다 : 내가 사용하는

{8667} normal block at 0x0000000005C35D10, 68 bytes long. 
Data: <    > 03 00 07 00 0B 00 0F 00 13 00 17 00 1B 00 1F 00 
{8666} normal block at 0x0000000005C61310, 136 bytes long. 
Data: <    > 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 
{8665} normal block at 0x000000000325CDE0, 1088 bytes long. 
Data: <    > 00 00 00 00 80 07 00 00 0D 01 00 00 80 07 00 00 
{8664} normal block at 0x0000000005C340D0, 72 bytes long. 
Data: <  h  > F0 1A 96 05 00 00 00 00 68 AE B5 DB FE 07 00 00 
{8601} normal block at 0x0000000005C35C90, 60 bytes long. 
Data: <    > 03 00 07 00 0B 00 0F 00 13 00 17 00 1B 00 1F 00 
{8600} normal block at 0x0000000005D93A20, 120 bytes long. 
Data: <    > 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 
{8599} normal block at 0x0000000005DBA680, 960 bytes long. 
Data: <    > 00 00 00 00 80 07 00 00 0D 01 00 00 80 07 00 00 
{8598} normal block at 0x0000000005C336B0, 72 bytes long. 
Data: <  h  > F0 1A 96 05 00 00 00 00 68 AE B5 DB FE 07 00 00 
  • 는 김포 :: 클래스와 파괴해야하지만이 보이지 않는 클래스의 private 멤버로 텍스트 그럴 수 있습니다. 내가 뭘 놓치고 있니?
  • 나는 _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);을 사용합니다. 이것이 거짓 긍정입니까?
  • 기능을 보니 sf::Text::setOutlineThickness, 여기에는 문제가 없습니다. A brief documentation.
  • 문자열의 크기에 따라 다른 누설이 실제로 증상의 더 많은 것입니다. 윤곽선 두께에 대한 drawcall 및 기본값이 아닌 값입니다. 그렇게,

    FT_Glyph_Stroke(&glyphDesc, stroker, false); 
    

    그러나 FT_Glyph_Stroke의 다큐에 따르면, 실제로이 있어야한다 : SFML에서 실제 누출이 같은

+0

'sf :: Text :: draw()'는 외곽선 두께가 아닌 경우 약간 다른 동작을합니다. -zero :'if (m_outlineThickness! = 0) target.draw (m_outlineVertices, states);'. 또한,'sf :: Text :: ensureGeometryUpdate()'는 외곽선 두께가 0이 아니라면 조건부 코드를 가지고 있습니다. 나는 그 지역들을 볼 것이다. –

답변

1

그것은 다음과 같습니다 Font.cpp#L561

에서 보이는 원본 글립 문자가 소멸됩니다 :

FT_Glyph_Stroke(&glyphDesc, stroker, true); 
+0

당신이 옳은 것처럼 보입니다! SFML에 대한 새로운 바이너리 작업. 테스트 한 것은 더 이상 메모리 누수가 없다는 것을 나타냅니다. SFML 팀이이를 확인하자마자이를 응답으로 표시하겠습니다. Font.cpp를 보게 된 동기는 무엇입니까? – Chringo

+1

@Chringo, 나는 자신의 메모리 누수 탐지 도구 [heob] (https://github.com/ssbssa/heob)를 사용했는데,'FT_Get_Glyph()'의 호출에서'glyphDesc'가 절대로 해제되지 않았 음을 보여주었습니다. 나머지는 디버깅으로 알아 냈습니다. – ssbssa