Hi,
When running kannel I get the following error ...sometimes the bearerbox
crash and sometimes the smsbox
Assertion Failed..etc..etc..
" Too Many concurrent allocations "
Can anyone help me how can I fix it?
Thanks in advance.
Warm Regards,
Pravesh
Hi all,
After running the cvs 20020126 version of kannel connected to an SMPP
gateway quite happily for the last 6 days... kannel died with:
2002-01-31 00:11:22 [8] PANIC: Too many concurrent allocations.
Does this imply that the server it was running on ran out of memory? Or, is
there a
pravesh khokhar wrote:
> Hi,
> When running kannel I get the following error ...sometimes the bearerbox
> crash and sometimes the smsbox
> Assertion Failed..etc..etc..
> " Too Many concurrent allocations "
>
> Can anyone help me how can I fix it?
> Thanks in
(over 2000) messages to
Kannel (using the http interface) I invariably get the message
"PANIC: Too many concurrent allocations"
in the log file followed by the Kannel processes dying and the remainder of
the messages in the batch being lost.
Is this a Kannel issue, Linux/Kernel issue, har
ml
>
> - Original Message -
> From: "Jörg Pommnitz" <[EMAIL PROTECTED]>
> To: "'Tim Hammonds'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Thursday, October 25, 2001 12:12 AM
> Subject: AW: PANIC: Too many concurrent allocat
Hi,
Benjamin Lee wrote:
> After running the cvs 20020126 version of kannel connected to an SMPP
> gateway quite happily for the last 6 days... kannel died with:
>
> 2002-01-31 00:11:22 [8] PANIC: Too many concurrent allocations.
>
> Does this imply that the server it was run
Benjamin Lee wrote:
>
> After running the cvs 20020126 version of kannel connected to an SMPP
> gateway quite happily for the last 6 days... kannel died with:
>
> 2002-01-31 00:11:22 [8] PANIC: Too many concurrent allocations.
>
> Does this imply that the server it was
for the last 6 days... kannel died with:
> >
> > 2002-01-31 00:11:22 [8] PANIC: Too many concurrent allocations.
> >
> > Does this imply that the server it was running on ran out of memory? Or, is
> > there a subtle leak somewhere?
>
>No, Kannel has a limitation i
On Thu, Jan 31, 2002 at 02:53:26PM +0100, Stipe Tolj wrote:
> Benjamin Lee wrote:
> > Does this imply that the server it was running on ran out of memory? Or, is
> > there a subtle leak somewhere?
>
> No, Kannel has a limitation if you run it in --with-malloc=check mode
> which is the default set
Richard Braakman wrote:
>
> In either case, Stipe is right in that the panic was from the malloc
> checking code, and not from the server running out of memory.
> I just wanted to point out that if you get that panic, it still
> means there's an actual bug. You can hide it by turning off the
> m
On Thu, Jan 31, 2002 at 05:39:20PM +0100, Stipe Tolj wrote:
> Richard, can we utilize some function to detect memory leaks using the
> checking malloc routines already built-in Kannel?
Yes. If you turn debug logging on, you will get a list of still-allocated
areas when a process shuts down. Thi
Nisan Bloch wrote:
>
> I sent you a small patch for the smpp module a few days ago. It should
> address this error.
>
> Here it is again.
>
> --- gw/smsc_smpp.c Thu Jan 17 22:51:52 2002
> +++ smsc_smpp.c Mon Jan 21 21:01:35 2002
> @@ -548,6 +548,7 @@
>
> info(0,"DLR = %s",octstr_get_cstr(dlrms
Richard Braakman wrote:
>
> The SIGQUIT code is in signal_handler() in wapbox.c, and can be easily
> copied to the other boxes.
I just added this to gw/bearerbox.c and gw/smsbox.c.
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Mün
Everybody, thanks all for the information!
For what it's worth, I'm now running kannel (cvs update from yesterday)
compiled with:
./configure --prefix=/usr --with-defaults=speed --disable-docs --disable-ssl
--enable-debug
(malloc checking off) I'll be watching it closely to see what happens.
Hammonds [mailto:[EMAIL PROTECTED]]
> Gesendet am: Mittwoch, 24. Oktober 2001 17:58
> An: [EMAIL PROTECTED]
> Betreff: PANIC: Too many concurrent allocations
>
> I am using a cvs version of Kannel as an SMS Gateway to a
> UCP/EMI SMSC.
>
> I was originally having th
D]>
Sent: Wednesday, October 24, 2001 9:27 PM
Subject: PANIC: Too many concurrent allocations
> I am using a cvs version of Kannel as an SMS Gateway to a UCP/EMI SMSC.
>
> I was originally having throughput problems with Kannel V1.1.5, as the
SMSC
> was ignoring messages sent if they
PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of ml
Sent: Thursday, 25 October 2001 5:55 p.m.
To: [EMAIL PROTECTED]
Subject: PANIC: Too many concurrent allocations
hi, Jörg
we met the problem too.
but if we compile kannel with native malloc mode , the following PANIC
occur,
2001-10-08 17:57:50
ml wrote:
> hi, Jörg
>
> we met the problem too.
> but if we compile kannel with native malloc mode , the following PANIC occur,
>
> 2001-10-08 17:57:50 [8] PANIC: mutex_unlock: Mutex failure!
> 2001-10-08 17:57:50 [8] PANIC: System error 22: Invalid argument
>
> thanks & best regards
> ml
This
Rumsfeld Donald <[EMAIL PROTECTED]>wrote:
Hi all,
I'm using GW CVS-20020611. It works well, but after about 2 days, the GW died with error: "PANIC: Too many concurrent allocations.".
Here's log:
2002-09-01 22:33:47 [0] INFO: Started access logfile `/log/access.l
"maybe".
-Original Message-From: Rumsfeld Donald
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, September 03, 2002 7:29
PMTo: Rumsfeld Donald; [EMAIL PROTECTED]Cc:
[EMAIL PROTECTED]Subject: BUG: "PANIC: Too many concurrent
allocations"
Rumsfeld Donald <
Hi all,
My GW was built with native mem-check (default option).
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 ?
Is there any way to watch packets from the time it's allocated memory to th
Mittwoch, September 4, 2002, at 06:42 Uhr, Rumsfeld Donald wrote:> Hi all,>> My GW was built with native mem-check (default option).>> I think that this error was caused by allocation memory too much.>if you get too many concurrent allocations, your gateway was definitively built w
-Original Message-From: Rumsfeld Donald
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, September 04, 2002
6:42 AMTo: Oded ArbelCc:
[EMAIL PROTECTED]Subject: RE: "PANIC: Too many concurrent
allocations"
Hi all,
My GW was built with native mem-check (defa
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 on
Hi,
I have this problem
I'm trying to send out SMS Broadcast and after a while kannel just die because of
PANIC: Too many concurrent allocations
Is that any way i can increase the concurrent allocations process?
Base on your experience, how many SMS can kannel process per second?
I&#x
; -Original Message-
> From: Abd Rahman Johari [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 24, 2002 5:51 AM
> To: [EMAIL PROTECTED]
> Subject: EMI: Serious Problem PANIC: Too many concurrent allocations
>
>
> Hi,
>
> I have this problem
>
> I'm tryi
On 24 May 2002, Abd Rahman Johari wrote:
> I'm trying to send out SMS Broadcast and after a while kannel just die
> because of PANIC: Too many concurrent allocations
You need to compile Kannel with non-checking malloc, i.e. use native
malloc. ./configure --with-defaults=speed or --
Kalle Marjola wrote:
>
> Hm, this question needs to be a s a first one in FAQ, it is so often
> asked.. (in fact I could not find it from FAQ section at all..)
definitly +1 ;)
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Münsters
Kalle Marjola wrote:
>On 24 May 2002, Abd Rahman Johari wrote:
>
>
>>I'm trying to send out SMS Broadcast and after a while kannel just die
>>because of PANIC: Too many concurrent allocations
>>
>>
>
>You need to compile Kannel with n
On Sat, 2002-06-01 at 02:11, Jari Juslin wrote:
> Kalle Marjola wrote:
>
> >On 24 May 2002, Abd Rahman Johari wrote:
> >
> >
> >>I'm trying to send out SMS Broadcast and after a while kannel just die
> >>because of PANIC: Too many concurrent alloc
crease MAX_TAB_SIZE in gwlib/gwmem-check.c
significantly. If I still run to these panics, there is propably some
bad memory leak that should be hunted down.
So, panic to "Too many concurrent allocations" can happen if a) Kannel
just has so high load, that is needs huge amounts of memory or b)
I want to run Kannel under heavy
> load, I need to increase MAX_TAB_SIZE in gwlib/gwmem-check.c
> significantly. If I still run to these panics, there is propably some
> bad memory leak that should be hunted down.
>
> So, panic to "Too many concurrent allocations" can h
On Sat, 1 Jun 2002, Jari Juslin wrote:
> So, panic to "Too many concurrent allocations" can happen if a) Kannel
> just has so high load, that is needs huge amounts of memory or b) if
> Kannel leaks too much memory. Am I right?
Yes. The reason a) is encountered when incomin
Kalle Marjola kirjoittaa maanantaina, 3. kesäkuuta 2002, kello 10:37:On
Sat, 1 Jun 2002, Jari Juslin wrote:
>
>> So, panic to "Too many concurrent allocations" can happen if a) Kannel
>> just has so high load, that is needs huge amounts of memory or b) if
>> Kan
>
> Kannel currently has configuration variable maximum-queue-length. See
> user-
> guide for details.
>
Yes, but when this is triggered bb_smscconn_receive () logs the event and
returns -1. All the SMSC drivers except HTTP ignore the return code from
bb_smscconn_receive (). Therefore, the mes
Paul Keogh kirjoittaa tiistaina, 4. kesäkuuta 2002, kello 14:51:
> Yes, but when this is triggered bb_smscconn_receive () logs the event
> and
> returns -1. All the SMSC drivers except HTTP ignore the return code from
> bb_smscconn_receive (). Therefore, the message is silently dropped from
> th
On Wed, 2002-06-05 at 09:39, Aarno Syvänen wrote:
> Paul Keogh kirjoittaa tiistaina, 4. kesäkuuta 2002, kello 14:51:
>
> > Yes, but when this is triggered bb_smscconn_receive () logs the event
> > and
> > returns -1. All the SMSC drivers except HTTP ignore the return code from
> > bb_smscconn_re
x27;t run into the too many concurrent allocations issue after using a
--malloc=native flag since we went live on May 31st.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Bruno David Rodrigues
Sent: Wednesday, June 12, 2002 4:23 PM
To: Aarno Syv?en
Cc: Paul
Bruno David Rodrigues kirjoittaa keskiviikkona, 12. kesäkuuta 2002,
kello 12:22:
Yes, it indeed seems that this code can use some rewriting :( Does
Paul's suggestion
met your big file needs (let us plan better this time).
Aarno
>> Paul Keogh kirjoittaa tiistaina, 4. kesäkuuta 2002, kello 14:5
On Wed, 2002-06-12 at 10:58, Aarno Syvänen wrote:
> Bruno David Rodrigues kirjoittaa keskiviikkona, 12. kesäkuuta 2002,
> kello 12:22:
>
> Yes, it indeed seems that this code can use some rewriting :( Does
> Paul's suggestion
> met your big file needs (let us plan better this time).
I don't ca
close to the kind of traffic you are talking about as well.
> Didn't run into the too many concurrent allocations issue after using a
> --malloc=native flag since we went live on May 31st.
With 1GB ? I don't think so.
I recall that smsbox*.log have each and every message but
bearerbox_*.log lost almost 25%.
Bruno David Rodrigues wrote:
>
> I recall that smsbox*.log have each and every message but
> bearerbox_*.log lost almost 25%.
but those messages that have been logged in smsbox.log, but *not* in
bearerbox.log have to be queued in the store file, right?!
Can you verify this?
BTW, I'd like to im
On Wed, 2002-06-12 at 11:36, Stipe Tolj wrote:
> Bruno David Rodrigues wrote:
> >
> > I recall that smsbox*.log have each and every message but
> > bearerbox_*.log lost almost 25%.
>
> but those messages that have been logged in smsbox.log, but *not* in
> bearerbox.log have to be queued in the s
Bruno David Rodrigues wrote:
>
> On Wed, 2002-06-12 at 11:36, Stipe Tolj wrote:
> > Bruno David Rodrigues wrote:
> > >
> > > I recall that smsbox*.log have each and every message but
> > > bearerbox_*.log lost almost 25%.
> >
> > but those messages that have been logged in smsbox.log, but *not* i
Rodrigues
> Cc: [EMAIL PROTECTED]; 'Aarno Syv?en'; 'Paul Keogh';
> [EMAIL PROTECTED]
> Subject: Re: EMI: Serious Problem PANIC: Too many concurrent
> allocations
>
>
> Bruno David Rodrigues wrote:
> >
> > I recall that smsbox*.log have eac
Oded Arbel kirjoittaa keskiviikkona, 12. kesäkuuta 2002, kello 14:34:
Speaking of store files - After really looking into the store logic, it
seems my notion of how store worked was all wrong : the elimination of
messages that received acks/nacks from storage is done only on
store_load, so it'
46 matches
Mail list logo
