{"id":245,"date":"2008-09-26T12:59:21","date_gmt":"2008-09-26T16:59:21","guid":{"rendered":"http:\/\/benjamin.smedbergs.us\/blog\/?p=245"},"modified":"2008-09-26T12:04:34","modified_gmt":"2008-09-26T16:04:34","slug":"allocated-memory-and-shared-library-boundaries","status":"publish","type":"post","link":"https:\/\/benjamin.smedbergs.us\/blog\/2008-09-26\/allocated-memory-and-shared-library-boundaries\/","title":{"rendered":"Allocated Memory and Shared Library Boundaries"},"content":{"rendered":"

When people get started with XPCOM, one of the most confusing rules is how to pass data across XPCOM boundaries. Take the following method:<\/p>\n

IDL markup<\/h4>\n
string getFoo();<\/pre>\n
C++ generated method signature<\/h4>\n
nsresult GetFoo(char **aResult);<\/pre>\n
\"Diagram<\/p>\n
C++ Implementation<\/h4>\n
The aResult<\/code> parameter is called an “out parameter”. The implementation of this method is responsible for allocating memory and setting *aResult:<\/p>\n
nsresult\r\nObject::GetFoo(char **aResult)\r\n{\r\n  \/\/ Allocate a string to pass back\r\n  *aResult = NS_Alloc(4);\r\n\r\n  \/\/ In real life, check for out-of-memory!\r\n  strcpy(*aResult, \u00e2\u20ac\u0153foo\u00e2\u20ac\u009d);\r\n\r\n  return NS_OK;\r\n}<\/pre>\n
C++ Caller<\/h4>\n
The caller, after it is finished with the data, is responsible for freeing the data.<\/p>\n
char *foo;\r\nmyIFace->GetFoo(&foo);\r\n\/\/ do something with foo\r\nNS_Free(foo);<\/pre>\n
The important thing to note is that the code doesn’t allocate memory with malloc<\/code>, and doesn’t free it with free<\/code>. All memory that is passed across XPCOM boundaries must be allocated with NS_Alloc<\/code><\/a> and freed with NS_Free<\/code><\/a>.<\/p>\n
We have this rule because of mismatched allocators<\/em>. Depending on your operating system and the position of the moon, each shared library may have its own malloc heap. If you malloc<\/code> memory in one shared library and free<\/code> it in a different library, the heap of each library may get corrupted and cause mysterious crashes. By forcing everyone to use the NS_Alloc\/Free functions, we know that all code is using the same malloc heap.<\/p>\n
Helper Functions<\/h2>\n
In most cases, there are helper functions which make following the rules much easier. On the implementation side, the ToNewUnicode and ToNewCString functions convert an existing nsAString\/nsACString<\/a> to an allocated raw buffer.<\/p>\n
On the caller side, you should almost always use helper classes such as nsXPIDLString to automatically handle these memory issues:<\/p>\n
Better C++ Caller<\/h4>\n
nsXPIDLCString foo;\r\nmyIFace->GetFoo(getter_Copies(foo));\r\n\/\/ do something with foo<\/pre>\n
Impact on Extension Authors<\/h2>\n
It is especially important for extension authors to follow this advice on Windows. The Windows version of Firefox uses custom version of the Windows C runtime which we’ve patched to include the high-performance jemalloc allocator. Extension authors should link the C runtime statically<\/a>, which guarantees that they will have a mismatched malloc\/free heap.<\/p>\n
Notes<\/h2>\n