You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2013/08/07 10:18:36 UTC
[Bug 55375] New: java.lang.StackOverflowError with ModuleController
in Non-GUI mode
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
Bug ID: 55375
Summary: java.lang.StackOverflowError with ModuleController in
Non-GUI mode
Product: JMeter
Version: 2.9
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Main
Assignee: issues@jmeter.apache.org
Reporter: christopher.roscoe@braintribe.com
Created attachment 30684
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30684&action=edit
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)
...
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
--- Comment #4 from Sebb <se...@apache.org> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] java.lang.StackOverflowError with ModuleController in
Non-GUI mode
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
--- Comment #1 from Sebb <se...@apache.org> ---
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?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
--- Comment #9 from Sebb <se...@apache.org> ---
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?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
--- Comment #5 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Created attachment 31131
--> https://issues.apache.org/bugzilla/attachment.cgi?id=31131&action=edit
Patch proposal to detect recursivity
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |p.mouawad@ubik-ingenierie.c
| |om
--- Comment #3 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Created attachment 30686
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30686&action=edit
Test Plan showing another way for issue to occur
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|java.lang.StackOverflowErro |StackOverflowError with
|r with ModuleController in |ModuleController in Non-GUI
|Non-GUI mode |mode if its name is the
| |same as the target node
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
--- Comment #10 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
(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?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
--- Comment #8 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Sebb <se...@apache.org> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
--- Comment #7 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Hardware|PC |All
Resolution|FIXED |---
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55375] StackOverflowError with ModuleController in Non-GUI mode
if its name is the same as the target node
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55375
--- Comment #6 from Sebb <se...@apache.org> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.