Return-Path: X-Original-To: apmail-spark-issues-archive@minotaur.apache.org Delivered-To: apmail-spark-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2054411CF1 for ; Tue, 23 Sep 2014 03:00:36 +0000 (UTC) Received: (qmail 2711 invoked by uid 500); 23 Sep 2014 03:00:35 -0000 Delivered-To: apmail-spark-issues-archive@spark.apache.org Received: (qmail 2677 invoked by uid 500); 23 Sep 2014 03:00:35 -0000 Mailing-List: contact issues-help@spark.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@spark.apache.org Received: (qmail 2667 invoked by uid 99); 23 Sep 2014 03:00:35 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Sep 2014 03:00:35 +0000 Date: Tue, 23 Sep 2014 03:00:35 +0000 (UTC) From: "Matei Zaharia (JIRA)" To: issues@spark.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (SPARK-3032) Potential bug when running sort-based shuffle with sorting using TimSort MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SPARK-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14144243#comment-14144243 ] Matei Zaharia commented on SPARK-3032: -------------------------------------- I'm not completely sure that this is because hashCode provides a partial ordering, because I believe TimSort is supposed to work on partial orderings as well. I believe the problem is an integer over flow when we subtract key1.hashCode - key2.hashCode. Can you try replacing the line that returns h1 - h2 in keyComparator with returning Integer.compare(h1, h2)? This will properly deal with overflow. Returning h1 - h2 is definitely wrong: for example suppose that h1 = Int.MaxValue and h2 = Int.MinValue, then h1 - h2 = -1. Please add a unit test for this case as well. > Potential bug when running sort-based shuffle with sorting using TimSort > ------------------------------------------------------------------------ > > Key: SPARK-3032 > URL: https://issues.apache.org/jira/browse/SPARK-3032 > Project: Spark > Issue Type: Bug > Components: Shuffle > Affects Versions: 1.1.0 > Reporter: Saisai Shao > Priority: Critical > > When using SparkPerf's aggregate-by-key workload to test sort-based shuffle, data type for key and value is (String, String), always meet this issue: > {noformat} > java.lang.IllegalArgumentException: Comparison method violates its general contract! > at org.apache.spark.util.collection.Sorter$SortState.mergeLo(Sorter.java:755) > at org.apache.spark.util.collection.Sorter$SortState.mergeAt(Sorter.java:493) > at org.apache.spark.util.collection.Sorter$SortState.mergeCollapse(Sorter.java:420) > at org.apache.spark.util.collection.Sorter$SortState.access$200(Sorter.java:294) > at org.apache.spark.util.collection.Sorter.sort(Sorter.java:128) > at org.apache.spark.util.collection.SizeTrackingPairBuffer.destructiveSortedIterator(SizeTrackingPairBuffer.scala:83) > at org.apache.spark.util.collection.ExternalSorter.spillToMergeableFile(ExternalSorter.scala:323) > at org.apache.spark.util.collection.ExternalSorter.spill(ExternalSorter.scala:271) > at org.apache.spark.util.collection.ExternalSorter.maybeSpill(ExternalSorter.scala:249) > at org.apache.spark.util.collection.ExternalSorter.insertAll(ExternalSorter.scala:220) > at org.apache.spark.shuffle.sort.SortShuffleWriter.write(SortShuffleWriter.scala:85) > at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:68) > at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:41) > at org.apache.spark.scheduler.Task.run(Task.scala:54) > at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:199) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > {noformat} > Seems the current partitionKeyComparator which use hashcode of String as key comparator break some sorting contracts. > Also I tested using data type Int as key, this is OK to pass the test, since hashcode of Int is its self. So I think potentially partitionDiff + hashcode of String may break the sorting contracts. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org For additional commands, e-mail: issues-help@spark.apache.org