Either I'm confused or the gc is
Steven Schveighoffer
schveiguy at gmail.com
Sat Oct 24 15:04:53 UTC 2020
On 10/24/20 10:21 AM, donallen wrote:
> On Friday, 23 October 2020 at 23:41:05 UTC, rikki cattermole wrote:
>> Thanks!
>>
>> The problem is not in that block of code I believe.
>>
>> Now how about bind_text?
>>
>> Is that still using c variadic args?
>
> No. Read on.
>
> The detective in me couldn't resist (I really need a Peugeot and a
> basset hound) and so I did some more work on this despite not really
> having the time and I have made some progress.
Very nice!
I wonder if the corruption is happening on the account.guid. Since we
are talking about sqlite, which is a local DB, and not sending
information to a server (where it can't be corrupted), it's possible the
guid is being corrupted causing the premature exit of the loop.
Can you print out the guid after in the premature exit case to make sure
it hasn't changed?
> This does not panic! In theory, this should consume the same amount of
> GC memory as the format call (though I have not looked at the format
> code; there may well
> be intermediate allocations as it does its work).
Just for informational purposes, an append statement between N strings
allocates one block that holds all of them. Format appends, so it may
involve multiple allocations, though it's possible it does a similar
shortcut. I'm very interested in this code, I will look at the case for
format, and see if I can sleuth out any possible corruption possibilities.
>
> No panic. So there appears to be a problem in format when dealing with
> strings fed to an unconstrained %s, probably when interacting the
> garbage collector. My guess is that the issue is
> in format, not the gc.
Yeah, I tend to agree. More specifically, it could be in appender as
well (which is what format uses to allocate memory).
> That's as far as I've gotten. But I think we know more now than before.
Good work, and I think we can probably get to the bottom of it, lots of
great information!
-Steve
More information about the Digitalmars-d
mailing list