On Mit, 2008-03-05 at 15:41 -0600, The Asterisk Development Team wrote:
> Greetings,
> 
> The Asterisk.org development team has released Asterisk 1.4.19-rc1.  This is a
> test release for 1.4.19.  The official 1.4.19 release will be made after a
> 1.4.19 release candidate goes through a few days of testing without finding any
> major regressions.

Not really a regression, but I just found out that the 1.6 bug 11914
(Redirect through AMI not working) is also present in 1.4.19-rc1. Would
be nice to have this fixed in the final 1.4.19. The problem is in
main/pbx.c:__ast_pbx_run():
        for (;;) {
            while (ast_exists_extension(c, c->context, c->exten, c->priority, c->cid.cid_num)) {
        	if ((res = ast_spawn_extension(c, c->context, c->exten, c->priority, c->cid.cid_num))) {
        	    ...
        	}
        	if (c->_softhangup == AST_SOFTHANGUP_TIMEOUT && ast_exists_extension(...)) {
        	    ...
        	// *** MISSING***: } else if (c->_softhangup == AST_SOFTHANGUP_ASYNCGOTO) { c->_softhangup = 0;
        	} else if (c->_softhangup) {
        	   ...
        	   error = 1;
        	   break;
        	}
        	c->priority++;
            } /* end while  - from here on we can use 'break' to go out */
            ...
        }

While examining the code in __ast_pbx_run(), I've noticed something
strange and I would really appreciate if someone could comment on this:
Functions like ast_explicit_goto() that modify the context, exten or
priority of an ast_channel structure do lock the channel. But it seems
that __ast_pbx_run() is accessing these values without locking the
channel - which seems rather hazardous, especially with
manager-redirects/async-gotos that can happen at any time.

-- 
Dr. Michael Neuhauser                              mailto:mike@firmix.at
Firmix Software GmbH                                  sip:mike@firmix.at
Vienna/Austria/Europe                               tel:+43-1-7890849-30
Linux Development and Services                     http://www.firmix.at/