help: about glib hash table

[wwxxdd1982]

{
        __UHEAP_MARK;
	GHashTable *map =NULL;
	map = g_hash_table_new(g_direct_hash, g_direct_equal);
	g_hash_table_destroy(map);
	__UHEAP_MARKEND;
}

code like this, it will be arise Panic ALLOC: 0x.......
addr for memory leaked
who know why ? do i code correctly?
pls

[Sorcery-ltd]

I wouldn't reccommend using the heap checking macros around small bits of Open C code. It may well be that some memory small amount of memory is allocated by the P.I.P.S. backend that won't be freed until much later (possibly application exit).

In the background the libraries are using the cleanup stack (which may be expanded by your operation) and also maintaining file mapping tables and other resource lists.

If you actually have a memory leak problem when the application exits then it's worth checking further.

Hope that helps,
Sorcery

[wwxxdd1982]

hi,
i am sorry for that i haven't told that i was using libglib.lib on a GUI project.
when i'm using libglib on a OpenC project, it's ok.
and i take another test on GUI project, like below which
is also ok.

GLDEF_C TInt E32Main()
	{
        table = g_hash_table_new(hash_func, equal_func);
        g_hash_table_destory(table);
	return 0;
	}

i just wonder what happens when i'm using libglib in the GUI framework? thx.

[Sorcery-ltd]

Like I said, don't worry about it unless there's a memory leak at the end of your program.

In an Open C application that is using the "glue code" (libcrt0.lib) then most of the things that the P.I.P.S. backend uses are allocated and initialized when the application starts up. If you are writing a hybrid application that doesn't use libcrt0.lib (like your GUI app) then the backend does it's allocation and initialization when you make your first P.I.P.S. call. The libglib functions will be making calls to the P.I.P.S. libraries internally.

In your basic test below, it's hard to tell exactly where/how you've done the memory check but most likely the check has been placed in the code after the compiler has deemed everything out of scope and done the necessary de-allocation.

Hope that explains a little.

Sorcery

[wwxxdd1982]

hi Sorcery :
thx for your answer
actually the case is this:
use glib function g_hash_table_new()....
after in
GLDEF_C TInt E32main()
{
reutrn EikStart::RunApplication( NewApplication );
}
it will leak in the project,
so i test it in hello world GUI Project.
it is same.

class CA : public CBase, public MObserver
{
//  any other code
.
.
public:
~CA();
private:
void ConstructL();

private:
GHashTable *map;
};
void CA::ConstructL()
{
 map = g_hash_table_new(g_direct_hash, g_direct_equal);
 
//  any other code
}

CA::~CA()
{
 g_hash_table_destroy(map );

//  any other code
}

[Sorcery-ltd]

Hmmm, strange. It could be that there is a "close" function for libglib that does that does the necessary cleanup for hybrid applications.

I found something very similar for the crypto libraries and as far as I could tell the close function was undocumented.

Try posting this query on the tools and SDK feedback board - that's where I got an answer that time.

Sorcery