On Wed, 24 Oct 2001, Jörg Pommnitz wrote: > It's either a bug in Kannel (memory leak) or a heavily > stressed system running in debug limits. If it's not a > memory leak, you can prevent the emergency shutdown > by disabling debug malloc while calling configure.
The checking malloc system can only handle limited number of memory allocations at once; if there is more, it thinks it is a memory leak. Several months ago I multiplied the limit by 10x and thus the limit was very seldom reached. However, it was still met and it means that somewhere a queue is built up. And in normal situation this is not good, as queue should be done in sockets/similar places, not inside Kannel. I tinkered a bit with that and we fixed smsc_fake a bit so that queue is not built inside Kannel anymore. That way a benchmark/test of million or even 10 million messages can be tested out. BTW, the test showed that checking_malloc Kannel has speed of about 20-25% of native malloc.
