Symbian3/PDK/Source/GUID-3D10DAFD-BE83-4892-B5E0-2ED7CF047788.dita
changeset 1 25a17d01db0c
child 3 46218c8b8afa
equal deleted inserted replaced
0:89d6a7a84779 1:25a17d01db0c
       
     1 <?xml version="1.0" encoding="utf-8"?>
       
     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
       
     3 <!-- This component and the accompanying materials are made available under the terms of the License 
       
     4 "Eclipse Public License v1.0" which accompanies this distribution, 
       
     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
       
     6 <!-- Initial Contributors:
       
     7     Nokia Corporation - initial contribution.
       
     8 Contributors: 
       
     9 -->
       
    10 <!DOCTYPE concept
       
    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
       
    12 <concept id="GUID-3D10DAFD-BE83-4892-B5E0-2ED7CF047788" xml:lang="en"><title>UHEAP
       
    13 Markers and Panics in GLib-based Applications</title><shortdesc>The 2.10.x version of GLib has introduced a new type of memory
       
    14 allocator called slice allocator. These allocators allocate memory in page
       
    15 sizes even for a small request of something like 20 bytes. Once a huge chunk
       
    16 has been allocated, all the future memory requests are granted using the chunk
       
    17 that was allocated for the first memory request. Once the free pool runs out,
       
    18 another huge chunk is allocated.  </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
       
    19 <p>Whenever the memory is freed using <codeph>g_slice_free1()</codeph>, the
       
    20 memory is not returned to the OS; instead it is maintained by GLib as free
       
    21 memory which is used to for future memory requests.  </p>
       
    22 <p>The following example explains the issue. The code given below uses slice
       
    23 allocators to allocate 10 bytes of memory using <codeph>g_slice_alloc()</codeph> and
       
    24 subsequently frees it using <codeph>g_slice_free1()</codeph>. The code panics
       
    25 at <codeph>__UHEAP_MARKEND</codeph>, although the memory that has been allocated
       
    26 has been deallocated. This is because all the allocated memory on the heap
       
    27 has not been deallocated. When the user calls <codeph>g_slice_free1()</codeph> to
       
    28 free up, the memory is not freed; instead, GLib will keep it as part of the
       
    29 free pool for future allocation.  </p>
       
    30 <codeblock xml:space="preserve">#include &lt;glib.h&gt;
       
    31 #include &lt;e32base.h&gt;
       
    32 
       
    33 int main()
       
    34 {
       
    35   char *x;
       
    36   __UHEAP_MARK;
       
    37   x = (char *)g_slice_alloc(10);
       
    38   g_slice_free1(10,x);
       
    39   __UHEAP_MARKEND;
       
    40   return 0;
       
    41 }
       
    42 </codeblock>
       
    43 <p>To get around this problem, define an environment variable <codeph>G_SLICE</codeph> and
       
    44 set it to “always-malloc”.</p>
       
    45 <note>It is necessary that this environment variable is set before any GLib
       
    46 call that can cause memory allocation. If the environment variable is set
       
    47 after any <codeph>g_slice*</codeph> APIs have been called either from the
       
    48 application code or from GLib library code, setting it has not effect.</note>
       
    49 <p>The code below demonstrates the usage.</p>
       
    50 <codeblock xml:space="preserve">#include &lt;glib.h&gt;
       
    51 #include &lt;e32base.h&gt;
       
    52 
       
    53 int main()
       
    54 {
       
    55   char *x;
       
    56   __UHEAP_MARK;
       
    57  	g_setenv("G_SLICE","always-malloc",1);
       
    58   x = (char *)g_slice_alloc(10);
       
    59   g_slice_free1(10,x);
       
    60  __UHEAP_MARKEND;
       
    61  return 0;
       
    62 }
       
    63 </codeblock>
       
    64 <note><codeph>G_SLICE</codeph> is just a debugging environment variable. Setting
       
    65 it to “always-malloc” can help in detecting memory leaks in application code.
       
    66 This setting need not and should not be done in the release code since doing
       
    67 it overrides the GLib memory allocation mechanism and hence may
       
    68 result in loss of efficiency. The slice allocators are used by other GLib
       
    69 APIs like <codeph>GList</codeph>, <codeph>GSList</codeph>, <codeph>GNode</codeph>,
       
    70 and so on. Thus setting the environment variable is necessary if the application
       
    71 makes use of any such APIs that might use slice allocators.</note>
       
    72 </conbody></concept>