Either I'm confused or the gc is

[H. S. Teoh]

On Wed, Oct 21, 2020 at 09:35:43PM +0000, donallen via Digitalmars-d wrote:
[...]
> As I understand it from the documentation, dynamic arrays are
> represented as fat pointers that contain the array size and a pointer
> to the actual data in the heap. I assume, though the documentation
> doesn't say, that the size/pointer structure is on the stack.

That is correct, since you declared the `children` array as a local
variable.


> If so, every one of the children arrays has a pointer to it on the
> stack as the descent through the tree proceeds and therefore should
> not be garbage collectible until a particular call to the tree walker
> (of which I've provided the last bit of code, which deals with
> descending into the child accounts) returns to its caller.

Also correct. Barring a bug in the GC.


> It does look to me like those arrays are being collected prematurely
> and incorrectly.

It would appear to be so, but it's really hard to say without being able
to reproduce the problem locally.  Another possibility is memory
corruption caused by incorrect translation of C code to D. Generally,
this should be pretty rare: Walter designed D syntax to be similar to C
syntax such that if it compiles, it should work exactly as it does in
C, otherwise there should be a compile error.  But there *are* corner
cases where this may inadvertently happen.

There are also some gotchas with interfacing D code with C libraries
(sqlite, as you mentioned), which may appear to work at first but may
introduce subtle memory problems if not used correctly.

Of course, there *is* the possibility that there's a bug in the GC that
causes it to collect prematurely, but IMO the chances of that are pretty
low, because D arrays are one of its most-used core features, and if
something so basic doesn't work correctly, we would have seen (and
fixed) the problem a long time ago.  At least, it would have surfaced in
some of the large D projects out there.  But I haven't heard of any such
problem recently, except in connection with code that interfaces with C,
where sometimes mistakes can happen and memory corruption results.

But on the off-chance there *is* a bug in the GC: we'd greatly
appreciate it if you could somehow reduce the problem to a minimal test
case that we can reproduce locally so that we can investigate.


T

-- 
Не дорог подарок, дорога любовь.