Static linking giving warning and mem leak in debug

[mercurio7891]

Hi, I created a project in VS2010 and in debug mode, I link to
sfml-system-s-d.lib
sfml-window-s-d.lib

Code: [Select]


int main(int argc, char* args[])
{
    DETECT_MEMORY_LEAK;

    try
    {
        sf::Window App;
    }
    catch (std::exception& err)
    {
        std::cout << err.what() << "\n";
    }

    std::cin.get();

    return 0;
}


however when i compile it gives a lot of warning:

Code: [Select]


1>sfml-system-s-d.lib(Platform.obj) : warning LNK4099: PDB 'vc100.pdb' was not found with 'sfml-system-s-d.lib(Platform.obj)' or at 'C:\ Framework\Debug\vc100.pdb'; linking object as if no debug info
1>sfml-system-s-d.lib(Clock.obj) : warning LNK4099: PDB 'vc100.pdb' was not found with 'sfml-system-s-d.lib(Clock.obj)' or at 'C:\Framework\Debug\vc100.pdb'; linking object as if no debug info


but it still run fines. I guess because it can't find the symbol to load for debugging?

However when I exit the program. The CRT is detecting a number of memory leaks. I am using the _CrtDumpMemoryLeaks() along with _CrtSetDbgFlag(), to check for memory leaks.

regards

[Groogy]

First and foremost, why the try-catch statement? SFML doesn't use exceptions at all.

Also the linker warning is concerning that you are missing the debug files that are generated together with the library. From what I understand they aren't really needed. I just added the warning to be ignored.

And could you also specify whatever information you get from the memory leak detection?

[mercurio7891]

The try-catch is because I will be adding other code to it which can throw exceptions.

How do i get information about the memory leak?

[Groogy]

I don't know, I usually use Valgrind for memory leak detection. How do you know there is a memory leak? It must output something? Doesn't it output like where in the application the leaked memory was allocated and such? It must output something or else you wouldn't know that there is a memory leak.

[mercurio7891]

hmm, I am using the crt to detect memory leak in VS2010. Hence when the program quit, it will appear in the output window

Code: [Select]


'test.exe': Loaded 'C:\Windows\System32\uxtheme.dll', Symbols loaded (source information stripped).
'test.exe': Loaded 'C:\Windows\System32\nvoglv32.dll', Cannot find or open the PDB file
The thread 'Win32 Thread' (0x15f4) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1544) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1644) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1650) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1664) has exited with code 0 (0x0).
Detected memory leaks!
Dumping objects ->
{135} normal block at 0x00D07418, 20 bytes long.
 Data: < t   t   t      > 18 74 D0 00 18 74 D0 00 18 74 D0 00 CD CD CD CD
{134} normal block at 0x00D073E0, 8 bytes long.
 Data: <        > E4 80 D0 00 00 00 00 00
{133} normal block at 0x00D080D8, 384 bytes long.
 Data: <             s  > 84 83 1D 01 01 00 00 00 01 00 00 00 E0 73 D0 00
{132} normal block at 0x00581990, 4 bytes long.
 Data: <    > D8 80 D0 00
Object dump complete.
The program '[5504] test.exe: Native' has exited with code 0 (0x0).


Even when trying to break on the allocation for 135/134/132/133 nothing happens. I guess this is because it does not have the pdb files for the sfml portion.

The exact functions i am using to detect memory leaks are

Code: [Select]


_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
_CrtSetBreakAlloc(a);
_CrtDumpMemoryLeaks();


[Groogy]

That's all I could do, rest is up for Laurent to answer

[Laurent]

It's ok, don't worry about that

[mercurio7891]

I am wondering if there is any other information that i do need to provide, and whether is there something wrong with my code, which causes these memory leaks?

[Groogy]

Well Laurent probably know more about this. But you have done nothing wrong. I think it is more that the memory leak detection might misinterpret something that happens in OpenGL or the drivers? I don't know I'm just spewing out ideas.

[Laurent]

When I said "it's ok, don't worry about that" I was referring to the leak. SFML 1.6 has one but it's on purpose. It's already fixed in SFML 2.