Summary: | ASTERISK-18974: trunk: unable to run unit tests | ||
Reporter: | Paul Belanger (pabelanger) | Labels: | |
Date Opened: | 2011-12-06 15:57:33.000-0600 | Date Closed: | 2011-12-12 13:42:23.000-0600 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Tests/General |
Versions: | SVN | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Attachments: | ( 0) backtrace-threads.txt ( 1) backtrace-threads.txt2 ( 2) lock.txt ( 3) lock.txt2 | |
Description: | See attached locks and backtrace. | ||
Comments: | By: Paul Belanger (pabelanger) 2011-12-06 15:59:45.651-0600 Steps to reproduce {code} $ asterisk -ng $ asterisk -rx "tests execute all" {code} By: Matt Jordan (mjordan) 2011-12-08 11:44:40.972-0600 Note that since this fails in the time test, you really should enable all of the tests in menuselect (or at least that one) in order to reproduce it By: Matt Jordan (mjordan) 2011-12-08 15:32:21.635-0600 Paul - this isn't failing locally for me on Fedora 14. What OS are you running? By: Paul Belanger (pabelanger) 2011-12-09 10:57:53.836-0600 Ubuntu 10.04 By: Matt Jordan (mjordan) 2011-12-09 13:41:46.794-0600 Okay - the key here appears to be connecting to a remote Asterisk instance and executing the test, as opposed to connecting directly. This appears to have been caused by https://reviewboard.asterisk.org/r/1599/ By: Matt Jordan (mjordan) 2011-12-12 09:45:34.260-0600 In testing with Tilghman, it was discovered that this occurs when you execute the unit tests without any verbose flag. It appears as if the thread ID being used by the unit test to reference the inotify daemon is no longer set to the correct value, and is not set to NULL. By: Matt Jordan (mjordan) 2011-12-12 13:40:56.190-0600 Although I don't like it, I backed out Tilghman's patch for now. Hopefully we can figure out what in it was causing the remote console issues / unit test issues and put it back in. By: Matt Jordan (mjordan) 2011-12-12 13:42:23.857-0600 Closing this as suspended for now, since we backed out what appeared to be causing this problem. If the patch gets reintroduced *and* we see it exhibiting the same behavior, then I guess we could reopen this if we felt like it. |