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
