-----Original Message-----
From: Rumsfeld Donald [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 04, 2002 6:42 AM
To: Oded Arbel
Cc: [EMAIL PROTECTED]
Subject: RE: "PANIC: Too many concurrent allocations"Hi all,
My GW was built with native mem-check (default option).
You can compile either with "native" or with "checking" - not both. the default option before 1.2.0 was "checking", so my suggestion to you would be to recompile with "native". in native mode, Kannel will not check for "too many allocations".
I think that this error was caused by allocation memory too much.
Is there some packets that allocated memory before, but would not released after life-time ?
I'm not sure what you mean by "packets", but it is possible that some code claims memory and never releases it - thats what we call "a memory leak". we find these all the time and fix them - a later version will have fewer leaks.
Is there any way to watch packets from the time it's allocated memory to the time that it's released? For examples, using log file to track each mem block allocated or release in the function gw_malloc() and gw_free()?
No. when the Kannel is brought down, and it was compiled with "checking" or "slow" malloc, then a report will be generated on each memory segment that was not freed and which part of the code claimed it. this may or may not be helpful, as some functions claim memory for other parts of the code which are responsible for freeing it and may not do that properly.
--
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]
+972-9-9581711 (116)
+972-67-340014
::..
The first sign of maturity is the discovery that the volume knob
also turns to
the left.
