[Mono-dev] Stack overflow in Array.Sort for large arrays

[Marek Safar]

Hi,

I cannot reproduce the issue. Could you fill a bug report with test case
how to reproduce it.

Thanks
Marek

On Thu, Aug 2, 2012 at 7:21 PM, Martin Potter <martin.potter at logos.com>wrote:

> I am currently working on testing Mono to 2.11 with the hope to ease the
> transition to 2.12 when it is release. When testing, I found a nasty bug
> when sorting a large (228,000 elements) List<int> that resulted in a stack
> overflow. The partial stack trace from the crash:
>
> System.Collections.Generic.List`1<int>:Sort ()
> System.Array:Sort<int> (int[],int,int)
> System.Array:Sort<int>
> (int[],int,int,System.Collections.Generic.IComparer`1<int>)
> System.Array:SortImpl<int, int>
> (int[],int[],int,int,System.Collections.Generic.IComparer`1<int>)
> System.Array:qsort<int, int> (int[],int[],int,int)
> ...
> System.Array:qsort<int, int> (int[],int[],int,int)
>
> Upon pulling the related sorting code from System.Array into a separate
> project, I determined that the stack overflow was occurring for this
> particular List/Array due to the fact that over half of the list elements
> were same number. It appears that this occurs as a result of the change to
> the various qsort methods in
> https://github.com/mono/mono/commit/d97cdb0c124729152be551c421c4a11732e45fc9,
> which introduced a change in the treatment of elements with equal values.
> Reverting this commit fixes the stack overflow in the test app. In testing,
> I noticed that the old qsort code was significantly faster sorting when
> there were lots of duplicate values, was there are particular reason for
> changing the logic for dealing with equal values?
>
> — Martin
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120804/cca0e71c/attachment.html>