[Home]

Summary:ASTERISK-03250: Asterisk Segmentation Fault - layer3.c/mpg123
Reporter:muppetmaster (muppetmaster)Labels:
Date Opened:2005-01-11 02:19:28.000-0600Date Closed:2005-01-13 23:17:52.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I recently switched from using mpg123 to using the
built-in format_mp3 for MusicOnHold.  After playing a
song (which I adapted as perscribed to 8Khz/mono mp3
with lame) for about 30 seconds, I get static in the
earpiece and then:

Jan 11 08:59:08 WARNING[11039]: layer3.c:966
III_dequantize_sample: mpg123: Can't rewind stream by
10 bits!
Segmentation fault

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

I tested with an additional mp3 file (that had also been converted) and the segmentation fault occurred in the same timeframe.
Comments:By: Clod Patry (junky) 2005-01-11 03:04:15.000-0600

which mpg123 version? you need  mpg123 0.59r.
By: Andrey S Pankov (casper) 2005-01-11 06:31:50.000-0600

junky: this is about asterisk-addons/format_mp3, not mpg123... :)
By: Andrey S Pankov (casper) 2005-01-11 06:33:49.000-0600

muppetmaster: can you attach backtrace from gdb please! Core files are of little use outside your system...
By: muppetmaster (muppetmaster) 2005-01-11 06:39:00.000-0600

Please provide instructions (or a link to them) for providing the the appropriate backtrace from gdb.  Also, this indeed is concerning format_mp3.
By: Andrey S Pankov (casper) 2005-01-11 08:55:12.000-0600

Please-please-please, read the documentation _before_ submitting bugs!

http://www.digium.com/bugtracker.html (this page has a very nice summary...)
http://www.voip-info.org/wiki-Asterisk+debugging

edited on: 01-11-05 08:57
By: muppetmaster (muppetmaster) 2005-01-11 09:14:23.000-0600

I have read the documentation, but it is not clear exactly which output that you would be looking for.  So I am guessing (as it is not clear on the Wiki) that you need the output from the gdb after running the bt command).  Here it is:

(gdb) bt full
#0  0x41649c57 in load_module () from /usr/lib/asterisk/modules/format_mp3.so
No symbol table info available.
#1  0x080664ee in ast_readframe (s=0x819a280) at file.c:547
       f = Variable "f" is not available.
(gdb) bt
#0  0x41649c57 in load_module () from /usr/lib/asterisk/modules/format_mp3.so
#1  0x080664ee in ast_readframe (s=0x819a280) at file.c:547
#2  0x408ffe1f in moh_files_generator (chan=0x813de58, data=0x8113be8, len=160, samples=160)
   at res_musiconhold.c:199
#3  0x0806132e in ast_read (chan=0x813de58) at channel.c:1423
#4  0x08062c39 in ast_channel_bridge (c0=0x813de58, c1=0x813d698, config=0x41ca9ca0, fo=0x41ca9060, rc=0x41ca9064)
   at channel.c:2804
ASTERISK-1  0x409b3068 in ast_bridge_call (chan=0x813de58, peer=0x813d698, config=0x41ca9ca0) at res_features.c:896
ASTERISK-2  0x4162d9cf in dial_exec (chan=0x813de58, data=0x41caa210) at app_dial.c:1125
ASTERISK-3  0x08086dde in pbx_exec (c=0x813de58, app=0x8182b98, data=0x41caa210, newstack=1) at pbx.c:477
ASTERISK-4  0x4139f5dd in realtime_exec (chan=0x813de58, context=0x818f650 "internal_rt", exten=0x813e094 "3005",
   priority=1083181980, callerid=0x81134b8 "3004", newstack=1083181980, data=0x813de58 "SIP/3004-c65c")
   at pbx_realtime.c:204
ASTERISK-5  0x080880aa in pbx_extension_helper (c=0x813de58, con=Variable "con" is not available.
) at pbx.c:1312
ASTERISK-6 0x08089487 in ast_pbx_run (c=0x813de58) at pbx.c:1827
ASTERISK-7 0x0808b051 in pbx_thread (data=0x40900b9c) at pbx.c:2072
ASTERISK-8 0x4002a7f3 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-9 0x4019a62a in clone () from /lib/tls/libc.so.6
(gdb)

Please let me know if there is anything further I may provide on this issue.
By: Andrey S Pankov (casper) 2005-01-11 09:27:44.000-0600

It would be nice if next time you attach (not inline) your files with .txt extention here.
By: Anthony Minessale (anthm) 2005-01-11 11:28:02.000-0600

Can you please try it on the mp3 file without converting it at all
the most recent version of the format_mp3 does not need the conversion

I just want to know if the bug is related the the file that lame yields.
By: muppetmaster (muppetmaster) 2005-01-11 12:02:51.000-0600

I tested with the original mp3 file as requested, which is a 256k CBR.  At the beginning of play I got:

Jan 11 18:59:36 NOTICE[15285]: res_musiconhold.c:185 ast_moh_files_next: SIP/3004-100b Opened file 0 '/var/lib/asterisk/moh-native/radio_tarifa_argelina'
Jan 11 18:59:36 WARNING[15285]: interface.c:215 decodeMP3: Junk at the beginning of frame 49443303

But, the audio quality is much better and did not crash through the entire song and others in the directory.  Would appear to be an issue with the originally recommended encoding of 8Khz/mono.  Although still should not do a segmentation fault if a certain format is played.
By: Brian West (bkw918) 2005-01-11 12:58:14.000-0600

You should really convert them to ulaw then its not an issue.

bkw
By: twisted (twisted) 2005-01-11 23:00:40.000-0600

bkw, let's not go AROUND the bugs here, let's actually solve them.  ;)
By: Anthony Minessale (anthm) 2005-01-12 08:56:48.000-0600

The issue here is the problem could be with lame encoding the file wrong and or mpglib poorly reacting to invalid mp3 data.  It may very well be only 8k mp3's made by lame that have a problem can anyone do some testing?

perhaps post a url where we can see the original mp3 and the new one that crashes * and see if it crashes any other machines and if other machines that resample the original mp3 also produce a file that can cause a crash.  It's important to know where the problem lies.
By: Mark Spencer (markster) 2005-01-12 09:30:23.000-0600

If it's a segfault, the problem lives in mpglib, regardless of the encoder.  It's fine if mpglib doesn't want to read it, but it needs to not seg.  On the other hand, who really wants to try to go debug mpglib?  I'm certainly not.  There's a reason why in Asterisk we launch mpg123 and why format_mp3 lives in asterisk-addons and not asterisk proper.
By: Mark Spencer (markster) 2005-01-13 21:31:40.000-0600

Well not exactly fixed, but I've at least documented in the README that format_mp3 can crash with certain mp3's due to bugs in mpglib.  If someone actually wants to fix mpglib, feel free to reopen.