Thanks Bradley. I think I fixed the problem. In a few days I'm going to remove the mutex from blob, but for now the fix should work.
behdad On 04/25/11 13:09, Bradley Grainger wrote: > hb_blob_create_sub_blob creates a new hb_blob_t*, but never initialises the > "blob->lock" field. (Instead, the implementation of the method uses > parent->lock when calling hb_mutex_lock.) > > If hb_blob_lock (which appears to be part of the public API) is called with > one of these sub blobs, it will attempt to use the sub blob's lock field, but > that field is still set (by HB_OBJECT_DO_CREATE) to all zeros. > > Best case, hb_mutex_lock (however it is defined) will do nothing, leading to > a potential race condition; worst case, it will crash the program or exhibit > undefined behaviour. > > It seems like hb_blob_lock should detect one of these "sub blobs" (perhaps > some sort of flag would need to be defined in _hb_blob_t, or perhaps > blob->lock could be set to some special sentinel value?) and lock on > "((hb_blob_t *) blob->user_data)->lock" instead of "blob->lock" in that > situation. > > Bradley > _______________________________________________ > HarfBuzz mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/harfbuzz > _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
