Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deadlock when parallel collection function throws an exception #5375

Closed
scabug opened this issue Jan 13, 2012 · 6 comments
Closed

Deadlock when parallel collection function throws an exception #5375

scabug opened this issue Jan 13, 2012 · 6 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Jan 13, 2012

When doing a map over a parallel sequence, my program deadlocks waiting on the result if the map function threw an exception. Test case (exhibits problem in Scala 2.9.1 REPL on Oracle JDK 1.7.0u2, Linux x86_64):

val foos = (1 to 1000) toSeq
foos.par.map(i => if (i % 37 == 0) sys.error("i div 37") else i).seq

Entering this code in the toplevel will result in an indefinite hang. jstack reveals that all interesting threads are waiting, either on object monitors or parked.

@scabug
Copy link
Author

scabug commented Jan 13, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5375?orig=1
Reporter: Michael Ekstrand (ekstrand)
Affected Versions: 2.9.1

@scabug
Copy link
Author

scabug commented Jan 13, 2012

@paulp said:
For the record, I only can reproduce that deadlock with scala 2.9.1 on java7. If I use either scala trunk or java6, the exception comes out. So this appears fixed in trunk.

@scabug
Copy link
Author

scabug commented Jan 13, 2012

Michael Ekstrand (ekstrand) said:
I have downloaded the latest nightlies for 2.9.2 and 2.10.0 and tried it. It works correctly on 2.10 but deadlocks on 2.9.2.

It also works on 2.9.1 on OpenDK6 on my machine.

@scabug scabug closed this as completed Jan 25, 2012
@scabug
Copy link
Author

scabug commented Jan 25, 2012

@axel22 said:
The reason it didn't work on java7 is that the vendor name changed to "Oracle", so the fork join pool wasn't used. This was already fixed in trunk, but wasn't backported to 2.9.2.
This bug was still happening on java5, but I've fixed it now.

@scabug
Copy link
Author

scabug commented Jan 7, 2013

Heikki Vesalainen (hvesalai) said:
2.9.3 RC1 is out. Could the original fix developer backport this to 2.9.3 or should I take a stab at it?

@scabug
Copy link
Author

scabug commented Jan 16, 2013

@retronym said:
The ForkJoin detection was already added to 2.9.2.

2.9.x ~/code/scala2 git show 9eb9682f792e26bf99e74e777b776d5ce841a595
commit 9eb9682f792e26bf99e74e777b776d5ce841a595
Author: Aleksandar Pokopec <aleksandar.prokopec@epfl.ch>
Date:   Fri Nov 11 16:59:45 2011 +0000

    Changes the fork join pool detection for JVM1.7...
    
    Changes the fork join pool detection for JVM1.7, for actors and parallel
    collections libraries.
    
    Review by phaller.

diff --git a/src/actors/scala/actors/scheduler/ThreadPoolConfig.scala b/src/acto
index d514d94..a7bf8ec 100644
--- a/src/actors/scala/actors/scheduler/ThreadPoolConfig.scala
+++ b/src/actors/scala/actors/scheduler/ThreadPoolConfig.scala
@@ -45,7 +45,7 @@ private[actors] object ThreadPoolConfig {
 
         // on IBM J9 1.6 do not use ForkJoinPool
         // XXX this all needs to go into Properties.
-        isJavaAtLeast("1.6") && ((javaVmVendor contains "Sun") || (javaVmVendor
+        isJavaAtLeast("1.6") && ((javaVmVendor contains "Oracle") || (javaVmVen
       })
     catch {
       case _: SecurityException => false
2.9.x ~/code/scala2 git tag --contains 9eb9682f792e26bf99e74e777b776d5ce841a595
v2.9.2
v2.9.2-RC2
v2.9.2-RC3
v2.9.3-RC1

@scabug scabug added this to the 2.10.0-M1 milestone Apr 7, 2017
julienrf added a commit to julienrf/scala-parallel-collections that referenced this issue Jan 13, 2019
Check that all suppressed exception contain a multiple of 37, rather
than checking for explicit values.
julienrf added a commit to julienrf/scala-parallel-collections that referenced this issue Jan 17, 2019
Check that all suppressed exception contain a multiple of 37, rather
than checking for explicit values.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants