0

I normally use CFSTR() macro to create a CFString object from a standard c string until, after several test and checking better the documentation, I realized that every call to this function creates automatically a memory leak that lives until the program terminates. Visual leak detector still reports the memory as not freed even after the application close. Any call to CFRetain, CFRelease does not affect the memory at all. Since I make lots of calls, I was wondering if I should use CFStringCreateWithCString where, unlike of CFSTR, the memory is fully freed after calling CFRelease (as also reported from the memory leak detection tool).

Thanks

Update (in reply to comments): I'm on Windows and I use the official CoreFoundation library directly from my c++ application. To identify memory leaks I use OpenCfLite because the source code is the same, but allows me to also include the Visual Leak Detector header or, alternatively, to just use the built-in Visual Studio leak detector. When I close the application I get a full report and I can clearly see the memory address along with its content. I can see from report that the same strings passed to CFSTR(=__CFStringMakeConstantString) are still located at the memory address. This does not appear to be a bug or something I've done wrong, but just the normal behavior because as Apple states: "Values returned from CFSTR are not released by CFString and they are guaranteed to be valid until the program terminates."

Sample call: CFSTR("This string has been created from __CFStringMakeConstantString function")

---------------This is a dump from Microsoft builtin leak detector:-------------------

Detected memory leaks!

Dumping objects ->

c:\projects\cftest\cftest\cfbase.c(277) : {61} normal block at 0x00A01648, 96 bytes long.

Data: < GThis st> 00 00 00 00 8C 07 00 00 47 54 68 69 73 20 73 74

Object dump complete.

---------------This is a dump from VLD tool:---------------

---------- Block 1 at 0x04AD2FE8: 4096 bytes ----------

Call Stack:

0x77D89950 (File and line number not available): ntdll.dll!RtlQueryEnvironmentVariable + 0x241 bytes
0x77D8D8C9 (File and line number not available): ntdll.dll!LdrResSearchResource + 0xB4D bytes
0x77D8D78C (File and line number not available): ntdll.dll!LdrResSearchResource + 0xA10 bytes
0x77D8C4D5 (File and line number not available): ntdll.dll!LdrLoadDll + 0x7B bytes
0x772A2288 (File and line number not available): KERNELBASE.dll!LoadLibraryExW + 0x1F1 bytes
0x6FA4DF32 (File and line number not available): clr.dll!GetCLRFunction + 0x895F bytes
0x6FA4DFAD (File and line number not available): clr.dll!GetCLRFunction + 0x89DA bytes
0x6FC4ECF0 (File and line number not available): clr.dll!CorLaunchApplication + 0x17DB0 bytes
0x6F9F421B (File and line number not available): clr.dll!StrongNameSignatureVerification + 0x524C bytes
0x6F9F42E2 (File and line number not available): clr.dll!StrongNameSignatureVerification + 0x5313 bytes
0x6F9F3FE4 (File and line number not available): clr.dll!StrongNameSignatureVerification + 0x5015 bytes
0x6F9AD323 (File and line number not available): clr.dll!LogHelp_NoGuiOnAssert + 0x17457 bytes
0x6FA57D55 (File and line number not available): clr.dll!GetCLRFunction + 0x12782 bytes
0x6F9C52D5 (File and line number not available): clr.dll!LogHelp_TerminateOnAssert + 0x16F1D bytes
0x023D0882 (File and line number not available): (Module name unavailable)!(Function name unavailable)
0x00370AF3 (File and line number not available): (Module name unavailable)!(Function name unavailable)
0x6CC8CEA3 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C3A4D34 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C397BBB (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C3979B8 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C3A3B37 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C399828 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C3A285A (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C3A3A60 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C3A26D9 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C399513 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C399491 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x6C8F9B34 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
0x023D0E7B (File and line number not available): (Module name unavailable)!(Function name unavailable)
0x767262FA (File and line number not available): USER32.dll!gapfnScSendMessage + 0x332 bytes
0x76726D3A (File and line number not available): USER32.dll!GetThreadDesktop + 0xD7 bytes
0x76726DE8 (File and line number not available): USER32.dll!GetThreadDesktop + 0x185 bytes

........ GThis.st

72 69 6E 67 20 68 61 73 20 62 65 65 6E 20 63 72 ring.has .been.cr

65 61 74 65 64 20 66 72 6F 6D 20 5F 5F 43 46 53 eated.fr om.__CFS

74 72 69 6E 67 4D 61 6B 65 43 6F 6E 73 74 61 6E tringMak eConstan

74 53 74 72 69 6E 67 20 66 75 6E 63 74 69 6F 6E tString. function

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

Now, I can easily avoid all of the above issues by replacing any call to CFSTR with CFStringCreateWithCString where I'm sure that there are no memory leaks (at least as long as I remember to call CFRelease), but I would like to know why lots of code samples show an heavy use of CFSTR if every call to this function stores the string in memory which is possible to free only when the program terminates.

Thanks

user1344320
  • 31
  • 4
  • 1
    How, specifically, are you detecting leaks? – Peter Hosey Apr 21 '12 at 23:15
  • Are you using ARC?By the way CFSTR cretese a constnt string, probably in the stack... It shouldn,t count on memory allocations – Andrea Apr 22 '12 at 08:03
  • Thanks for your comment, I've just edited the question and added new details. – user1344320 Apr 22 '12 at 14:24
  • On OS X, these constant strings are embedded in the executable itself, which is why they are never deallocated. If it is the same on Windows, then you don't need to worry about it since it's not really a leak, but if they are created at runtime then you might consider switching. – ughoavgfhw Apr 22 '12 at 16:55
  • The main problem is how to understand if on Windows the strings are created at runtime or not. Since CFStringMakeConstantString function is available also in the windows version of the library, it should work in the same way, but I also think that if this function really create a true constant, the tools should not detect leaks. Instead I receive everytime a full report with address and content of the string. – user1344320 Apr 22 '12 at 17:55

1 Answers1

1

Your question is also answered here I think. If you are creating a large number of unique strings, you should use CFStringCreateWithCString and CFRelease. On the other hand, if the number of unique strings is small (say 100 or so), there is no problem using CFSTR.

Community
  • 1
  • 1
Boinst
  • 3,365
  • 2
  • 38
  • 60