Created attachment 30684 [details] The test to reproduce the error. The log file. See attached a simple jmx file to reproduce the stackoverflow. There is no problem when i start the test in GUI mode. In Non-GUI i have the following output. An error occurred: null errorlevel=1 Drücken Sie eine beliebige Taste . . . Here is how i start the test in Non-GUI mode. jmeter -n -t d:\development\workspaces\2.11.3\apache-jmeter-latest\bin\temp\stackoverflow\stackoverflow.jmx -l d:\development\workspaces\2.11.3\apache-jmeter-latest\bin\temp\stackoverflow\stackoverflow.jtl -j d:\development\workspaces\2.11.3\apache-jmeter-latest\bin\temp\stackoverflow\stackoverflow.log In the log (also attached) the last entry is the stacktrace of the java.lang.StackOverflowError. 2013/08/07 10:04:45 FATAL - jmeter.JMeter: An error occurred: java.lang.StackOverflowError at java.util.HashMap.containsKey(HashMap.java:335) at org.apache.jorphan.collections.ListedHashTree.add(ListedHashTree.java:163) at org.apache.jmeter.control.ModuleController.getReplacementSubTree(ModuleController.java:170) at org.apache.jmeter.JMeter.convertSubTree(JMeter.java:883) at org.apache.jmeter.JMeter.convertSubTree(JMeter.java:885) at org.apache.jmeter.JMeter.convertSubTree(JMeter.java:885) ...
Work-round is to rename the Module Controller so it has a different name from the target controller. May perhaps be related to Bug 47165?
Thanks for the original report and Test Case. Turned out that the Module Controller (MC) was finding itself rather than the proper target node. Fixed by not allowing the target node to be a Module Controller. URL: http://svn.apache.org/r1511236 Log: StackOverflowError with ModuleController in Non-GUI mode if its name is the same as the target node Bugzilla Id: 55375 Added: jmeter/trunk/bin/testfiles/Bug55375.csv (with props) jmeter/trunk/bin/testfiles/Bug55375.jmx (with props) jmeter/trunk/bin/testfiles/Bug55375.xml (with props) Modified: jmeter/trunk/build.xml jmeter/trunk/src/components/org/apache/jmeter/control/ModuleController.java jmeter/trunk/xdocs/changes.xml
Created attachment 30686 [details] Test Plan showing another way for issue to occur
It's picking the wrong parent controller. If you look in the drop-down list in the GUI, there are two instances of the target: Test Plan > Thread Group > reload Selecting the second one in the GUI results in a stack overflow error when running the GUI test. It looks like the non-GUI code happens to choose the wrong target - correct name, wrong instance. Note: the Test Plans that are created are identical, so the GUI test must be using additional information to identify the target controller. Not sure if it makes sense to allow multiple MC targets with the same name. If it does, then the JMX file (and drop-down list) will need to contain extra information to identify the instance. It may just be simpler to complain if the Test Plan contains multiple targets with the same name.
Created attachment 31131 [details] Patch proposal to detect recursivity
The patch effectively converts the stack overflow into an illegal state exception. The benefit is that the message reports the name offending test element (though this may not be unique). However it does not solve the issue that the non-GUI code behaves differently from the GUI code. Ideally any fix should address the different behaviour and prevent recursive calls. If the MC refused to allow multiple controllers with the same name, that should solve the behaviour difference, but it could affect some test plans. Given that at present the non-GUI code does not have sufficient information to choose the correct controller in the case of duplicates, that change is probably acceptable. The other issue is that the user may choose a target which is a parent of the MC, causing stack overflow. If controller names must be unique then this should be less likely to occur. Since such targets are useless, ideally they should be excluded from the list. This would need to be done after duplicate checking.
(In reply to Sebb from comment #6) > The patch effectively converts the stack overflow into an illegal state > exception. > The benefit is that the message reports the name offending test element > (though this may not be unique). Shall I commit it ? > > However it does not solve the issue that the non-GUI code behaves > differently from the GUI code. In fact both GUI and Non GUI behave identically except that sometimes GUI picks the first element instead of picking the second one. But if you fix it then you get a StackOverflow. > > Ideally any fix should address the different behaviour and prevent recursive > calls. Fix prevents recursive calls. > > If the MC refused to allow multiple controllers with the same name, that > should solve the behaviour difference, but it could affect some test plans. > Given that at present the non-GUI code does not have sufficient information > to choose the correct controller in the case of duplicates, that change is > probably acceptable. Not sure > > The other issue is that the user may choose a target which is a parent of > the MC, causing stack overflow. If controller names must be unique then this > should be less likely to occur. Since such targets are useless, ideally they > should be excluded from the list. This would need to be done after duplicate > checking. Could be next step.
To be clear, I think the GUI may have in fact changed the saved reference value of Module Controller. So I suspect another bug in GUI mode which gets confused when there are duplicated.
I don't see any point in applying a temporary fix. The GUI seems to remember the correct instance whilst it is active. i.e. it will run which ever is selected from the list. However, when the JMX is saved, only the name is stored. So when the JMX is reloaded, it cannot possibly know which one was previously selected. This is a fundamental problem for both GUI and non-GUI test runs. One way to fix this is to insist that controller names are unique. Another way would be to store the instance number. This could either be done for every case, or only done where there are multiple matches, or the instance number could default to the first (i.e. only store it if not the first or only instance). Requiring unique names would be more likely to break existing test plans, as the default names are not unique, so I now think it would be better to store an instance number. Making the instance default to 1 would reduce the number of test plans that needed to be updated. However it would make it more difficult to determine whether the choice was deliberate or accidental, unless the test plan version is also taken into account. So it might be better to insist that the instance number was always saved. The question then arises - what should JMeter do if the user adds another controller with the same name after the MC entry has been selected?
(In reply to Sebb from comment #9) > I don't see any point in applying a temporary fix. Ok, let's wait for a better implementation > > The GUI seems to remember the correct instance whilst it is active. > i.e. it will run which ever is selected from the list. > > However, when the JMX is saved, only the name is stored. > So when the JMX is reloaded, it cannot possibly know which one was > previously selected. > This is a fundamental problem for both GUI and non-GUI test runs. Ok, that's what I was saying. > > One way to fix this is to insist that controller names are unique. > Another way would be to store the instance number. Maybe but could be tricky to develop and maintain. > This could either be done for every case, or only done where there are > multiple matches, or the instance number could default to the first (i.e. > only store it if not the first or only instance). > > Requiring unique names would be more likely to break existing test plans, as > the default names are not unique, so I now think it would be better to store > an instance number. Making the instance default to 1 would reduce the number > of test plans that needed to be updated. However it would make it more > difficult to determine whether the choice was deliberate or accidental, > unless the test plan version is also taken into account. So it might be > better to insist that the instance number was always saved. > > The question then arises - what should JMeter do if the user adds another > controller with the same name after the MC entry has been selected?
*** Bug 57392 has been marked as a duplicate of this bug. ***
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/3180