Summary: | ASTERISK-20283: Files descriptors for dummy channels need to be set to -1 | ||
Reporter: | Gareth Palmer (gareth) | Labels: | |
Date Opened: | 2012-08-20 20:12:26 | Date Closed: | 2012-08-29 14:41:07 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/General |
Versions: | SVN 11.0.0-beta1 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Attachments: | ( 0) svn-371580.patch | |
Description: | ast_dummy_channel_alloc doesn't set the file descriptors for the newly created channel to -1, instead they are left as 0 which is a valid file descriptor. Dummy channels usually aren't read from, but functions like SHELL and CURL use autoservice on the channel. Without the patch the following is printed to the console: ERROR[10552]: channel_internal_api.c:1095 ast_channel_internal_alert_read: Alertpipe on channel lost O_NONBLOCK?!! WARNING[10552]: channel.c:3980 __ast_read: No read routine on channel WARNING[10549]: channel.c:1330 __ast_queue_frame: Unable to write to alert pipe on (qlen = 0): Bad file descriptor! Patch initializes the file descriptors using the same code for normal channel allocations. Bug us minor because the function's output is returned correctly. | ||
Comments: | By: Richard Mudgett (rmudgett) 2012-08-20 21:03:46.583-0500 Dummy channels have their own destructor since dummy channels do not initialize as much of the channel structure. Does the dummy channel destructor actually close those files? By: Gareth Palmer (gareth) 2012-08-20 21:10:17.801-0500 No, the dummy channel doesn't try and close those file descriptors. The comment in the patch is also a cut'n'paste of what is in __ast_channel_alloc_ap. I can rewrite it to say something like: "Initialize the file descriptors to -1 just in case autoservice is called on the channel or something tries to read frames from it" By: Richard Mudgett (rmudgett) 2012-08-20 21:14:20.328-0500 That would be clearer since dummy channels should normally not be using them. By: Gareth Palmer (gareth) 2012-08-20 21:22:39.033-0500 I have replaced the patch with one containing a better comment. |