Summary:	ASTERISK-02022: Coredump when waiting stream
Reporter:	Konstantin Prokazoff (oryx)	Labels:
Date Opened:	2004-07-15 03:47:27	Date Closed:	2004-09-25 02:26:24
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Due to different releases of libc, but 100% in RH7.3 & FBSD 5.2.1, in strchr() first argument is const char *, so diff are: @@ -892,7 +892,8 @@ -if(strchr(breakon,res)) { +if(breakon && *breakon) +if(strchr(breakon, res)) { ****** ADDITIONAL INFORMATION ****** Try padding any DTMF digits while listening to file. In my case, this are ulaw files and I working with inband DTMF transmission within H.323.
Comments:	By: Konstantin Prokazoff (oryx) 2004-07-15 04:25:21 Sorry, I forget to say, this diff for file.c. By: Olle Johansson (oej) 2004-07-15 08:42:02 Which version of Asterisk are giving you core dumps? Also, please attach "cvs diff -u of file.c" according to the instructions. By: Konstantin Prokazoff (oryx) 2004-07-15 09:01:47 cvs of 13/07/2004. diff are: --- file.c.orig Thu Jul   1 16:41:40 2004 +++ file.c      Thu Jul  15 16:33:16 2004 @@ -892,7 +892,8 @@ -if (strchr(breakon, res)) { +if(breakon && *breakon) + if(strchr(breakon, res)) { By: Mark Spencer (markster) 2004-07-15 10:49:52 You must always supply a breakon argument.  Who is calling the routine with breakon set to NULL?  That's where the bug is. By: Konstantin Prokazoff (oryx) 2004-07-15 11:07:11 Mark, I haven't called ast_waitstream with breakon=NULL, but in case if H.323 uses inband DTMF transmission and when we awaiting streamed file on channel, and if I'll press any digit on my phone, asterisk coredumps, and by gdb, it fails on segmentation fault, which occurs on strchr(), in case, if breakon="" (so, \0). That's all folks. By: Mark Spencer (markster) 2004-07-15 14:49:00 Already fixed it in CVS, the comment accidently got placed on another bug report.