Either I'm confused or the gc is

[Steven Schveighoffer]

On 10/23/20 8:47 AM, donallen wrote:
> On Thursday, 22 October 2020 at 21:58:04 UTC, rikki cattermole wrote:
>> On 23/10/2020 4:56 AM, donallen wrote:
>>> ==3854==    by 0x1B7E98: void 
>>> verifier.main(immutable(char)[][]).walk_account_tree(verifier.main(immutable(char)[][]).Account, 
>>> int) (verifier.d:272)
>>> ==3854==  Uninitialised value was created by a stack allocation
>>> ==3854==    at 0x1B77FC: void 
>>> verifier.main(immutable(char)[][]).walk_account_tree(verifier.main(immutable(char)[][]).Account, 
>>> int) (verifier.d:84)
>>> ==3854==
>>> ==3854== Conditional jump or move depends on uninitialised value(s)
>>
>> That is coming up an awful lot.
>>
>> We'd need walk_account_tree source, to know if its doing something funky.
>>
>> But upon reviewing how the entire thing is working, I think we need 
>> one_row and next_row_available_p source as well. Oh and reset_stmt too.
> 
> Here's the source code you requested:

This all looks ok. The only think I can possibly consider is that you 
are using bind_text a lot, to presumably bind sqlite prepared statements 
to D strings.

This means it's *possible* that the prepared statements have pointers to 
the strings, but nothing else does (hard to work it out from just 
reading the code, I can't tell when things go out of scope easily, and 
your prepared statements clearly exist outside these functions). If a 
prepared statement is a C-malloc'd item, then it's not scanned by the 
GC. This means that what possibly might be happening is that you bind a 
D string to a text parameter, the D string goes out of scope, the GC 
collects it and allocates it elsewhere, and then sqlite tries to use it 
to send some requests.

To test this theory, maybe try a version of the code that when calling 
bind_text, you append the string itself to a GC allocated array stored 
in a global. Might not prove anything, but if it's fixing the problem, 
maybe that's where the GC is collecting things that it shouldn't.

-Steve