> On Mon, Apr 27, 2015 at 04:31:59AM -0400, Jeff Darcy wrote: > > That looks closely related to the bug that was fixed by the > > following patch: > > > > http://review.gluster.org/#/c/10319/ > > No, I already have it in tree. This is another problem. Yes, it is another problem, but it's a *related* problem. In fact it's the third of these that we've hit; the first was in option-validation code. http://review.gluster.org/#/c/10238/ What these all have in common is the following sequence: * An object is allocated for a translator (as THIS) * The translator is freed * The object is freed * Memory-tracking code tries to dereference from the object through the translator * BOOM We can address this particular bug the same way we addressed the second, by making sure the objects allocated in the log subsystem are associated with global_xlator (which never goes away). On the other hand, something that has bitten us three times is likely to keep biting us until we address the common root cause. Maybe we should change the way we track memory so that the translator *can't* be freed while other objects still point to it. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
