<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-3D10DAFD-BE83-4892-B5E0-2ED7CF047788" xml:lang="en"><title>UHEAP

Markers and Panics in GLib-based Applications</title><shortdesc>The 2.10.x version of GLib has introduced a new type of memory

allocator called slice allocator. These allocators allocate memory in page

sizes even for a small request of something like 20 bytes. Once a huge chunk

has been allocated, all the future memory requests are granted using the chunk

that was allocated for the first memory request. Once the free pool runs out,

another huge chunk is allocated.  </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>Whenever the memory is freed using <codeph>g_slice_free1()</codeph>, the

memory is not returned to the OS; instead it is maintained by GLib as free

memory which is used to for future memory requests.  </p>

<p>The following example explains the issue. The code given below uses slice

allocators to allocate 10 bytes of memory using <codeph>g_slice_alloc()</codeph> and

subsequently frees it using <codeph>g_slice_free1()</codeph>. The code panics

at <codeph>__UHEAP_MARKEND</codeph>, although the memory that has been allocated

has been deallocated. This is because all the allocated memory on the heap

has not been deallocated. When the user calls <codeph>g_slice_free1()</codeph> to

free up, the memory is not freed; instead, GLib will keep it as part of the

free pool for future allocation.  </p>

<codeblock xml:space="preserve">#include &lt;glib.h&gt;

#include <e32base.h>

int main()

{

  char *x;

  __UHEAP_MARK;

  x = (char *)g_slice_alloc(10);

  g_slice_free1(10,x);

  __UHEAP_MARKEND;

  return 0;

}

</codeblock>

<p>To get around this problem, define an environment variable <codeph>G_SLICE</codeph> and

set it to “always-malloc”.</p>

<note>It is necessary that this environment variable is set before any GLib

call that can cause memory allocation. If the environment variable is set

after any <codeph>g_slice*</codeph> APIs have been called either from the

application code or from GLib library code, setting it has not effect.</note>

<p>The code below demonstrates the usage.</p>

<codeblock xml:space="preserve">#include &lt;glib.h&gt;

#include <e32base.h>

int main()

{

  char *x;

  __UHEAP_MARK;

 	g_setenv("G_SLICE","always-malloc",1);

  x = (char *)g_slice_alloc(10);

  g_slice_free1(10,x);

 __UHEAP_MARKEND;

 return 0;

}

</codeblock>

<note><codeph>G_SLICE</codeph> is just a debugging environment variable. Setting

it to “always-malloc” can help in detecting memory leaks in application code.

This setting need not and should not be done in the release code since doing

it overrides the GLib memory allocation mechanism and hence may

result in loss of efficiency. The slice allocators are used by other GLib

APIs like <codeph>GList</codeph>, <codeph>GSList</codeph>, <codeph>GNode</codeph>,

and so on. Thus setting the environment variable is necessary if the application

makes use of any such APIs that might use slice allocators.</note>