Harfbuzz error?

d0oo0p · April 28, 2017, 12:37pm

So i’m getting this error from time to time in my application, and i’m not really sure of how to fix it?
I’m targeting c++ on windows.

singmajesty · April 29, 2017, 1:11am

Does this occur immediately, or after running for a long time? Does it seem connected with anything related to TextField?

d0oo0p · April 29, 2017, 6:39am

It happens just from time to time, not always.

I think it is related to reading or setting the text of a textfield, but I’m checking for null values before setting text, and it’s not catching anything.

d0oo0p · May 2, 2017, 5:49am

Any clues to what steps I could take to prevent this? I really need to find out what causes this and how to prevent it. Is it caused by a bad value, or an issue with harfbuzz itself?

singmajesty · May 2, 2017, 6:02pm

What versions of Lime and OpenFL are you using?

d0oo0p · May 2, 2017, 6:28pm

Hi.
I’m currently using the latest released versions : Haxe 3.4.2, Lime 4.0.3 , OpenFL 4.9.2, hxcpp 3.4.64 on Windows 10.

singmajesty · May 2, 2017, 11:49pm

Hmm, there’s very little information to go on. If it’s a bug in Harfbuzz itself, the newer version we are using in the Lime dev repository may help, but if its incorrect usage of Harfbuzz, then I’m not immediately sure what to do to try and look into this further. What language are you using in the TextField? I wonder if it’s a UTF-8 issue

d0oo0p · May 3, 2017, 10:01am

Hm, i see that. I i’m not a 100% sure but i think the problem comes from a value thats in a dynamic textfield thats constantly updating. If i’m not wrong, the text is just a numeric value, and its being fed into the application via udp, But i’m checking for bad values, null, NaN and all i can think of. And it doesnt catch anything.

d0oo0p · May 3, 2017, 10:02am

Looking at the error, does it have anything to do with a null value?

player_03 · May 4, 2017, 3:23am

Here’s the line the error points to:

github.com

native-toolkit/harfbuzz/blob/395599e2536e043251e3eedf37ce4ae3b9f445b9/src/hb-buffer.cc#L638


if (DEBUG_ENABLED (BUFFER))
  dump_var_allocation (this);


DEBUG_MSG (BUFFER, this,
	     "Deallocating var bytes %d..%d for %s",
	     byte_i, byte_i + count - 1, owner);


assert (byte_i < 8 && byte_i + count <= 8);
for (unsigned int i = byte_i; i < byte_i + count; i++) {
  assert (allocated_var_bytes[i]);
  assert (0 == strcmp (allocated_var_owner[i], owner));
  allocated_var_bytes[i]--;
}
}


void hb_buffer_t::assert_var (unsigned int byte_i, unsigned int count, const char *owner)
{
if (DEBUG_ENABLED (BUFFER))
  dump_var_allocation (this);


DEBUG_MSG (BUFFER, this,

Looks like Harfbuzz was trying to deallocate a variable, but part of that variable was already registered to another “owner.” Either that or the owner variable was invalid.

I was going to suggest some steps to debug that line, but it actually looks like the deallocation code has been completely revised. You may be able to solve this problem by updating Lime.

d0oo0p · May 5, 2017, 4:47pm

Great! Thank you for looking into this!
So i’ve updated my application to Lime 4.1.0 and OpenFL 5.0. I have to see how it goes as its kind of hard to reproduce the error, but there should be a chance this will fix the issue?

I saw there was a lot of Harfbuzz updates in the latest version of Lime?

singmajesty · May 5, 2017, 5:46pm

Yep, we updated Harfbuzz from 0.9 something to 1.4.6, so it’s possible this resolves your instability issue. Please let me know how testing goes

d0oo0p · May 5, 2017, 6:41pm

Perfect! Thank you so much!
Will let you know if it solved the issue

d0oo0p · May 8, 2017, 12:00pm

Well seems there are still issues, but not the same problem as before?
Now i’m getting this error:

player_03 · May 10, 2017, 5:38am

That’s this line:

github.com

native-toolkit/harfbuzz/blob/master/src/hb-buffer.cc#L333


out_info = info;


memset (pos, 0, sizeof (pos[0]) * len);
}


void
hb_buffer_t::swap_buffers (void)
{
if (unlikely (in_error)) return;


assert (have_output);
have_output = false;


if (out_info != info)
{
  hb_glyph_info_t *tmp_string;
  tmp_string = info;
  info = out_info;
  out_info = tmp_string;
  pos = (hb_glyph_position_t *) out_info;
}

The variable is declared here, and this is the only place it’s set to true. So either swap_buffers() is being called too often, or clear_output() isn’t being called often enough.

Not sure how you’d fix that, though.