EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Memory Leak in NotifyDirectoryChange

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
Posted: 10/07/2013 11:31:54
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

In version of the Callback File System I have found evidence of a 16 byte memory leak in the NotifyDirectoryChange API. Below is the call stack trace after trapping the memory allocation using _CrtBreakAlloc.

msvcr80d.dll!_heap_alloc_dbg(unsigned int nSize=16, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0) Line 371 C++
msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=16, int nhFlag=0, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0) Line 268 + 0x15 bytes C++
msvcr80d.dll!malloc(unsigned int nSize=16) Line 154 + 0x15 bytes C++
vdiskService.exe!_AsyncCallAdd() + 0xe bytes C
vdiskService.exe!_CbFsNotifyChangeFileOutside@16() + 0x94 bytes C
> vdiskService.exe!CallbackFileSystem::NotifyDirectoryChange() + 0x1f bytes C++

vdiskService.exe!CbFsWriteFile(CallbackFileSystem * Sender=0x01632ed8, CbFsFileInfo * FileInfo=0x0173e850, void * FileHandleContext=0x01633800, __int64 Position=0, void * Buffer=0x00860000, unsigned long BytesToWrite=35, unsigned long * BytesWritten=0x0263ff40) Line 2286 + 0x22 bytes C++

I cannot see the code obviously, although now that I think about it I do have the source code, but it would probably be easier for you guys who know the code intimately to search it out. The size of the allocated memory block is 16 bytes. Do you know off the top of your head whether that API allocates a 16 byte block of memory that it never frees?
Posted: 10/07/2013 12:10:13
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

OK, I looked at your source code and I think the culprit is in a bunch of routines that start with CbFsNotifyChangeFileOutside. That function calls AsyncCallAdd, which allocates a 16 byte memory structure called an "AsyncCallItem" which it places on a doubly linked list called the "AsyncCallGlobal.List". I could not find anywhere in the code where that item is freed, except in the case where the AsynCallAdd function fails, which in my case does not happen. Is this the memory leak I am seeing? Or have I interpreted all this incorrectly? More importantly, why am I suddenly seeing this memory leak when I didn't change anything in my code having to do with the NotifyDirectoryChange API? I still call that API from the same places that I have always called it, nothing I changed recently would affect that, so I am a bit puzzled why this memory leak has suddenly appeared, unless it was always there and I just never noticed it before, but that is unlikely, since I run the code under the debugger often and I can remember many cases where the debugger didn't show me memory leaks at all.
Posted: 10/08/2013 02:44:17
by Volodymyr Zinin (Team)

Hello Sid,

Thank you for it. The problem really exists and occurs if the NotifyDirectoryChange API is called inside the CallbackFS callbacks. And it seems the problem has always been present. We will fix it in the next build, but now you can correct it yourself by modifying the AsyncCallWorkerThread function in the following way:
AsyncCallWorkerThread (
    IN LPVOID ThreadParameter
    AsyncCallItem = CONTAINING_RECORD(ListEntry, ASYNC_CALL_ITEM, Next);
    free(AsyncCallItem);   <======= add this ========
Posted: 10/08/2013 09:05:19
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Thank you, Vladimir.



Topic viewed 933 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!