Assertions reported as " java.io.IOException: Steam closed"

Madhava Krishna

unread,

Oct 19, 2015, 12:44:16 AM10/19/15

to chisel-users

Hi,

I am running scala-2.11.6 and latest chisel version (2.2.29), when where an assertion is caught
it causes "java.io.IOException: Stream closed". Could someone please help me to resolve this.

Thanks,
Madhav

Andrea Peruffo

unread,

Oct 19, 2015, 2:52:54 AM10/19/15

to chisel-users

+1 for this, even in version 2.3-SNAPSHOT (pulled on friday) with a large cpp file (around 20Mb) after successful compilation when trying to run I get:

[debug] Waiting for thread run-main-0 to terminate.

[error] (run-main-0) java.io.IOException: Stream closed

java.io.IOException: Stream closed

at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:433)

at java.io.OutputStream.write(OutputStream.java:116)

at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)

at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)

at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)

at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)

at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)

at java.io.BufferedWriter.flush(BufferedWriter.java:254)

at Chisel.Tester.writeln(Tester.scala:124)

at Chisel.Tester.Chisel$Tester$$sendCmd(Tester.scala:145)

at Chisel.Tester$$anonfun$2.apply$mcVI$sp(Tester.scala:472)

at scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:166)

at Chisel.Tester.<init>(Tester.scala:471)

at CubeHashDemoAlgoTester.<init>(CubeHashHw.scala:688)

at Main$$anonfun$2.apply(Main.scala:35)

at Chisel.Driver$.apply(Driver.scala:53)

at Chisel.chiselMain$.apply(hcl.scala:63)

at Chisel.chiselMainTest$.apply(hcl.scala:76)

at Main$.delayedEndpoint$Main$1(Main.scala:34)

at Main$delayedInit$body.apply(Main.scala:4)

at scala.Function0$class.apply$mcV$sp(Function0.scala:34)

at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)

at scala.App$$anonfun$main$1.apply(App.scala:76)

at scala.collection.immutable.List.foreach(List.scala:381)

at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)

at scala.App$class.main(App.scala:76)

at Main$.main(Main.scala:4)

at Main.main(Main.scala)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:497)

at sbt.Run.invokeMain(Run.scala:67)

at sbt.Run.run0(Run.scala:61)

at sbt.Run.sbt$Run$$execute$1(Run.scala:51)

at sbt.Run$$anonfun$run$1.apply$mcV$sp(Run.scala:55)

at sbt.Run$$anonfun$run$1.apply(Run.scala:55)

at sbt.Logger$$anon$4.apply(Logger.scala:85)

at sbt.TrapExit$App.run(TrapExit.scala:248)

at java.lang.Thread.run(Thread.java:745)

[debug] Thread run-main-0 exited.

[debug] Interrupting remaining threads (should be all daemons).

[debug] Sandboxed run complete..

java.lang.RuntimeException: Nonzero exit code: 1

at scala.sys.package$.error(package.scala:27)

at sbt.BuildCommon$$anonfun$toError$1.apply(Defaults.scala:1943)

at scala.Option.foreach(Option.scala:236)

at sbt.BuildCommon$class.toError(Defaults.scala:1943)

at sbt.Defaults$.toError(Defaults.scala:38)

at sbt.Defaults$$anonfun$runTask$1$$anonfun$apply$36$$anonfun$apply$37.apply(Defaults.scala:719)

at sbt.Defaults$$anonfun$runTask$1$$anonfun$apply$36$$anonfun$apply$37.apply(Defaults.scala:717)

at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)

at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:40)

at sbt.std.Transform$$anon$4.work(System.scala:63)

at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)

at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)

at sbt.Execute.work(Execute.scala:235)

at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)

at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:159)

at sbt.CompletionService$$anon$2.call(CompletionService.scala:28)

at java.util.concurrent.FutureTask.run(FutureTask.java:266)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

at java.util.concurrent.FutureTask.run(FutureTask.java:266)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:745)

Donggyu Kim

unread,

Oct 19, 2015, 5:11:37 AM10/19/15

to chisel-users

Could you explain which assertion was caught?

Donggyu Kim

unread,

Oct 19, 2015, 5:13:09 AM10/19/15

to chisel-users

Did you not get this error before pulling the latest release? Is a large cpp file your design?

Andrea Peruffo

unread,

Oct 19, 2015, 5:54:42 AM10/19/15

to chisel-users

Never try with another version of chisel...

The cpp file is quite large, let say around 20Mb.

Found also that it fails constantly only on my MacBook and not on a workstation with Linux, maybe is something os related?

Let me know if I could do anything to better trac the problem.

Madhava Krishna

unread,

Oct 19, 2015, 6:10:20 AM10/19/15

to chisel...@googlegroups.com

The assertion is implemented using method assert(Bool, String): Unit

As shown below.

class mkAssert extends Module{

val io = new Bundle{
    val dataIn = UInt(INPUT,8)
    val dataOut = UInt(OUTPUT,width=3)
}

io.dataOut := OHToUInt(io.dataIn)
assert(io.dataIn != UInt(0), "! dataIn not One Hot Encoded !")
}

P.S: Attachment includes test code that drives the module and outputs with and without assert.

Madhava Krishna,
CAD Lab,
Department of Electronic Systems Engineering,
Indian Institute of Science,
Bangalore - 560012.

Ph: 91-9535145495

--
You received this message because you are subscribed to the Google Groups "chisel-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
To post to this group, send email to chisel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/da4fef14-8962-4c9c-bf27-1dc915cde2f6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

MyAssert.scala

run_with_assert

run_with_no_assert

Jim Lawson

unread,

Oct 19, 2015, 2:12:57 PM10/19/15

to chisel...@googlegroups.com

This is a result of the way run-time assertions are currently implemented in the C++ backend. By default, an assert() is translated to an invocation of the ASSERT macro (defined in emulator.h) which throws a std::runtime_error() exception with the assertion message as argument if the supplied condition evaluates to false.

Since there are currently no exception handlers in the generated C++ code, this ends up invoking std::terminate() and abort() which causes the application to exit, thereby closing the connection to the Tester running in the JVM.

We should do the following:
- catch the "java.io.IOException: Stream closed” in the tester
- ensure we output any messages generated by the test application
- provide a default exception handler in the C++ test application

I’ve added this as a new issue (#559).

In the meantime, you can eliminate the use of the ASSERT macro by specifying

--assertWarn

as an additional Chisel option. The instructs Chisel to translate assert() into an invocation of the WARN macro which will print the specified message if the specified condition evaluates to false, and then continue execution.

> To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/CACwyQTo5u4j3wkUjdH17wLnHRA9TCQYEKXVjp_cw24gM_XOzCA%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

> <MyAssert.scala><run_with_assert><run_with_no_assert>

Donggyu Kim

unread,

Oct 19, 2015, 4:27:52 PM10/19/15

to chisel-users

Unfortunately, the connection between Chisel testers and emulators is very slow and unstable. We didn't test it on mac os heavily either. I'm currently working on a way better method included in the next release. Stay tuned.

Andrea Peruffo

unread,

Oct 19, 2015, 4:50:10 PM10/19/15

to chisel...@googlegroups.com

Please fill free to ask of needed... is it possibile to use a bus (i.e. nanomsg) instead a direct socket? Moreover is it possible to use the '-pipe' or '-j {cores}' option in case of long compilations?

--
You received this message because you are subscribed to a topic in the Google Groups "chisel-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chisel-users/VqmrjFaquY8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chisel-users...@googlegroups.com.

To post to this group, send email to chisel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/7a2d40d8-ba1b-47b1-aad2-c7b6aba81749%40googlegroups.com.

Rupert Smith

unread,

Oct 21, 2015, 9:07:35 AM10/21/15

to chisel-users

I had a similar issue a while back, and re-read what I posted then.

https://groups.google.com/forum/?fromgroups#!topic/chisel-users/2GbVXrpfRFM

If the child process dies, you get this IOException. In your case, by adding some exception handling into the simulator code and dumping the error out to the console, you should at least be able to find out which assertion failed. A top-level error handler in the simulator code might have helped me track down the error I was getting too, although in my case it was not an assert that I had added to my code.

So +1 for a top-level error handler in the simulator code.

Also, to make it faster are you going to move to a shared memory buffer between the JVM and C++? Re-writing the simulator in Java would be another interesting possibility.

Rupert

Reply all

Reply to author

Forward