Summary:ASTERISK-02987: Read() exists non-zero on timeout
Reporter:rusty500 (rusty500)Labels:
Date Opened:2004-12-14 12:00:00.000-0600Date Closed:2008-01-15 15:17:22.000-0600
Versions:Frequency of
Environment:Attachments:( 0) mydiff.txt
Description:Many cases exist in a macro where you'll want to read input, then if input is blank, loop back to read.

When input is blank (user enters no digits), Read() exits non-zero:

Spawn extension (macro-connect-agent, s, 11) exited non-zero on 'IAX2/USER@IP:63223/10' in macro 'connect-agent'

Of course this causes the macro to exit, which causes some major problems with the way applications are intended to work.

I'm sure this is not the intended behavior.  This was working properly in an 11/04/2004 CVS version, but is no longer working in most of the recent CVS versions, nor does it seem to work in 1-0_stable.

Comments:By: rusty500 (rusty500) 2004-12-14 12:03:05.000-0600

Just thought you might want to see the macro definition:

; Noops reserved for future functionality
exten => s,1,Noop
exten => s,2,Noop
exten => s,3,Noop
exten => s,4,Noop
exten => s,5,Noop
exten => s,6,Noop
exten => s,7,Noop
exten => s,8,Noop
exten => s,9,Noop
exten => s,10,Noop
exten => s,11,Read(XInput,call-holding-prompt,1)
exten => s,12,GotoIf(${XInput}?13:10)

Debug data shows asterisk killing the macro at line 11 due to Read() exiting non-zero.

By: Tilghman Lesher (tilghman) 2004-12-14 12:50:03.000-0600

app_read has not been changed since September.  I suspect you have version skew.  Try doing a 'make clean install' and restarting Asterisk.

By: rusty500 (rusty500) 2004-12-14 16:04:53.000-0600

I have already tried fully removing asterisk including modules, make clean, recompiling, and reinstalling.

I have even tried installing on a fresh server that has never had asterisk installed before.

This problem persists.  It may not be easily noticed since most of the time, if dealing with a read application, the caller will actually enter digits.

Also, I do believe that if this is a real bug (I can't seem to get it to go away, except if I revert to CVS versions from 11/14 and before (after 11/14 might work, but the current version does not work), that it does qualify as a major bug.

This site defines a major bug as:

A bug which completely prevents Asterisk from operating in a method that it normally is expected to operate -- and particularly if it cannot be reasonably worked around -- is MAJOR. Significant protocol violations that are not simply policy decisions are MAJOR.

If you can do a quick trial of the extension code that I sent you, I think you'll be able to reproduce this one.  It seems to match the description of "MAJOR" because it does prevent asterisk from handling this situation properly, and when dealing with a call announce application, there is no reasonable workaround that I can see after doing quite a bit of research.


By: Tilghman Lesher (tilghman) 2004-12-14 17:13:51.000-0600

The source to app_read, which hasn't changed since September, makes it very clear:  an empty response is to return non-zero:

               res = ast_app_getdata(chan, filename, tmp, maxdigits, 0);
               if (res > -1) {
                       pbx_builtin_setvar_helper(chan, varname, tmp);
                       ast_verbose(VERBOSE_PREFIX_3 "User entered '%s'\n", tmp);
               } else {
                       ast_verbose(VERBOSE_PREFIX_3 "User entered nothing\n");

By: rusty500 (rusty500) 2004-12-14 17:22:54.000-0600

Forgive me, you are correct about app_read (last time it was modified was in December), however may there have been some modifications to app_macro or something else that is causing the macro to exist after a non-zero status on a Read()?  I am neither seeing the "exited non-zero" messages on the 11/14 CVS version, nor am I seeing the macro terminate (it loops as it should).

I guarantee that if you try to reproduce this, you will be able to.

I do apologize if I've misreported this as an app_read error rather than app_macro or another application that is causing this.


By: rusty500 (rusty500) 2004-12-14 17:23:41.000-0600

Oops, I meant to say that you were correct about app_read, and that it was last modified in September (not December)... a bit out of it today :-).

By: Mark Spencer (markster) 2004-12-14 23:32:19.000-0600

I think it was erroneous and an oversight for app_read to return non-zero upon a timeout.  It's been fixed in CVS head, but I think russell will likely have to do some thing about whether this should go in stable or not.

By: rusty500 (rusty500) 2004-12-15 00:04:40.000-0600


Thanks for your response.  I thought something was a little off.

If you meant that you wanted me to test it before committing changes to the stable release, I already have.  Seems to be fixed :-).

Thanks, Mark -- both for a great piece of software and for being so on top of fixing things.

Read() now works as it should.  You can close this bug again (only way I could reply was to re-open).


PS: Corydon, changes to the Karma would be appreciated -- I don't feel that I misrepresented the bug when posting -- IMHO it does cause Asterisk to work in a way that it should not (and it's not just a simple issue of protocol violations, etc.).

By: zoa (zoa) 2004-12-15 02:44:51.000-0600

closed on user request

By: Russell Bryant (russell) 2004-12-15 13:55:42.000-0600

Please don't mark bugs as closed.  Please just mark it as resolved instead.  That is how I know that I need to look at it for the stable branch.  Otherwise, it is very likely that I will totally miss it.


By: Russell Bryant (russell) 2004-12-19 20:44:31.000-0600

fixed in 1.0

By: Digium Subversion (svnbot) 2008-01-15 15:16:39.000-0600

Repository: asterisk
Revision: 4450

U   trunk/apps/app_read.c

r4450 | markster | 2008-01-15 15:16:38 -0600 (Tue, 15 Jan 2008) | 2 lines

Fix silly read problem which would hang up if nobody called (bug ASTERISK-2987)



By: Digium Subversion (svnbot) 2008-01-15 15:17:22.000-0600

Repository: asterisk
Revision: 4499

U   branches/v1-0/apps/app_read.c

r4499 | russell | 2008-01-15 15:17:21 -0600 (Tue, 15 Jan 2008) | 2 lines

don't return -1 if user enters nothing (bug ASTERISK-2987)