Bug #5719
closedEFSM Test Generator hangs on b11
100%
Description
The EFSM Test Generator that is run at EfsmTestGeneratorVhdlTestCase hangs on b11 VHDL design (or this testcase continues more than 8 hours - it is very suspicious).
The log fragment is attached below.
Updated by Sergey Smolov about 9 years ago
- Priority changed from High to Urgent
The test still hangs on Hudson.
Updated by Igor Melnichenko about 9 years ago
- Status changed from Open to Resolved
- % Done changed from 0 to 100
Updated by Sergey Smolov about 9 years ago
- Status changed from Resolved to Open
- % Done changed from 100 to 0
Now this testcase produces at Hudson server the java.lang.OutOfMemoryError with the following error log:
build.xml:140: java.lang.OutOfMemoryError: Requested array size exceeds VM limit
at java.util.Arrays.copyOf(Arrays.java:2271)
at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
at java.io.PrintStream.write(PrintStream.java:480)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207)
at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:129)
at java.io.BufferedWriter.close(BufferedWriter.java:264)
at java.io.PrintStream.close(PrintStream.java:359)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:542)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:1420)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:848)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1899)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:800)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
Possibly testcase prints too much to stdout. You need either to forward the stream to file or to shrink the logging.
Updated by Igor Melnichenko about 9 years ago
What is the target maximum heap size?
Updated by Sergey Smolov about 9 years ago
I can't find related Hudson settings. You may try to remove all the engine output except the most wanted information. After that I'll check it on Hudson (see e-mail).
Updated by Sergey Smolov about 9 years ago
By the way, why not to use Retrascope logging subsystem for engine output's filtering?
Updated by Igor Melnichenko about 9 years ago
Sergey Smolov wrote:
I can't find related Hudson settings. You may try to remove all the engine output except the most wanted information. After that I'll check it on Hudson (see e-mail).
How much RAM is on the Hudson server?
Updated by Igor Melnichenko about 9 years ago
Sergey Smolov wrote:
By the way, why not to use Retrascope logging subsystem for engine output's filtering?
I'm using it.
Updated by Igor Melnichenko about 9 years ago
I've shortened the INFO output. Maybe it's enough.
Updated by Sergey Smolov about 9 years ago
Igor Melnichenko wrote:
I've shortened the INFO output. Maybe it's enough.
But it is not. Can you mark all the engine output as "DEBUG" (except, for example, the resulting coverage)? In fact this output log is still exhaustive and huge.
By the way, you may reproduce this bug on your PC by applying the following patch to build.xml:
Index: build.xml
===================================================================
--- build.xml (revision 1678)
+++ build.xml (working copy)
@@ -127,6 +127,8 @@
debug="${compile.java.debug}"
debuglevel="${compile.java.debug.level}"
verbose="${compile.java.verbose}"
+ fork="true"
+ memorymaximumsize="2048m"
includeantruntime="false">
</javac>
Updated by Igor Melnichenko about 9 years ago
- Status changed from Open to Resolved
- % Done changed from 0 to 100
Sergey Smolov wrote:
Igor Melnichenko wrote:
I've shortened the INFO output. Maybe it's enough.
But it is not. Can you mark all the engine output as "DEBUG" (except, for example, the resulting coverage)? In fact this output log is still exhaustive and huge.
By the way, you may reproduce this bug on your PC by applying the following patch to build.xml:
[...]
Done. The test target from build.xml has passed EfstTestGeneratorTestCase successfully.
But I see your commit. Should I discard my changes?
Updated by Sergey Smolov about 9 years ago
I've just changed the loglevel for some INFO-messages to DEBUG level. Also I've checked it on my PC. The testing on Hudson is in progress.
I think you'd better to merge your changes with mine before committing.
Updated by Sergey Smolov almost 9 years ago
- Status changed from Verified to Closed
- Published in build set to 20150701