[Home]

Summary:ASTERISK-07944: Asterisk Crashes with Glibc error on CentOS 4.4
Reporter:Mark Hampton (mhampton)Labels:
Date Opened:2006-10-18 21:05:22Date Closed:2007-03-19 08:24:41
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When It crashes, I typically have 100 - 150 channels in use.  It happens a couple of times a day per server.  Typically it's a GLIBC invalid memory address error, but it scrolled past too fast for me to get the details.  The backtrace from the core file is in the "Additional Info" section.  My Asterisk log looked like this just before and after the crash.  

Oct 18 10:05:01 DEBUG[4903] pbx.c: Function result is ''
Oct 18 10:05:01 DEBUG[4905] pbx.c: Expression result is '1'
Oct 18 10:05:01 DEBUG[4903] pbx.c: Expression result is '1'
Oct 18 10:05:01 DEBUG[4903] pbx.c: Expression result is '1'
Oct 18 10:05:01 DEBUG[4903] pbx.c: Expression result is '1'
Oct 18 10:05:01 DEBUG[4905] pbx.c: Expression result is '1'
Oct 18 10:05:01 DEBUG[4905] pbx.c: Function result is '"" <8003415019>'
Oct 18 10:05:01 DEBUG[4903] pbx.c: Function result is '"" <8003415019>'
Oct 18 10:05:05 VERBOSE[4952] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
Oct 18 10:05:05 VERBOSE[4952] logger.c: Asterisk Dynamic Loader loading preload modules:


****** ADDITIONAL INFORMATION ******

#0  ast_var_name (var=0x10) at chanvars.c:71
#1  0x08089b18 in pbx_builtin_getvar_helper (chan=0x952b338, name=0x3506340 "GROUP") at pbx.c:5940
#2  0x080a2254 in ast_app_group_get_count (group=0x3506430 "OUT_2", category=0x35063e0 "GROUP") at app.c:1067
#3  0x00148390 in group_count_function_read (chan=0x957efe8, cmd=0x35064c0 "GROUP_COUNT", data=0x0, buf=0x3506510 "",
   len=0) at func_groupcount.c:54
#4  0x08086dd6 in ast_func_read (chan=0x0, in=0x3507520 "GROUP_COUNT()", workspace=0x0, len=0) at pbx.c:1377
ASTERISK-1  0x08088aec in pbx_substitute_variables_helper_full (c=0x957efe8, headp=0x957f3b0,
   cp1=0x35095b0 " ${GROUP_COUNT()} > ${OUTMAXCHANS_${ARG1}} ", cp2=0x35085a1 "", count=4094) at pbx.c:1520
ASTERISK-2  0x08088dd6 in pbx_substitute_variables_helper_full (c=0x957efe8, headp=0x957f3b0,
   cp1=0x94c3cf0 "$[ ${GROUP_COUNT()} > ${OUTMAXCHANS_${ARG1}} ]?108", cp2=0x350e7d0 "", count=8191) at pbx.c:1580
ASTERISK-3  0x0809128d in pbx_extension_helper (c=0x957efe8, con=Variable "con" is not available.
) at pbx.c:1600
ASTERISK-4  0x080919cc in ast_spawn_extension (c=0x0, context=0x10 "", exten=0x10 "", priority=16, callerid=0x10 "")
   at pbx.c:2230
ASTERISK-5  0x0047d65c in macro_exec (chan=0x957efe8, data=0x35150a0) at app_macro.c:215
ASTERISK-6 0x0809141d in pbx_extension_helper (c=0x957efe8, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-7 0x080926e6 in __ast_pbx_run (c=0x957efe8) at pbx.c:2230
ASTERISK-8 0x0809424c in pbx_thread (data=0x0) at pbx.c:2517
ASTERISK-9 0x00b53371 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-10 0x00a66ffe in clone () from /lib/tls/libc.so.6
Comments:By: Eric Romang / DCLUX (eromang) 2006-10-19 00:33:49

Hello,

Which OS, CPU and version of glibc you have ?

Did you think http://bugs.digium.com/view.php?id=8085 is the same trouble ?

Regards
By: Mark Hampton (mhampton) 2006-10-19 01:00:26

I'm not sure if it's the same problem.  Here's the server info:

OS:  CentOS 4.4
Uname -a:  2.6.9-42.0.3.ELsmp #1 SMP
Glibc Version:  glibc-2.3.4-2.25
Motherboard:  SuperMicro X7DBR-E Intel Xeon DualCore DualProc SATA
Memory:  1GB
By: Mark Hampton (mhampton) 2006-10-19 01:04:26

Here's a core bt from another server which had an Asterisk crash.  This server is identical to the first:

#0  0x009897a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x009ce7a5 in raise () from /lib/tls/libc.so.6
#2  0x009d0209 in abort () from /lib/tls/libc.so.6
#3  0x00a0271a in __libc_message () from /lib/tls/libc.so.6
#4  0x00a08fbf in _int_free () from /lib/tls/libc.so.6
ASTERISK-1  0x00a0933a in free () from /lib/tls/libc.so.6
ASTERISK-2  0x08061528 in ast_channel_free (chan=0x91acd08) at channel.c:957
ASTERISK-3  0x08067f6d in ast_hangup (chan=0x91acd08) at channel.c:1392
ASTERISK-4  0x080929d1 in __ast_pbx_run (c=0x91acd08) at pbx.c:2467
ASTERISK-5  0x0809424c in pbx_thread (data=0x0) at pbx.c:2517
ASTERISK-6 0x00b2b371 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-7 0x00a6effe in clone () from /lib/tls/libc.so.6
By: Mark Hampton (mhampton) 2006-10-19 01:06:17

Here's one from server 3:

#0  0x00a0b7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00a507a5 in raise () from /lib/tls/libc.so.6
#2  0x00a52209 in abort () from /lib/tls/libc.so.6
#3  0x00a8471a in __libc_message () from /lib/tls/libc.so.6
#4  0x00a8afbf in _int_free () from /lib/tls/libc.so.6
ASTERISK-1  0x00a8b33a in free () from /lib/tls/libc.so.6
ASTERISK-2  0x08056dcc in ast_verbose (fmt=0x7a5d7d "%s %s: %s\n") at logger.c:884
ASTERISK-3  0x007a25a9 in handle_verbose (chan=0x0, agi=0x0, argc=3, argv=0x4470060) at res_agi.c:1236
ASTERISK-4  0x007a4052 in agi_exec_full (chan=0xa1dd1a0, data=Variable "data" is not available.
) at res_agi.c:1828
ASTERISK-5  0x0809141d in pbx_extension_helper (c=0xa1dd1a0, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-6 0x080919cc in ast_spawn_extension (c=0x0, context=0x6 "", exten=0x6 "", priority=6, callerid=0x6 "") at pbx.c:2230
ASTERISK-7 0x0035a65c in macro_exec (chan=0xa1dd1a0, data=0x447c0a0) at app_macro.c:215
ASTERISK-8 0x0809141d in pbx_extension_helper (c=0xa1dd1a0, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-9 0x080926e6 in __ast_pbx_run (c=0xa1dd1a0) at pbx.c:2230
ASTERISK-10 0x0809424c in pbx_thread (data=0x0) at pbx.c:2517
ASTERISK-11 0x00b98371 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-12 0x00af0ffe in clone () from /lib/tls/libc.so.6
By: Eric Romang / DCLUX (eromang) 2006-10-19 01:43:02

Hello,

I run under RHEL 4 ES with 2.6.9-42.0.3.ELsmp #1 SMP and the glibc-2.3.4-2.25.
I run also a dual core Intel Xeon.

What I see is that we have the same error messages :

ASTERISK-4 0x007a4052 in agi_exec_full (chan=0xa1dd1a0, data=Variable "data" is not available.
) at res_agi.c:1828
ASTERISK-5 0x0809141d in pbx_extension_helper (c=0xa1dd1a0, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-6 0x080919cc in ast_spawn_extension (c=0x0, context=0x6 "", exten=0x6 "", priority=6, callerid=0x6 "") at pbx.c:2230
ASTERISK-7 0x0035a65c in macro_exec (chan=0xa1dd1a0, data=0x447c0a0) at app_macro.c:215
ASTERISK-8 0x0809141d in pbx_extension_helper (c=0xa1dd1a0, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-9 0x080926e6 in __ast_pbx_run (c=0xa1dd1a0) at pbx.c:2230
ASTERISK-10 0x0809424c in pbx_thread (data=0x0) at pbx.c:2517
ASTERISK-11 0x00b98371 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-12 0x00af0ffe in clone () from /lib/tls/libc.so.6

Regards.
By: Mark Hampton (mhampton) 2006-10-19 09:59:35

I does seem similar.  Hard to tell on the surface it it's a glibc problem, an Aasterisk problem, or a combination of both.
By: Eric Romang / DCLUX (eromang) 2006-10-19 10:50:27

Hi,

Did you have also into /var/log/messages this kind of error log ?

Oct 12 09:27:05 5_lu_supernode kernel: asterisk[5782] general protection rip:3a9f1684cb rsp:401b8ba0 error:0
Oct 16 11:31:48 5_lu_supernode kernel: asterisk[2459]: segfault at 0000003d00000007 rip 0000002a962ef100 rsp 00000000402f67e0 error 4
Oct 16 12:22:57 5_lu_supernode kernel: asterisk[2709]: segfault at 0000003d0000000f rip 00000000004884a9 rsp 0000000040185020 error 4

Regards.
By: Mark Hampton (mhampton) 2006-10-19 11:13:02

I had nothing in /var/adm/messages, but maybe that's because stdout from Asterisk was going to the console.  The message looks familiar from what I remember.  I was definitely a segv of some sort.
By: sbingner (sbingner) 2006-10-19 18:52:24

Are you using NPTL or LinuxThreads?

getconf GNU_LIBPTHREAD_VERSION

There was report of a similar issue and the user updated from linuxthreads to NPTL but I don't believe we ever found out if it corrected the issues.


By: Mark Hampton (mhampton) 2006-10-19 19:42:24

Evidently NTPL:

# getconf GNU_LIBPTHREAD_VERSION
NPTL 2.3.4
By: Steve Murphy (murf) 2006-10-20 10:33:35

Well, it doesn't look like this has come to any conclusion yet, and I've noticed over the years, that desperate men are willing to try desperate things... if this is your case, I have noted that more than one stack trace includes a call to app_macro.

If you were using trunk, a simple experiment would be to replace the calls to Macro() with Gosub() instead, including the macro's args in the Gosub's arglist. But you can't do that in 1.4 or 1.2... So, if you are desperate and want to do an experiment, then go to a development machine, grab a copy of your 1.2 release, and also grab the trunk version of asterisk...

Take a copy of the trunk/apps/app_stack.c and substitute the Gosub and Return routines, if they otherwise have the same args, from trunk, into the 1.2 app_stack.c. Tweedle it until it compiles and works. You now have the famous and acclaimed "gosub-with-args" enhancement! Then, take a copy of your production dialplan, and substitute the Macro() calls with Gosub() calls. Pick thru your macros and make sure there's Return() calls in the right places. Test and debug. Get it all to work. Then, when it feels good, move the test exec into your production environment, and see if it reduces your crash rate at all.

It could easily be, that this has no affect at all on your crash rate, and that you wasted your time completely. Life is a gamble. But before you take this big gamble, let me tell you my reasons for suggesting it:
1. All dialplan code is executed in a thread.
2. All threads have an assigned, fixed, stack size.
3. When you run out of stack space, you crash, in seemingly random fashion.
4. Macro invokes a whole new extension/priority processing engine to process the instructions in the macro.
5. Gosub just appends a return addr to VM, and jumps to the proper location. No expensive engine is invoked. Return() reverses the affect.
6. From experience, Macros have been hard-coded to limit the depth to which macros can call other macros to the round number 7. I personally have witnessed crashes in asterisk when it hits 9, and heard reports of crashes at 8. But, you don't necessarily have to call stuff that deep to get the same affect. Anthing that uses a fair amount of stack could single-handedly hit the ceiling without any help from Macro.  But any memory crash with Macro() in the trace should raise some alarms...

So, there, the experiment is up to you.
By: Mark Hampton (mhampton) 2006-10-20 20:13:31

I hope I don't sound _that_ desperate :)

From what I can tell, most of the backtraces show that the segmentation violations are coming from glibc free(), but not from any one specific place in asterisk.  It almost seems random.

I'm suspicious of CentOS 4.4 more than anything.  Problem is, when I tried downgrading the kernel to 4.3, my server would no longer boot, and I couldn't resolve it before my down-time window was up.  I may make another attempt at some point.

Last night I upgrade all of the servers to Asterisk 1.2.13, along with the latest versions of zaptel, libpri, and addons.  Today 3 out of 4 servers experienced an Asterisk crash.  Here are the bts:

#0  0x009817a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x009c67a5 in raise () from /lib/tls/libc.so.6
#2  0x009c8209 in abort () from /lib/tls/libc.so.6
#3  0x009fa71a in __libc_message () from /lib/tls/libc.so.6
#4  0x00a00fbf in _int_free () from /lib/tls/libc.so.6
ASTERISK-1  0x00a0133a in free () from /lib/tls/libc.so.6
ASTERISK-2  0x08061568 in ast_channel_free (chan=0xb705fb20) at channel.c:957
ASTERISK-3  0x08067fad in ast_hangup (chan=0xb705fb20) at channel.c:1392
ASTERISK-4  0x08092ac1 in __ast_pbx_run (c=0xb705fb20) at pbx.c:2467
ASTERISK-5  0x0809434c in pbx_thread (data=0x0) at pbx.c:2517
ASTERISK-6 0x00b53371 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-7 0x00a66ffe in clone () from /lib/tls/libc.so.6

#0  0x00a0b7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00a507a5 in raise () from /lib/tls/libc.so.6
#2  0x00a52209 in abort () from /lib/tls/libc.so.6
#3  0x00a8471a in __libc_message () from /lib/tls/libc.so.6
#4  0x00a8afbf in _int_free () from /lib/tls/libc.so.6
ASTERISK-1  0x00a8b33a in free () from /lib/tls/libc.so.6
ASTERISK-2  0x00667623 in dial_exec_full (chan=0x9b2d248, data=Variable "data" is not available.
) at app_dial.c:286
ASTERISK-3  0x0066a7ad in dial_exec (chan=0x0, data=0x6) at app_dial.c:1649
ASTERISK-4  0x0809150d in pbx_extension_helper (c=0x9b2d248, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-5  0x08091abc in ast_spawn_extension (c=0x0, context=0x6 "", exten=0x6 "", priority=6, callerid=0x6 "") at pbx.c:2230
ASTERISK-6 0x0049d66c in macro_exec (chan=0x9b2d248, data=0x177f0a0) at app_macro.c:221
ASTERISK-7 0x0809150d in pbx_extension_helper (c=0x9b2d248, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-8 0x080927d6 in __ast_pbx_run (c=0x9b2d248) at pbx.c:2230
ASTERISK-9 0x0809434c in pbx_thread (data=0x0) at pbx.c:2517
ASTERISK-10 0x00b98371 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-11 0x00af0ffe in clone () from /lib/tls/libc.so.6

#0  ast_var_name (var=0x18) at chanvars.c:71
#1  0x08089b78 in pbx_builtin_getvar_helper (chan=0x957d678, name=0x2fac340 "GROUP") at pbx.c:5941
#2  0x080a2374 in ast_app_group_get_count (group=0x2fac430 "OUT_1", category=0x2fac3e0 "GROUP") at app.c:1067
#3  0x007cd390 in group_count_function_read (chan=0x95a0f70, cmd=0x2fac4c0 "GROUP_COUNT", data=0x0, buf=0x2fac510 "",
   len=0) at func_groupcount.c:54
#4  0x08086e36 in ast_func_read (chan=0x0, in=0x2fad520 "GROUP_COUNT()", workspace=0x0, len=0) at pbx.c:1377
ASTERISK-1  0x08088b4c in pbx_substitute_variables_helper_full (c=0x95a0f70, headp=0x95a1338,
   cp1=0x2faf5b0 " ${GROUP_COUNT()} > ${OUTMAXCHANS_${ARG1}} ", cp2=0x2fae5a1 "", count=4094) at pbx.c:1520
ASTERISK-2  0x08088e36 in pbx_substitute_variables_helper_full (c=0x95a0f70, headp=0x95a1338,
   cp1=0x954e798 "$[ ${GROUP_COUNT()} > ${OUTMAXCHANS_${ARG1}} ]?108", cp2=0x2fb47d0 "", count=8191) at pbx.c:1580
ASTERISK-3  0x0809137d in pbx_extension_helper (c=0x95a0f70, con=Variable "con" is not available.
) at pbx.c:1600
ASTERISK-4  0x08091abc in ast_spawn_extension (c=0x0, context=0x18 "", exten=0x18 "", priority=24, callerid=0x18 "")
   at pbx.c:2230
ASTERISK-5  0x007c266c in macro_exec (chan=0x95a0f70, data=0x2fbb0a0) at app_macro.c:221
ASTERISK-6 0x0809150d in pbx_extension_helper (c=0x95a0f70, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-7 0x080927d6 in __ast_pbx_run (c=0x95a0f70) at pbx.c:2230
ASTERISK-8 0x0809434c in pbx_thread (data=0x0) at pbx.c:2517
ASTERISK-9 0x00476371 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-10 0x003b9ffe in clone () from /lib/tls/libc.so.6

#0  0x00354890 in _int_malloc () from /lib/tls/libc.so.6
#1  0x00356401 in malloc () from /lib/tls/libc.so.6
#2  0x0035b030 in strdup () from /lib/tls/libc.so.6
#3  0x00975364 in macro_exec (chan=0x8b00770, data=0x29467d0) at app_macro.c:181
#4  0x0809150d in pbx_extension_helper (c=0x8b00770, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-1  0x08091abc in ast_spawn_extension (c=0x0, context=0x8ae6378 "", exten=0x8ae6378 "", priority=145646456,
   callerid=0x8ae6378 "") at pbx.c:2230
ASTERISK-2  0x0097566c in macro_exec (chan=0x8b00770, data=0x294d0a0) at app_macro.c:221
ASTERISK-3  0x0809150d in pbx_extension_helper (c=0x8b00770, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-4  0x080927d6 in __ast_pbx_run (c=0x8b00770) at pbx.c:2230
ASTERISK-5  0x0809434c in pbx_thread (data=0x0) at pbx.c:2517
ASTERISK-6 0x00476371 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-7 0x003b9ffe in clone () from /lib/tls/libc.so.6
By: Mark Hampton (mhampton) 2006-10-23 19:17:30

I finally saw the glibc error today:

*** glibc detected *** free(): invalid pointer: 0x0a202148 ***

Asterisk ended with exit status 134
Asterisk exited on signal 6.
By: Eric Romang / DCLUX (eromang) 2006-10-24 11:49:00

Hello again,

What protocol are you using ? SIP, IAX or both ?

Regards
By: Eric Romang / DCLUX (eromang) 2006-10-24 12:02:50

Also,

Could you put export MALLOC_CHECK_=1 into your /etc/profile or init.d script

NOTES : If MALLOC_CHECK_ is explicitly set a value other than 0, this causes glibc to perform more tests that are more extensive than the default, and may impact performance.

Also in your /etc/profile modify the value unlimit -S -c 0 to unlimit -S -c unlimited to get core files.

Regards.


By: Mark Hampton (mhampton) 2006-10-24 12:12:27

I'm only using SIP.

Thankyou.  I'll try the MALLOC_CHECK_=1
By: Serge Vecher (serge-v) 2006-10-26 09:29:18

mhampton: please make sure that you are:
1) building asterisk with 'make dont-optimize'. This will turn off compiler optimizations and correctly reference line # in the source.
2) Posting bt's as attachments, not inline.
3) Testing asterisk 1.2.13.

Thanks and good luck with trackign the problem down.
By: Mark Hampton (mhampton) 2006-11-06 00:27:13.000-0600

Ok, I have an update.  I disables hyperthreading in /boot/grub/grub.conf , and the memory-related crashes have gone down significantly.  I'm still getting crashes, but I'm happier with the reduced crash-rate.  I only had two today from four servers.  Here's a sample of the stack traces now that hyper-threading is disabled:

#0  0x009817a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x009c67a5 in raise () from /lib/tls/libc.so.6
#2  0x009c8209 in abort () from /lib/tls/libc.so.6
#3  0x009fa71a in __libc_message () from /lib/tls/libc.so.6
#4  0x00a011c0 in _int_free () from /lib/tls/libc.so.6
ASTERISK-1  0x00a0133a in free () from /lib/tls/libc.so.6
ASTERISK-2  0x080acb1e in ast_rtp_destroy (rtp=0xac5ff4) at rtp.c:1095
ASTERISK-3  0x0030ad90 in __sip_destroy (p=0xb731ffe0, lockowner=1) at chan_sip.c:2137
ASTERISK-4  0x0034317a in do_monitor (data=0x0) at chan_sip.c:11560
ASTERISK-5  0x00b53371 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-6 0x00a66ffe in clone () from /lib/tls/libc.so.6


#0  0x002d47a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x003197a5 in raise () from /lib/tls/libc.so.6
#2  0x0031b209 in abort () from /lib/tls/libc.so.6
#3  0x0034d71a in __libc_message () from /lib/tls/libc.so.6
#4  0x003537f4 in malloc_consolidate () from /lib/tls/libc.so.6
ASTERISK-1  0x00354643 in _int_malloc () from /lib/tls/libc.so.6
ASTERISK-2  0x00356401 in malloc () from /lib/tls/libc.so.6
ASTERISK-3  0x080a4780 in ast_cdr_alloc () at cdr.c:459
ASTERISK-4  0x0806a6e8 in __ast_request_and_dial ()
   at pbx.c:4995
ASTERISK-6 0x00b13208 in attempt_thread (data=0xb7b32b18) at pbx_spool.c:266
ASTERISK-7 0x00476371 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-8 0x003b9ffe in clone () from /lib/tls/libc.so.6
By: Serge Vecher (serge-v) 2007-02-22 15:50:40.000-0600

any changes with 1.2.15 or 1.4 svn?
By: callguy (callguy) 2007-02-22 21:12:11.000-0600

We are also experiencing the same issue (similarly loaded system w/the same glibc version on centos). We are still experiencing it w/1.2.15 (and have seen it for many versions prior).

We are testing w/1.4 now, but the verdict is still out (the crashes only happen once a week or so for us).
By: quid246 (quid246) 2007-03-09 11:29:19.000-0600

I am experiencing this in bug in CentOS 4.1 running v1.2.16, Dual Opteron 244.  Compiled and installed off the shelf.... Zaptel 1.2.15/LibPRI 1.2.4/Asterisk 1.2.16

I don't have extensive log files, but here is what was found it /var/log/messages

Mar  9 16:31:28 iax asterisk: *** glibc detected *** free(): invalid next size (fast): 0xb7902d58 ***
Mar  9 16:35:01 iax safe_asterisk: Parsing /etc/asterisk/asterisk.conf
Mar  9 16:35:01 iax asterisk: safe_asterisk startup succeeded

Nothing unusual in the Asterisk log files... it just seem to have died.


By: Mark Hampton (mhampton) 2007-03-16 21:40:43

Good news:  Switched to 1.4.1 last weekend on our dual-core Xeon 3060 server, and it didn't crash once.  Not even with 250 simultaneous calls in progress.  

Our dual-core Xeon 5050 server running 1.2.13 crashed several times over the same period with 125 simultaneous calls.

As far as I'm concerned, 1.4.1 rocks!
By: Serge Vecher (serge-v) 2007-03-19 08:24:37

thanks, we've worked hard on making it rock :)

other reporters: if you are still able to reproduce this bug with 1.4.1, please feel free to open a new bug mentioning a reference to this one with pertaining debug info.