Imported From: https://issues.scala-lang.org/browse/SI-4705?orig=1
Reporter: @lrytz
Attachments:

• stackdump_r25154_ctrl-d.txt (created on Jun 25, 2011 11:03:33 AM UTC, 3505 bytes)

@paulp said:
Can you be more specific? It doesn't do anything like that for me. Windows?

@paulp said:
Oh, I see OSX in the subject line now. No, it definitely doesn't do that on OSX for me.

@paulp said:
Closing as cannot reproduce because I use ctrl-D all day so I know I can't reproduce it as I've never seen it. Please reopen if it's reproducible in a way you can describe to me.

@lrytz said:
I tried on a different Mac and I see the same behavior.

Here's what I did. At the end, in the scala> prompt, I typed ctrl-d. Afterwards, any keystroke does not echo anymore, nothing happens, until I type ctrl-c and get back to the console.

lampmac3:~ jenkins$ env
TERM=screen
SHELL=/bin/bash
SSH_CLIENT=128.178.154.107 36418 22
SBT_HOME=/Users/jenkins/apps/sbt
SSH_TTY=/dev/ttys000
ANT_HOME=/Users/jenkins/apps/ant
ANT_OPTS=-Xmx1536m -Xms1536m -Xss1m -XX:MaxPermSize=512M -XX:+UseParallelGC
JAVA_OPTS=-Xmx1536m -Xms1536m -Xss1m -XX:MaxPermSize=512M -XX:+UseParallelGC
USER=jenkins
MONO_HOME=/Library/Frameworks/Mono.framework/Versions/Current
mount_authenticator=
MAIL=/var/mail/jenkins
PATH=/Users/jenkins/apps/ant/bin:/Users/jenkins/apps/sbt:/Library/Frameworks/Mono.framework/Versions/Current/bin:/bin:/usr/bin:/usr/local/bin:/usr/local/git/bin
PWD=/Users/jenkins
SHLVL=1
HOME=/Users/jenkins
LOGNAME=jenkins
SSH_CONNECTION=128.178.154.107 36418 128.178.154.94 22
_=/usr/bin/env
lampmac3:~ jenkins$ 
lampmac3:~ jenkins$ wget http://www.scala-lang.org/archives/downloads/distrib/files/nightly/distributions/scala-2.10.0.r25101-b20110618022942.tgz
[...]
lampmac3:~ jenkins$ tar xzf scala-2.10.0.r25101-b20110618022942.tgz 
lampmac3:~ jenkins$ scala-2.10.0.r25101-b20110618022942/bin/scala
Welcome to Scala version 2.10.0.r25101-b20110618020216 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_24).
Type in expressions to have them evaluated.
Type :help for more information.

scala> 
lampmac3:~ jenkins$ 

@paulp said:
So first thing I learned from your transcript is that 1.6.0_24 is out on OSX. I find that for whatever reason my java preferences kept 1.6.0_22 around and were still using that.

Switching to 1.6.0_24 made no difference, I still see ctrl-D working. I mention it because next I tried openjdk and then I saw what you see. So this I cannot explain. It's something environmental, but I don't think the jvm is the direct reason: more of a proxy.

scala3
Welcome to Scala version 2.10.0.r25100-b20110616124416 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_24).
Type in expressions to have them evaluated.
Type :help for more information.

// This represents ctrl-D working as expected
scala> [paulp@stem ~ (master)]$ 

JAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home scala3
Welcome to Scala version 2.10.0.r25100-b20110616124416 (OpenJDK 64-Bit Server VM, Java 1.7.0-internal).
Type in expressions to have them evaluated.
Type :help for more information.

// This represents ctrl-D freezing us and ctrl-C ending the session.
scala> 
[paulp@stem ~ (master)]$ 

@paulp said:
Oh, and in my openjdk if I enter a few commands in the repl and then ctrl-D, it works. Is that true for you?

@paulp said:
I have pinned this on using the boot classpath: normal behavior returns with -nobootcp. Can you confirm the same?

huynhjl said (edited on Jun 25, 2011 11:25:40 AM UTC):
I've intermittently experienced almost the same on locally built pack bins on Windows 7 (built at rev 25149) as well as nightly 2.10.0.r25154-b20110625020222 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_18). The only difference is CTRL-C doesn't exit. I have to kill with the Task Manager.

H:\r25154\bin>scala.bat
Welcome to Scala version 2.10.0.r25154-b20110625020222 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_18).
Type in expressions to have them evaluated.
Type :help for more information.

scala> dasdasfd
<console>:8: error: not found: value dasdasfd
              dasdasfd
              ^
// This represents ctrl-D freezing
scala>

Because it's scala.bat, it's basically equivalent to using the nobootcp option. I'm collecting a stack dump and heap dump and will attach.

Note it also happens with cygwin even when starting with /cygdrive/h/r25154/bin/scala -nobootcp -Djline.terminal=none and exiting using :quit. Never happens when using exit.

huynhjl said:
Stack dump. Zipped heap dump is ~11MB, so I'll send on request.

@lrytz said:
for me it happens always. also after entering some commands, and also when using -nobootcp.

Ramzi (rby) said:
On a Linux box (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_26), it doesn't happen when an expression has been evaluated successfully.
I also noticed that it happens if nothing has been evaluated before ctrl-D or if the expressions before it evaluate to errors.

huynhjl said:
I've noticed on my Windows 7 64 bits box that the issue is intermittent/not deterministic. It can manifest once then it works fine for many runs. It makes it difficult to bisect for when the problem originated. When it does happen I can get a stack trace and memory dump. The only semi suspicious thing I can find is

"pool-2-thread-1" prio=6 tid=0x000000001be03000 nid=0xdac waiting on condition [0x000000001c37f000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x000000000a633618> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
	at java.lang.Thread.run(Thread.java:619)

   Locked ownable synchronizers:
	- None

Using the Eclipse Memory Analyzer, it seems this pool executor has no task queued up and its LinkedBlockingQueue is empty. All the threads are showing only java.lang or java.util method calls.

@harrah said:
The scala.tools.nsc.io package object contains several methods that cause a thread pool to be created but never explicitly shut down. The only user of these methods that I found was the scala.tools.nsc.Sources class, which uses the io.spawn method. The thread pools will only get shut down by the finalizer running, which could explain the sporadic nature of this bug.

A fix might be to use plain threads, make the ThreadFactory construct daemon threads, or to call shutdown() on the thread pool after submitting. I don't know which one is preferred.

@paulp said:
I turned a few funny looking knobs and sliders based on mark's comment. Any problem havers want to try out a new build and see if it made any difference? r25390 is the relevant commit.

@jrudolph said:
Ubuntu 11.04 here, same problem with 2.9.1.RC1/2.

I tried with scala-compiler-2.10.0-20110815.021856-122.jar and Ctrl+D works now in sbt console again.

@paulp said:
If you guys can try RC3 ASAP (whenever it's out) and make sure it's fixed that'd be great.

Also, Johannes, can you verify that #4844 is fixed for you.

@jrudolph said:
In 2.9.1.RC3, Ctrl-C/D work with sbt 0.7.7 and standalone interpreter as intended in Ubuntu 11.04.

@harrah said:
Closing, as the fix has been confirmed to work and there have not been any complaints since 2.9.1.final has been released that I am aware of.