Project

General

Profile

Bug #5719

EFSM Test Generator hangs on b11

Added by Sergey Smolov over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Urgent
Category:
Engine (Generator)
Target version:
Start date:
03/18/2015
Due date:
% Done:

100%

Estimated time:
Detected in build:
svn
Platform:
Published in build:
20150701

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.

History

#1

Updated by Igor Melnichenko over 4 years ago

  • Status changed from New to Open
#2

Updated by Sergey Smolov over 4 years ago

  • Priority changed from High to Urgent

The test still hangs on Hudson.

#3

Updated by Igor Melnichenko over 4 years ago

  • Status changed from Open to Resolved
  • % Done changed from 0 to 100
#4

Updated by Sergey Smolov over 4 years ago

  • File deleted (efsm-testgen-log.txt)
#5

Updated by Sergey Smolov over 4 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.

#6

Updated by Igor Melnichenko over 4 years ago

What is the target maximum heap size?

#7

Updated by Sergey Smolov over 4 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).

#8

Updated by Sergey Smolov over 4 years ago

By the way, why not to use Retrascope logging subsystem for engine output's filtering?

#9

Updated by Igor Melnichenko over 4 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?

#10

Updated by Igor Melnichenko over 4 years ago

Sergey Smolov wrote:

By the way, why not to use Retrascope logging subsystem for engine output's filtering?

I'm using it.

#11

Updated by Igor Melnichenko over 4 years ago

I've shortened the INFO output. Maybe it's enough.

#12

Updated by Sergey Smolov over 4 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>
#13

Updated by Igor Melnichenko over 4 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?

#14

Updated by Sergey Smolov over 4 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.

#15

Updated by Igor Melnichenko over 4 years ago

Done.

#16

Updated by Sergey Smolov over 4 years ago

  • Status changed from Resolved to Verified

Ok:-)

#17

Updated by Sergey Smolov about 4 years ago

  • Status changed from Verified to Closed
  • Published in build set to 20150701

Also available in: Atom PDF