digitalmars.D.bugs - [Issue 3930] New: AAs horribly broken
- d-bugmail puremagic.com (109/109) Mar 10 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3930
- d-bugmail puremagic.com (14/14) Mar 11 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3930
- d-bugmail puremagic.com (24/24) Mar 11 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3930
- d-bugmail puremagic.com (10/10) Mar 11 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3930
- d-bugmail puremagic.com (12/12) Mar 27 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3930
http://d.puremagic.com/issues/show_bug.cgi?id=3930 Summary: AAs horribly broken Product: D Version: 2.041 Platform: Other OS/Version: Windows Status: NEW Severity: regression Priority: P1 Component: druntime AssignedTo: sean invisibleduck.org ReportedBy: dsimcha yahoo.com The following code tests the builtin associative array by comparing its behavior to the behavior of an AA implemented via linear search. It works on 2.040 but produces an access violation on 2.041. import std.stdio, std.random; // Quick, dirty and inefficient AA using linear search, useful for testing. struct LinearAA(K, V) { K[] keys; V[] values; V opIndex(K key) { foreach(i, k; keys) { if(k == key) { return values[i]; } } assert(0, "Key not present."); } V opIndexAssign(V val, K key) { foreach(i, k; keys) { if(k == key) { return values[i] = val; } } keys ~= key; values ~= val; return val; } V* opIn_r(K key) { foreach(i, k; keys) { if(key == k) { return values.ptr + i; } } return null; } void remove(K key) { size_t i = 0; for(; i < keys.length; i++) { if(keys[i] == key) { break; } } assert(i < keys.length); for(; i < keys.length - 1; i++) { keys[i] = keys[i + 1]; values[i] = values[i + 1]; } keys = keys[0..$ - 1]; values = values[0..$ - 1]; } uint length() { return values.length; } } void main() { foreach(iter; 0..10) { // Bug only happens after a few iterations. writeln(iter); uint[uint] builtin; LinearAA!(uint, uint) linAA; uint[] nums = new uint[100_000]; foreach(ref num; nums) { num = uniform(0U, uint.max); } foreach(i; 0..10_000) { auto index = uniform(0, nums.length); if(index in builtin) { assert(index in linAA); assert(builtin[index] == nums[index]); assert(linAA[index] == nums[index]); builtin.remove(index); linAA.remove(index); } else { assert(!(index in linAA)); builtin[index] = nums[index]; linAA[index] = nums[index]; } } assert(builtin.length == linAA.length); foreach(k, v; builtin) { assert(k in linAA); assert(*(k in builtin) == *(k in linAA)); assert(linAA[k] == v); } } } This is probably related to Bug 3929. Since the current builtin AA implementation uses free() quite liberally as a practical necessity due to false pointer issues, we see some very subtle, hard to reproduce bugs. (The only way I can reproduce them is by monte carlo unittesting different AA implementations against each other like above. Even then it depends somewhat sensitively on what code was executed previously, hence the multiple iterations.) For me, this is a blocker for using this version of DMD, as the project I'm working on lately uses AAs very heavily. I think this is severe enough to merit its own release. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 10 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3930 Steven Schveighoffer <schveiguy yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schveiguy yahoo.com 04:07:31 PST --- I can only find two places that AA's use free, one when an element is removed via gc_free, and once to delete the hash array itself. Commenting out both of those, I still get the segmentation fault. I'm still not convinced that the stomping fixes I put in are not to blame, I will try commenting those out. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 11 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3930 Steven Schveighoffer <schveiguy yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com 05:10:16 PST --- I found the problem. It has nothing to do with the cache, but it has to do with a bug with how I store the length in the block. Because I must store the length of a block that is page size or greater at the front of the block (smaller blocks I store the length at the end), the start of an array is offset by 2*size_t.sizeof bytes. The problem comes when initializing a newly allocated array. I forgot to add the offset for larger arrays when calling memset, so the last 2*size_t.sizeof bytes are not initialized. In addition, if you allocated a large array of structs which had a non-uniform initializer, they could all be skewed! I think this fix is worth a new release of dmd. I checked in the changes, but druntime doesn't build at the moment, I think someone is adding stack tracing. Try this patch on your local copy of druntime and see if it fixes the problem for you: http://www.dsource.org/projects/druntime/changeset/261/trunk?format=diff&new=261 cc'ing walter to notify him. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 11 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3930 Steven Schveighoffer <schveiguy yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.sagitario gmx.de 05:44:03 PST --- *** Issue 3898 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 11 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3930 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |clugdbug yahoo.com.au Resolution| |FIXED Fixed DMD2.042. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 27 2010