Floating point exception

Asterisk Asterisk Support
#1

I’m running 1.4.23 and trying to figure out why asterisk is crashing occasionally. It happened twice today. The events in the logs just prior to the crash are never the same. I don’t see anything there that suggests a problem (at least not to me). Today, when it disconnected I saw this on the console.

Disconnected from Asterisk server
/usr/sbin/safe_asterisk: line 111: 19523 Floating point exception(core dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk ${CLIARGS} ${ASTARGS} >&/dev/${TTY} </dev/${TTY}
Asterisk ended with exit status 136
Asterisk exited on signal 8.
Automatically restarting Asterisk.
root@um-882 /var/log/asterisk> mpg123: no process killed

I have no idea where to start debuging this. I assume the floating point exception is what is causing the problem. We’re running 1.4.23 with rx_fax. Any ideas?

#2

Read docs/backtrace.txt and then submit the results to issues.asterisk.org.

First make sure that it was built for the correct processor type.

#3

In this case, I wouldn’t start with core files.
Could you start with hardware change?

#4

The change to the server was a memory upgrade from 1gb to 2gb about two weeks ago. I believe this was happening before then. Not sure how to check the processor type it was built for, but it was complied on this machine. The machine has twp Pentium 4’s, and it is running…

root@um-882 /tmp> uname -a
Linux um-882.xxxxxxxx.com 2.6.9-78.0.13.ELsmp #1 SMP Wed Jan 14 16:12:46 EST 2009 i686 i686 i386 GNU/Linux

Does that help, or do I need to look further at the processor?

Backtrace says something about the core dump being not very useful if Asterisk is complied without the DONT_OPTIMIZE flag, and it was complied without the flag. I do have a core dump from the last time this happened. Should I submit it to issues even though I didn’t have DONT_OPTIMIZE?

I have recomplied with DON_OPTIMIZE, but haven’t installed… After I do that I will have to wait for it to die again to get another dump. So, I wonder if I should go ahead and submit what I’ve got.

Thanks for the suggestions!

#5

They don’t normally look at optimised ones, because too much information is lost.

I think the “check the machine first” comment was suggesting that you eliminate the possibility of faulty hardware.

#6

Ok, I will hold off posting until I have optimize turned off in production. Any reason to not just leave it that way permanently? Does optimization use less resources? I saw a suggestion somewhere that I also turn on debug threads, so I’ve built it with that flag as well.

As for hardware, it’s a basic machine, no line cards, etc. I originally used zt_dummy for timing, but have upgraded to dahdi_dummy. I’m also using app_rxfax. Any need for worry there?

Thanks, again for the suggestions. I will “make install” tonight, and post to issues if I get another dump.