[asterisk-bugs] [JIRA] (ASTERISK-29947) testsuite: Premature shutdown causes tests to fail
N A (JIRA)
noreply at issues.asterisk.org
Thu Mar 3 13:56:06 CST 2022
[ https://issues.asterisk.org/jira/browse/ASTERISK-29947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258259#comment-258259 ]
N A edited comment on ASTERISK-29947 at 3/3/22 1:54 PM:
--------------------------------------------------------
Yes, I have, the test will still be running and Originate() will fail due to an "active shutdown", and as such channel allocations fail.
Basically, the test is walking dead at that point.
e.g.
[Mar 3 14:39:00] VERBOSE[4143848][C-00000003] pbx.c: Executing [s2 at test-anoncallreject:6] Originate("PJSIP/autotest2-00000001", "Local/22s3test-anoncallreject at orig-again,app,Wait,5") in new stack
[Mar 3 14:39:00] DEBUG[4143848][C-00000003] app_originate.c: Originating call to 'Local/22s3test-anoncallreject at orig-again' and connecting them to Wait(5)
[Mar 3 14:39:00] WARNING[4143848][C-00000003] channel.c: Channel allocation failed: Refusing due to active shutdown
[Mar 3 14:39:00] WARNING[4143848][C-00000003] core_unreal.c: Unable to allocate owner channel structure
I've found this happening every single time there is a problem like this. Why is there an "active shutdown"? I certainly didn't tell it to. It's the test suite telling it to.
It seems the logic to detect that a test is over is faulty.
I think this one is actually "Major" because if tests can just get prematurely killed when UserEvent is called, then that's a serious problem which pretty much makes it impossible to run tests without rewriting them to use only a single UserEvent.
was (Author: interlinked):
Yes, I have, the test will still be running and Originate() will fail due to an "active shutdown", and as such channel allocations fails.
Basically, the test is walking dead at that point.
e.g.
[Mar 3 14:39:00] VERBOSE[4143848][C-00000003] pbx.c: Executing [s2 at test-anoncallreject:6] Originate("PJSIP/autotest2-00000001", "Local/22s3test-anoncallreject at orig-again,app,Wait,5") in new stack
[Mar 3 14:39:00] DEBUG[4143848][C-00000003] app_originate.c: Originating call to 'Local/22s3test-anoncallreject at orig-again' and connecting them to Wait(5)
[Mar 3 14:39:00] WARNING[4143848][C-00000003] channel.c: Channel allocation failed: Refusing due to active shutdown
[Mar 3 14:39:00] WARNING[4143848][C-00000003] core_unreal.c: Unable to allocate owner channel structure
I've found this happening every single time there is a problem like this. Why is there an "active shutdown"? I certainly didn't tell it too. It's the test suite telling it too.
It seems the logic to detect that a test is over is faulty.
I think this one is actually "Major" because if tests can just get prematurely killed when UserEvent is called, then that's a serious problem which pretty much makes it impossible to run tests without rewriting them to use only a single UserEvent.
> testsuite: Premature shutdown causes tests to fail
> --------------------------------------------------
>
> Key: ASTERISK-29947
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29947
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Tests/testsuite
> Affects Versions: 18.9.0
> Environment: Debian 11
> Reporter: N A
> Assignee: Unassigned
>
> A problem I've been noticing for a while is that sometimes the test suite will prematurely kill a test if a UserEvent for success has been received, even if the success count hasn't yet hit the required count.
> For instance, I have a test that aborts after 1 success user event, when 2 are required, and then it fails because Asterisk got shut down even though the test was still running, and obviously 1 is not 2 so the test fails.
> If I simply comment out the success user event, the test runs to completion successfully, but obviously this doesn't make it work.
> I have ensured that there is always a channel up at all parts of the test so it isn't the case that Asterisk is shutting down because the test suite has detected there are no channels. Instead, it seems to be reacting in a majorly buggy way.
> The only workaround is simply to include at most 1 success user event, which kind of defeats the point of trying to add rich tests to the test suite in the first place.
> Granted, this doesn't happen with every test, but it seems to with a large number.
> In the past, I've rewritten tests to only include 1 success, to improve reliability, but it seems in some cases it will just consistently fail like this.
> ```
> root at pbxdev:/usr/src/testsuite# ./runtests.py --test=tests/intertest/anoncallreject --timeout=60
> Running tests for Asterisk (run 1 of 1)...
> Tests to run: 1 * 1 time(s) = 1 Maximum test inactivity time: 60 sec.
> --> Running test 'tests/intertest/anoncallreject' ...
> Making sure Asterisk isn't running ...
> Making sure SIPp isn't running...
> Running tests/intertest/anoncallreject ...
> [Mar 03 14:39:02] WARNING[4143745]: asterisk.ami:208 __check_result: Event occurred 1 times, which is out of the allowable range
> [Mar 03 14:39:02] WARNING[4143745]: asterisk.ami:209 __check_result: Event description: {'count': 2, 'conditions': {'match': {'UserEvent': 'LineTest', 'Event': 'UserEvent'}}, 'requirements': {'match': {'Result': 'Pass'}}}
> Test tests/intertest/anoncallreject failed
> <?xml version="1.0" encoding="utf-8"?>
> <testsuites>
> <testsuite errors="0" failures="1" name="AsteriskTestSuite" tests="1" time="18.62" timestamp="2022-03-03T14:38:43 EST">
> <testcase classname="intertest" name="anoncallreject" time="18.62">
> <failure>Running tests/intertest/anoncallreject ...
> [Mar 03 14:39:02] WARNING[4143745]: asterisk.ami:208 __check_result: Event occurred 1 times, which is out of the allowable range
> [Mar 03 14:39:02] WARNING[4143745]: asterisk.ami:209 __check_result: Event description: {'count': 2, 'conditions': {'match': {'UserEvent': 'LineTest', 'Event': 'UserEvent'}}, 'requirements': {'match': {'Result': 'Pass'}}}
> </failure>
> </testcase>
> </testsuite>
> </testsuites>
> ```
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list