Bug 55375 - StackOverflowError with ModuleController in Non-GUI mode if its name is the same as the target node
StackOverflowError with ModuleController in Non-GUI mode if its name is the s...
Status: REOPENED
Product: JMeter
Classification: Unclassified
Component: Main
2.9
All All
: P2 normal (vote)
: ---
Assigned To: JMeter issues mailing list
:
: 57392 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2013-08-07 08:18 UTC by christopher.roscoe
Modified: 2015-02-15 18:00 UTC (History)
2 users (show)



Attachments
The test to reproduce the error. The log file. (2.18 KB, application/zip)
2013-08-07 08:18 UTC, christopher.roscoe
Details
Test Plan showing another way for issue to occur (4.65 KB, text/plain)
2013-08-07 12:43 UTC, Philippe Mouawad
Details
Patch proposal to detect recursivity (3.91 KB, patch)
2013-12-18 19:59 UTC, Philippe Mouawad
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description christopher.roscoe 2013-08-07 08:18:36 UTC
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)
...
Comment 1 Sebb 2013-08-07 08:36:31 UTC
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?
Comment 2 Sebb 2013-08-07 10:22:49 UTC
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
Comment 3 Philippe Mouawad 2013-08-07 12:43:32 UTC
Created attachment 30686 [details]
Test Plan showing another way for issue to occur
Comment 4 Sebb 2013-08-07 14:30:08 UTC
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.
Comment 5 Philippe Mouawad 2013-12-18 19:59:39 UTC
Created attachment 31131 [details]
Patch proposal to detect recursivity
Comment 6 Sebb 2013-12-19 02:24:20 UTC
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.
Comment 7 Philippe Mouawad 2013-12-19 17:10:53 UTC
(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.
Comment 8 Philippe Mouawad 2013-12-19 17:13:30 UTC
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.
Comment 9 Sebb 2013-12-19 18:07:50 UTC
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?
Comment 10 Philippe Mouawad 2013-12-19 20:58:30 UTC
(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?
Comment 11 Philippe Mouawad 2015-02-15 18:00:26 UTC
*** Bug 57392 has been marked as a duplicate of this bug. ***