Permalink
Browse files

fix memory corruption bug in unittest

  • Loading branch information...
1 parent aedc7ee commit ef0bed7d157afe5be5a69e17d5f30ffd309be527 @WalterBright WalterBright committed Dec 25, 2012
Showing with 3 additions and 2 deletions.
  1. +3 −2 std/algorithm.d
View
@@ -2903,11 +2903,12 @@ unittest
{
struct TransientRange
{
- int[128] _buf;
+ int[] _buf;
int[][] _values;
this(int[][] values)
{
_values = values;
+ _buf = new int[128];
}
@property bool empty()
{
@@ -2980,7 +2981,7 @@ unittest
}
assert(equal(result, "abc12def34"d),
- "Unexpected result: '%s'"d.format(result));
+ "Unexpected result: '%s'"d.format(result));
}
// uniq

4 comments on commit ef0bed7

@WalterBright
Owner

The problem was an interior pointer, _buf[], to the int[128] array, which, when the struct
got copied, resulted in a pointer to a stack object that went out of scope.

Took me two days to find it :-(

@9rnsr
Member

In recent, I have thought that we should support more aggressive scope attribute.
Using it will restrict much of user program design, but provides much safety for memory corruption.
(In this case, an interior pointer should be marked as scope, and cannot escape anywhere.)
And, I think it is necessary also for the SafeD headway.

But, I don't know why current scope implementation is limited. I'd like to know the reason.

@WalterBright
Owner

There isn't a reason other than nobody has gotten around to it.

Interior pointers are disallowed in D for precisely the reason this bug was a bug. Scope isn't going to fix it. I'm not sure how to fix it.

Part of the reason it took me so long to find this bug was because it only showed up when I changed the code generator a bit, and it also only showed up on OSX 64 (the hardest to debug platform), and of course it behaved like a heisenbug. So I spent enormous time trying to figure out where the code gen went wrong.

@9rnsr
Member

Interior pointers are disallowed in D for precisely the reason this bug was a bug. Scope isn't going to fix it. I'm not sure how to fix it.

I'm just starting to think about that. So, I also cannot yet clearly answer to it.

Part of the reason it took me so long to find this bug was because it only showed up when I changed the code generator a bit, and it also only showed up on OSX 64 (the hardest to debug platform), and of course it behaved like a heisenbug. So I spent enormous time trying to figure out where the code gen went wrong.

I can imagine that it is very hard. Cheers for your good work.

There isn't a reason other than nobody has gotten around to it.

OK. I would like to try it.

Please sign in to comment.