agi segfaults 1.2.9.1

----- Julian Lyndon-Smith <asteriskdotr.com> wrote:
> I'm sure that part of Kevin's email was cut off, and
that he meant to
> 
> say in addition was "and we'd like to be made
aware of them so that
> they 
> can be fixed in order to make asterisk an even more
reliable system"

No, it was not. It is not possible to completely validate
every set of parameters sent to every single
application/function/AGI command/etc. in Asterisk. Even if
it was possible, it's not worth the effort or the
time/memory/etc. cost it would put on the users of Asterisk.

> having reported bug #7354 earlier today, a crash when
invalid
> parameters 
> are passed to AddQueueMember

Invalid parameters are one thing, no parameter at all (when
one is clearly documented to be required) is something else
entirely. With that said, no matter how much you want to
try, there is no amount of code we can put into things like
AddQueueMember that will always guarantee that nothing bad
will happen if you specify invalid parameters.

-- 
Kevin P. Fleming
Senior Software Engineer
Digium, Inc.

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Kevin,

Slow down - it was meant to be read with a smiley. It *is*
impossible to 
manually go through all possible combinations of parameters
to make sure 
that they all work.

In regards to the AddQueueMember, I simply forgot to add
context to the 
end of the device name. I don't think that this should
cause a segfault. 
On the other hand, I wouldn't expect you to be testing for 
averyververylongcontextthatcouldbe100000000000million
characterslong either.

Julian

Kevin P. Fleming wrote:
> ----- Julian Lyndon-Smith <asteriskdotr.com> wrote:
>> I'm sure that part of Kevin's email was cut off,
and that he meant to
>>
>> say in addition was "and we'd like to be
made aware of them so that
>> they 
>> can be fixed in order to make asterisk an even more
reliable system"
> 
> No, it was not. It is not possible to completely
validate every set of parameters sent to every single
application/function/AGI command/etc. in Asterisk. Even if
it was possible, it's not worth the effort or the
time/memory/etc. cost it would put on the users of Asterisk.
> 
>> having reported bug #7354 earlier today, a crash
when invalid
>> parameters 
>> are passed to AddQueueMember
> 
> Invalid parameters are one thing, no parameter at all
(when one is clearly documented to be required) is something
else entirely. With that said, no matter how much you want
to try, there is no amount of code we can put into things
like AddQueueMember that will always guarantee that nothing
bad will happen if you specify invalid parameters.
> 

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On Wed, 2006-06-14 at 08:37 -0500, Kevin P. Fleming wrote:
> ----- Julian Lyndon-Smith <asteriskdotr.com> wrote:
> > I'm sure that part of Kevin's email was cut off,
and that he meant to
> > 
> > say in addition was "and we'd like to be
made aware of them so that
> > they 
> > can be fixed in order to make asterisk an even
more reliable system"
> 
> No, it was not. It is not possible to completely
validate every set of
> parameters sent to every single
application/function/AGI command/etc.
> in Asterisk. Even if it was possible, it's not worth
the effort or the
> time/memory/etc. cost it would put on the users of
Asterisk.

I have to say that is a piss poor attitude. Making it 100%
foolproof and
hackerproof may be too much to ask for, but simple
validation of the
parameters should be done. 

A better attitude would have been just to ask for the patch
that
validated the exec parameters.

-- 
Steven <critchbasesys.com>

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Julian Lyndon-Smith wrote:
> Kevin,
>
> Slow down - it was meant to be read with a smiley. It
*is* impossible
> to manually go through all possible combinations of
parameters to make
> sure that they all work.
>
> In regards to the AddQueueMember, I simply forgot to
add context to
> the end of the device name. I don't think that this
should cause a
> segfault. On the other hand, I wouldn't expect you to
be testing for
> averyververylongcontextthatcouldbe100000000000million
characterslong
> either.
>
Weird, I could have sworn that the context wasn't neccesary
(as in the
example shown in show application AddQueueMember in the
CLI).


_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On 6/22/06, Thomas Kenyon <digiumsanguinarius.co.uk>
wrote:
> >
> > In regards to the AddQueueMember, I simply forgot
to add context to
> > the end of the device name. I don't think that
this should cause a
> > segfault. On the other hand, I wouldn't expect
you to be testing for
> > averyververylongcontextthatcouldbe100000000000million
characterslong
> > either.
> >
> Weird, I could have sworn that the context wasn't
neccesary (as in the
> example shown in show application AddQueueMember in the
CLI).
>

 You're reading this out of context. context is required for
Local/
interfaces specified in AddQueueMember. The segfault
condition has
been corrected and you get a warning on the CLI now when you
do
something that you should not.

-- 
Bird's The Word Technologies, Inc.
http://www.btwtech.com/
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

BJ Weschke wrote:
>
> You're reading this out of context. context
is required for Local/
> interfaces specified in AddQueueMember. The segfault
condition has
> been corrected and you get a warning on the CLI now
when you do
> something that you should not.
>
When I hadn't done this (back on 1.2.5) It assumed the
context was default.


_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev