drizzle-discuss team mailing list archive
Mailing list archive
Re: libdrizzle: drizzle_result_create on a used result structure?
Yeah, this is a known behavior. Since the memory is not initialized
in anyway when using new result structures, you can't simply add a
flag. You may just be reading leftover bits. I have thought about doing
the result scan (and you could scan all connections for a drizzle_st
structure too), but this may be more overhead than you want. I also
thought about adding that scan behavior, but make it triggered by an
optional flag that you can use while debugging. Nothing really seems
like a good answer in my mind.
As far as assertions, I try to avoid them and instead report an error
in a sane way if possible. This way you still get an error even if
folks compile with asserts off, and if libdrizzle is part of a much
larger system, it doesn't take the entire system down for what may
be a trivial piece of functionality. Unless there is no possible
way to recover from it (which is rare if you have your API correct),
I avoid assert().
Looking at your patch, that is about what I would want to do, except
look for other result lists in other connections, and wrap the check
around a behavior flag. This may be a generic flag like "do other
sanity checks", and not just specific to this check.
On Thu, Dec 10, 2009 at 05:49:21PM -0500, Evan Jones wrote:
> I found a bug in my program caused by me not calling
> drizzle_result_free before reusing a drizzle_result_st structure.
> This ends up causing an infinite loop when drizzle_result_free gets
> called in the future, since both the next and prev pointers point to
> the same thing.
> I have a hack in my branch to detect this error in one case: if you
> attempt to re-use the result structure with the same connection, I
> search the connection's result list to see if it is already there. I
> can't solve the case where you attempt to use it with another
> connection. This will likely cause a double free or similar
> situation. I'm unsure if this is worth actually including in
> libdrizzle, but the changeset is here for review:
> As a side note, what is the libdrizzle policy about assertions?
> There are a few places where I could add assert() statements that
> would crash on this error (such as when result->next ==
> result->prev). Personally I love assertions, since they would have
> made this error obvious, rather than me needing to debug an infinite
> Evan Jones