Summary:ASTERISK-08515: ALSA output causes Seg Fault
Reporter:edgreenberg (edgreenberg)Labels:
Date Opened:2007-01-08 08:34:53.000-0600Date Closed:2007-02-15 20:03:35.000-0600
Versions:Frequency of
Description:Was dialing from the console and call was connecting with OSS output. Switched modules.conf to noload=>oss (in order to use alsa) and got seg fault on audio output.


Asterisk Ready.
*CLI> dial 014089830588
The 'dial' command is deprecated and will be removed in a future release. Please use 'console dial' instead.
*CLI>     -- Executing [014089830588@local:1] Dial("ALSA/hw:0,0", "SIP/fr01/014089830588") in new stack
   -- Called fr01/014089830588
   -- SIP/fr01-083e1508 is making progress passing it to ALSA/hw:0,0
[Jan  8 06:25:05] WARNING[21725]: chan_alsa.c:770 alsa_indicate: Don't know how to display condition 14 on ALSA/hw:0,0
   -- SIP/fr01-083e1508 is ringing
   -- SIP/fr01-083e1508 answered ALSA/hw:0,0
<< Console call has been answered >>
[Jan  8 06:25:06] WARNING[21725]: utils.c:725 tvfix: warning too large timestamp -14221443.9699231
[Jan  8 06:25:06] WARNING[21725]: utils.c:725 tvfix: warning too large timestamp -14221443.9699231
Segmentation fault
Comments:By: edgreenberg (edgreenberg) 2007-01-08 08:36:10.000-0600

This is with Fedora Core 6 on Dell Latitude D810 laptop (dual core 2.33).

By: Serge Vecher (serge-v) 2007-01-08 14:39:38.000-0600

ed, can you please upload a backtrace?

By: edgreenberg (edgreenberg) 2007-01-08 16:15:56.000-0600

#0  __ast_read (chan=0x90928e8, dropaudio=0) at channel.c:2074
#1  0x08094e83 in waitstream_core (c=0x90928e8, breakon=0xc258b0 "",
   forward=0x811a23b "", rewind=0x811a23b "", skip_ms=0, audiofd=-1,
   cmdfd=-1, context=0x0) at file.c:1029
#2  0x080951ca in ast_waitstream (c=0x90928e8, breakon=0xc258b0 "")
   at file.c:1093
#3  0x00c252b4 in playback_exec (chan=0x90928e8, data=0xb7a27f28)
   at app_playback.c:434
#4  0x080be6c8 in pbx_extension_helper (c=0x90928e8, con=0x0,
   context=0x9092a68 "local", exten=0x9092ab8 "#", priority=1, label=0x0,
   callerid=0x0, action=E_SPAWN) at pbx.c:505
ASTERISK-1  0x080c036c in __ast_pbx_run (c=0x90928e8) at pbx.c:2245
ASTERISK-2  0x080c12ae in pbx_thread (data=0x90928e8) at pbx.c:2556
ASTERISK-3  0x080eb82b in dummy_start (data=0x9092d90) at utils.c:545
ASTERISK-4  0x433ee3db in start_thread () from /lib/libpthread.so.0
ASTERISK-5  0x4334806e in clone () from /lib/libc.so.6

By: Joshua C. Colp (jcolp) 2007-01-24 20:22:59.000-0600

The backtrace provided shows an issue in app_playback but I don't see it in use at all on the call you gave - can you please provide a full backtrace with a newer checkout? thread apply all bt - thanks.

By: edgreenberg (edgreenberg) 2007-01-24 21:53:16.000-0600

I will try to get this for you by end of week. I have limited internet connectivity right now.

By: edgreenberg (edgreenberg) 2007-02-09 12:52:55.000-0600

I have had trouble with this.. a few times, I 'updated' and couldn't get a working build. Now I have a working build. I will try to get a test for you by end of weekend.

By: edgreenberg (edgreenberg) 2007-02-09 13:09:42.000-0600

OK, this seems to be resolved in the latest svn. There was a comment that stated that there was no reason to use app_playback, but this seems incorrect. When the call connects, the system plays a little chirp through app_playback.

We learn -- every day.

Pleaes close bug.

By: Serge Vecher (serge-v) 2007-02-09 13:21:28.000-0600

can you please provide the details as to when is app_playback required (so this can be documented)?

By: Joshua C. Colp (jcolp) 2007-02-15 20:03:35.000-0600

Since this is already fixed I'm closing out this bug. If you still have the info for serge feel free to add it, but I think you just misunderstood what I said... but that's okay!