Through debugging Ellery Newcomer's test case (see
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=108685),
I have found another bug in the array append patch.
See if you can spot it, I literally had to stare at this code for about 40
minutes, confused by its behavior, before I finally saw the problem. The
function below searches the LRU cache for a blockinfo (base pointer, size, and
attributes) containing an interior pointer:
struct BlkInfo
{
void* base;
size_t size;
uint attr;
}
BlkInfo *__getBlkInfo(void *interior)
{
// try to do a smart lookup, using __nextBlkIdx as the "head"
BlkInfo *ptr = __blkcache.ptr;
for(int i = __nextBlkIdx; i >= 0; --i)
{
if(ptr[i].base <= interior && (interior - ptr[i].base) < ptr.size)
return ptr + i;
}
for(int i = N_CACHE_BLOCKS - 1; i > __nextBlkIdx; --i)
{
if(ptr[i].base <= interior && (interior - ptr[i].base) < ptr.size)
return ptr + i;
}
return null; // not in cache.
}
to give you a hint, here is the erroneous behavior that puzzled me:
given a pointer 0x38bd0, the function returned a blockinfo that started at
0x38bc0 with size 16.
If you can't figure it out, here is the answer:
http://www.dsource.org/projects/druntime/changeset/282
I'm waiting to hear back from Ellery that the new code fixes the problem, and I
also pinged David for his issue with AAs. If all is OK, I recommend a patch
release. I'm not sure the state of the AAs in trunk, since Walter has changed
them significantly -- we could be fixing one bug and introducing many more.
Given how simple this fix is, it might be good to release just this fix in
order to have a stable version that doesn't do memory stomping.
-Steve
----- Original Message ----
> From: Walter Bright <[email protected]>
> To: Discuss the phobos library for D <[email protected]>
> Sent: Fri, April 2, 2010 1:29:18 PM
> Subject: [phobos] Looks like more problems with the array append patches
>
>
-------- Original Message --------
Subject: Memory Corruption with
> AAs
Date: Fri, 2 Apr 2010 17:15:36 +0000 (UTC)
From: dsimcha <
> ymailto="mailto:[email protected]";
> href="mailto:[email protected]";>[email protected]>
Organization: XXX
> News Server
Newsgroups: digitalmars.D
Has anyone else still been
> noticing difficult to reproduce memory corruption
issues in the presence of
> associative arrays with 2.042? They seem to happen
very infrequently
> and non-deterministically. I can only reproduce them in the
context of
> a large program. However, they don't occur in 2.040 (the release
before
> the array stomping patch), and they are clearly a result of
> memory
corruption, as contents of arrays change from what I expect them to be
> to
completely random-looking values inside a loop that does a lot of
> memory
management and uses AAs heavily but doesn't modify the
> values.
_______________________________________________
phobos mailing
> list
> href="mailto:[email protected]";>[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
