2819 – array.sort segfaults if array length >=0x8F_FFFF

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
Add an attachment (proposed patch, testcase, etc.)

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


AltStyle によって変換されたページ (->オリジナル) /