D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 2819 - array.sort segfaults if array length >=0x8F_FFFF
Summary: array.sort segfaults if array length >=0x8F_FFFF
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: phobos (show other issues)
Version: D1 (retired)
Hardware: x86 Windows
: P2 normal
Assignee: No Owner
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2009-04-07 13:17 UTC by Don
Modified: 2014-04-18 09:14 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Don 2009-04-07 13:17:33 UTC
void main() {
  auto a = new uint[0x8F_FFFF]; // smallest size that fails
  a.sort;
}

It's caused by the hard-coded
  byte*[40] stack;              // stack

in
extern (C) long _adSort(Array a, TypeInfo ti)
in qsort.d.

Affects both D1 and D2.
This is just another reason for the built-in .sort to be deprecated.
Comment 1 Stewart Gordon 2009-04-07 14:20:12 UTC
(In reply to comment #0)
> This is just another reason for the built-in .sort to be deprecated.

I don't understand.  How is this bug a consequence of sort being built in?
Comment 2 Don 2009-04-07 14:47:23 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > This is just another reason for the built-in .sort to be deprecated.
> 
> I don't understand.  How is this bug a consequence of sort being built in?

It isn't. But the fact that the built-in sort is buggy as well as slow and limited, further weakens its appeal. It just doesn't seem to have much going for it.

Comment 3 Andrei Alexandrescu 2009-04-07 15:05:46 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > This is just another reason for the built-in .sort to be deprecated.
> > 
> > I don't understand.  How is this bug a consequence of sort being built in?
> 
> It isn't. But the fact that the built-in sort is buggy as well as slow and
> limited, further weakens its appeal. It just doesn't seem to have much going
> for it.
> 

I agree. By the way, if anyone has run numbers on the relative speeds of various sort implementations, please share.
Comment 4 Matti Niemenmaa 2009-04-07 15:17:15 UTC
http://www.dsource.org/projects/tango/ticket/571 has some old numbers.
Comment 5 Stewart Gordon 2009-04-07 16:19:53 UTC
(In reply to comment #3)
> I agree. By the way, if anyone has run numbers on the relative speeds of
> various sort implementations, please share.

What's a run number?

Anyway, here's a program I wrote a while ago to benchmark sorting algorithms:

http://www.digitalmars.com/d/archives/digitalmars/D/announce/Sorting_algorithms_benchmark_7661.html
http://pr.stewartsplace.org.uk/d/sortbench.d
Comment 6 Andrej Mitrovic 2011-05-24 22:24:36 UTC
I can't recreate this bug on 2.053. If others can confirm, close this down I guess.
Comment 7 Don 2011-05-25 00:54:15 UTC
Still segfaults on 1.068. And I don't think the underlying bug has actually been fixed on D2, either, even though this test case works now.
Comment 8 github-bugzilla 2012-01-27 21:08:32 UTC
Commit pushed to phobos-1.x at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/12b9cb5db63216c33485681edc83f2f272d869f9
fix Issue 2819 - array.sort segfaults if array length >=0x8F_FFFF
Comment 9 github-bugzilla 2012-01-27 21:09:54 UTC
Commit pushed to master at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/077c1bd9948dce0a645cc5df5b9dc8919a2295fc
Issue 2819 - array.sort segfaults if array length >=0x8F_FFFF