Hi Evan, 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. Thanks! -Eric 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: > > https://code.launchpad.net/~evanj/libdrizzle/dev > > > 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 > loop. > > Evan > > -- > Evan Jones > http://evanjones.ca/ _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
