0

I suspect I have some memory leaks problem so I defined two functions that I can call from the immediate window while stepping through my code:

_CrtMemState s1;

void SetMemCheckPoint() {
    _CrtMemCheckpoint(&s1);
}

void CompareMemory() {
    _CrtMemDumpAllObjectsSince(&s1);
}

Then I have this line somewhere:

buf = (char*)realloc(buf, (strlen(src)+1)*sizeof(char)); //yes I'm aware sizeof(char) = 1
//Don't worry, after this, if (!buf) I fast fail and exit(-1)

Just before stepping through this line, calling SetMemCheckPoint() then CompareMemory() in the immediate window reports no new allocations (as it obviously should).

Then, just after stepping through this line, calling CompareMemory() in the immediate window reports this:

Dumping objects ->
{6886} normal block at 0x19941B90, 58 bytes long.
 Data: <C:\Users\XXXXXXX> 43 3A 5C 55 73 65 72 73 5C XX XX XX XX XX XX XX
{3974} client block at 0x1921D600, subtype 0, 10 bytes long.
 Data: <% /m K    > 25 00 2F 6D 00 4B 00 CD CD CD 
{3807} client block at 0x05D45800, subtype 0, 16 bytes long.
 Data: <r               > 72 0B CB 00 CD CD CD CD CD CD CD CD CD CD CD CD

[... 700 more allocations ...]

{153} client block at 0x05D5BF90, subtype 0, 11 bytes long.
 Data: <log.log    > 6C 6F 67 2E 6C 6F 67 00 CD CD CD 
{152} client block at 0x05BD5C00, subtype 0, 48 bytes long.
 Data: <                > 90 BF D5 05 08 00 00 00 0B 00 00 00 CD CD CD CD 
{151} client block at 0x05C5B210, subtype 0, 32 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 E8 03 00 00 00 00 00 00 
Object dump complete.

All these allocations seems to be memory allocated before calling SetMemCheckPoint().

Is MS crt realloc() somehow messing with the (MS) crt debug heap and corrupting my checkpoint s1?

Or am I missing something ?

edit

This code is in a dll called from Excel macros (vba). Maybe there are some strange interactions between Excel and my debug-compiled dll (that is itself dynamically linked to msvcr120d.dll).

Also, the realloc call does return a new pointer, but subsequent calls seem to "cycle" between a few addresses. I am wondering if this causes _CrtMemDumpAllObjectsSince to see this "new" pointer as an "old" allocation, and then dump all allocations since this "old" one ?

I can't reproduce it in a minimal program :( It seems it has something to do with interactions between my dll and Excel/3rd party code indeed...

ThreeStarProgrammer57
  • 2,906
  • 2
  • 16
  • 24
  • seeing the rest of the code would greatly help the debug process. However, when calling realloc() always 1) place the result in a temp pointer then check that temp pointer (!=NULL) before copying the temp pointer to 'buf'. Not using a temp pointer will result in the original pointer being set to NULL, resulting in a memory leak as the original pointer would be overlayed by 'NULL' – user3629249 May 28 '15 at 03:40
  • these 'leaks' seem to be just all the allocations in the 'heap' and are not actually memory leaks – user3629249 May 28 '15 at 03:43
  • @user3629249 Yes, these are allocations, but they should not appear after when calling `_CrtMemDumpAllObjectsSince` with a recent memory check point. I suspect I have leaks because of the process growing memory usage. – ThreeStarProgrammer57 May 28 '15 at 09:02
  • @user3629249 I'm aware of the proper usage of temp pointer for storing `realloc` result. I just "fast fail" (report error and terminate) in case of `realloc` returning NULL (see my comment just below the realloc call), because *for the moment* my code can't deal with allocation failures, it just "fast fail". – ThreeStarProgrammer57 May 28 '15 at 09:39
  • Do you call `CompareMemory` twice? Though it seems to be valid, I would try to remove the first call. – Alex F May 28 '15 at 09:41
  • @AlexFarber I get the same result if I don't `CompareMemory()` before stepping. Note that `CompareMemory()` is just a call to `_CrtMemDumpAllObjectsSince` so it should not have side effects. – ThreeStarProgrammer57 May 28 '15 at 09:47
  • @user3629249 I reworded "leaks" to "allocations" to avoid confusions. Also, the rest of the code is quite long, and I didn't manage to reproduce this in a small program :( – ThreeStarProgrammer57 May 28 '15 at 09:49
  • Any chance of multithreading issues? Also, is _CRTDBG_MAP_ALLOC defined? It may help to see a better leaks report. – Alex F May 28 '15 at 10:00

0 Answers0