| Summary: | ASTERISK-04517: [patch] #include "directory" causes asterisk hang with 100%cpu | ||
| Reporter: | Tzafrir Cohen (tzafrir) | Labels: | |
| Date Opened: | 2005-07-04 14:59:14 | Date Closed: | 2011-06-07 14:10:28 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/Configuration |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) include_dir_hang_fix.diff.txt ( 1) include_dir_hang_fix.head.diff.txt | |
| Description: | Asterisk fails to handle read errors in configuration files. When it gets a read error it will simply retry. One test scenario: mkdir /etc/asterisk/testdir echo '#include "testdir"' >> /etc/logger.conf # or whatever asterisk -rx reload # or any other method to cause asterisk to read that config file Result: asterisk hangs in a 100% CPU loop. read(2) returns -1 with the error EISDIR. If asterisk is in real-time priority the system locks up pretty nicely. The attached patch adds a check for a possible error from fgets. It is quite crude, though. Are there valid reasons for retrying after a read error rather than giving up? Or should there be a separate check for ferror and an error there? ****** ADDITIONAL INFORMATION ****** Can't disaclim at the moment, I'll have to wait for my employer to fax it tommorow... The patch is vs. 1.0.9 because I don't have any working HEAD installation to test on. The seconf patch (.head) is a manually edited patch that applies. But then again, the basic structure there hasn't changed. | ||
| Comments: | By: Kevin P. Fleming (kpfleming) 2005-07-05 15:13:43 Are these patches not covered under the disclaimer already submitted two weeks ago? By: Tilghman Lesher (tilghman) 2005-07-26 23:15:09 Any update on the disclaimer? No disclaimer and we'll have to close the bug. By: Michael Jerris (mikej) 2005-07-26 23:26:33 suspended until the disclaimer is worked out. | ||