[Home]

Summary:ASTERISK-06214: Realtime lookup failure causes crash?
Reporter:alric (alric)Labels:
Date Opened:2006-01-29 09:37:29.000-0600Date Closed:2006-05-09 10:35:02
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Asterisk_Crash.rtf
( 1) BT_-_3-22-06.txt
( 2) convert_mp3_to_gsm.sh
Description:I don't know exactly what this debug output means, but shortly after these errors (attached in file) were seen in the messages log, asterisk crashed.  OS is CentOS 4.2 Final, and the only addon we used was format_mp3.  SIP peers, voicemail, and extensions (not extensions.conf, but our internal extensions) are pulled from DB via the Realtime engine from ODBC with MySQL as the backend DB.  We use Polycom 501 IP phones, and most of the calls come through app_queue to those phones.  This PBX is in production, so I couldn't try to reproduce the issue.
Comments:By: Jared Smith (jsmith) 2006-01-31 14:15:39.000-0600

Did the crash create a core file?  If so, please post a gdb backtrace so that we can try to find the culprit.  If not, make sure Asterisk is setup to create core files on crashes :-)

Also, you could try updating to 1.2.4 and see if that helps.
By: Jared Smith (jsmith) 2006-01-31 14:18:26.000-0600

My bad, you did post the backtrace... Sorry about that.  It looks like it might be a malformed SQL query... MySQL is complaining about looking up an extension named 'h (yes, that's apostrophe-h).
By: alric (alric) 2006-02-03 13:37:50.000-0600

I guess this could be related to the memory leak in some way.  But without knowing exactly whats going on in there its just speculation.
By: Mark Spencer (markster) 2006-02-20 08:20:25.000-0600

format_mp3 should not be used since it can introduce memory corruption.  Can you reproduce without format_mp3 and provide another backtrace?
By: alric (alric) 2006-02-27 07:59:52.000-0600

Alright.  I'm pretty sure I have some more core files laying around, and we don't use format_mp3 anymore (converted sound files to use native).  I can probably get this today or tomorrow.
By: alric (alric) 2006-03-22 15:26:58.000-0600

I believe this just happened again.  Attached a new BT.  I still have this core file, so I can run more gdb tests on it if necessary.
By: alric (alric) 2006-03-22 15:28:50.000-0600

A few minutes before the crash (from /var/log/asterisk/messages) was this:

Mar 22 15:10:06 WARNING[19464] res_odbc.c: SQL Execute returned an error -1: HY000: [unixODBC][TCX][MyODBC]Lost connection to M
ySQL server during query (67)
Mar 22 15:10:06 WARNING[19464] res_odbc.c: SQL Execute returned an error -1: 00000: [unixODBC][TCX][MyODBC]Lost connection to M
ySQL server during query (67)
Mar 22 15:10:06 WARNING[19464] res_config_odbc.c: SQL Execute error!
[SELECT * FROM extensions_table WHERE exten LIKE ? AND context = ? AND priority = ? ORDER BY exten]

Mar 22 15:10:09 WARNING[19495] res_odbc.c: SQL Execute returned an error -1: 42000: [unixODBC][TCX][MyODBC]You have an error in
your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''1034'' at l
ine 1 (175)
Mar 22 15:10:09 WARNING[19495] res_odbc.c: SQL Execute returned an error -1: 00000: [unixODBC][TCX][MyODBC]You have an error in
your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''1034'' at l
ine 1 (175)
Mar 22 15:10:09 WARNING[19495] res_config_odbc.c: SQL Execute error!
[SELECT * FROM voicemail_users WHERE mailbox = ?]

Beyond that, nothing else seems vaguely related.
By: Joshua C. Colp (jcolp) 2006-03-22 16:38:27.000-0600

Can you check memory usage on the machine? That backtrace is very weird... and shouldn't happen under normal circumstances. It's trying to allocate memory for a translation path for signed linear/ulaw conversion.
By: alric (alric) 2006-03-22 16:48:17.000-0600

I also got about a million of this line about 10-15 minutes before the crash:

Mar 22 14:48:07 WARNING[16511] chan_sip.c: Asked to transmit frame type 64, while native formats is 4 (read/write = 4/4)

Checking mem utilization:
            total       used       free     shared    buffers     cached
Mem:        513992     486688      27304          0      58392     318064
-/+ buffers/cache:     110232     403760
Swap:       498004        140     497864
By: alric (alric) 2006-03-22 16:51:02.000-0600

Oh also, this is on version 1.2.5 now instead of 1.2.3.
By: Serge Vecher (serge-v) 2006-05-01 16:20:24

Alric: can you please provide a backtrace from v.1.2.7.1?

As a side note, I would not recommend to use format_mp3 in a production enviroment. You are better off converting those mp3s to a raw format. Please refer the wiki on voip-info.org
By: Serge Vecher (serge-v) 2006-05-09 10:34:13

Again, format_mp3 at this point is not recommended for production environments. I've attahced a conversion script to make it easy for you.

If you are able to reproduce this issue with the most recent 1.2 branch code, please upload a new backtrace from Asterisk compiled with 'make dont-optimize'

Thanks.