Error raised while calling 'lgi.cbk (number): Regress': attempt to call a number value

[reinerh]

The tests for lua-lgi recently started failing in Debian: #1101238

********************** lua dynamic (5.1) *********
Test: tests/test.lua

(process:29425): Lgi-WARNING **: 23:12:50.389: Error raised while calling 'lgi.cbk (number): Regress': attempt to call a number value

(process:29425): Lgi-WARNING **: 23:12:50.389: Error raised while calling 'lgi.cbk (string): Regress': attempt to call a string value

(process:29425): Lgi-WARNING **: 23:12:50.389: Error raised while calling 'lgi.cbk (table: 0x55fe2bc845a0): Regress': attempt to call a table value

(process:29425): Lgi-WARNING **: 23:12:50.389: Error raised while calling 'lgi.cbk (table: 0x55fe2bcf11e0): Regress': attempt to call a table value
gireg   : all 114 tests passed.
marshal : all 1 tests passed.
corocbk : all 3 tests passed.
record  : all 1 tests passed.

(lua5.1:29425): dbind-WARNING **: 23:12:50.941: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files

(lua5.1:29425): GLib-GObject-CRITICAL **: 23:12:50.973: Object class LgiTestFakeMonitor1 doesn't implement property 'network-metered' from interface 'GNetworkMonitor'
gobject : all 18 tests passed.
glib    : all 6 tests passed.
variant : all 15 tests passed.
dbus    : all 3 tests passed.
gtk     : all 21 tests passed.
cairo   : all 12 tests passed.
pango   :  1:glyphstring                        FAIL
             tests/pango.lua:43: failure
stack traceback:
	[C]: in function 'error'
	tests/test.lua:88: in function 'fail'
	tests/test.lua:91: in function 'check'
	tests/pango.lua:43: in function <tests/pango.lua:20>
	[C]: in function 'xpcall'
	tests/test.lua:50: in function 'runfunc'
	tests/test.lua:73: in function 'run'
	tests/test.lua:141: in main chunk
	[C]: ?
pango   : FAILED 1 of 1 tests
gio     : all 2 tests passed.

I can reproduce this error here. Does anyone have an idea?

[psychon]

recently

Do you know more? When did it start?

I am not sure what that test exactly does... It puts the text ltr שָׁוְא ltr into Pango, asks for the font Adobe Hebrew and asks for some font shaping. The failing assert is that some PangoGlyphString is empty. But this is inside a loop, so perhaps Pango just started producing some extra, empty glyph strings with some recent-ish update?

Dunno, I am just making random guesses here. Do you have a way to investigate?

[psychon]

Random guess from looking at Pango's git repo: GNOME/pango@8aa7f0b

It changes the function in question and it now has an annotation of out caller-allocates that it previously did not have. And this change was only done recently. And Debian testing has a Pango version with this change.

So perhaps it is Pango that broke lgi?

[reinerh]

Hi @psychon,

I just verified that the reason of the failure is indeed pango. In a chroot with the build succeeding (pango 1.56.1) I upgraded pango (to 1.56.2) and the builds starts failing.
The pango commit you mentioned is included since 1.56.2, so that looks like a reasonable candidate.

Does lua-lgi and/or the test now need to get adjusted for the changed pango behaviour, or is this an unintended breakage from pango?

[psychon]

Does lua-lgi and/or the test now need to get adjusted for the changed pango behaviour, or is this an unintended breakage from pango?

Sorry, but I have no clue. The failing test calls pango_shape(). This is one of the functions that got changed in GNOME/pango@8aa7f0b. Searching for shape in lgi/overrige/Pango.lua does not find anything special. Searching for GlyphString finds:

-- Pango.GlyphString is struct with counted array inside, until
-- Pango-1.38 which has fixed annotation.  Fix for previous versions.
if gi.Pango.GlyphString.fields.glyphs.typeinfo.tag ~= 'array' then
   Pango.GlyphString._attribute = { glyphs = {} }
   function Pango.GlyphString._attribute.glyphs:get()
      local array = core.record.field(self, Pango.GlyphString._field.glyphs)
      local glyphs = {}
      for i = 0, self.num_glyphs - 1 do
	 glyphs[i + 1] = core.record.fromarray(array, i)
      end
      return glyphs
   end
end

Judging from the comment, this code should not be running.

So... I cannot find any special "override" in LGI that should be active here.

Seaching for out caller-allocates find https://gi.readthedocs.io/en/latest/annotations/giannotations.html which says:

Out parameter, where the calling code must allocate storage.

Dunno what gi does without that annotation. I would guess out, but what does automatically determine allocation mean?

So... basically, I do not have much clue about gobject-introspection and Google did not immediately give me a "way to go" here and installing old Pango versions for experiments is complicated (and right now, I do not even have Lua installed anymore...).

[psychon]

Searching in LGI's C code for caller-allocates finds the following, which could be related:

lgi/lgi/callable.c

Lines 910 to 930 in a412921

	if (param->dir != GI_DIRECTION_OUT)
	nret += callable_param_2c (L, param, lua_argi++, 0, &args[argi],
	1, callable, ffi_args);
	/* Special handling for out/caller-alloc structures; we have to
	manually pre-create them and store them on the stack. */
	else if (callable->info && g_arg_info_is_caller_allocates (&param->ai)
	&& lgi_marshal_2c_caller_alloc (L, param->ti, &args[argi], 0))
	{
	/* Even when marked as OUT, caller-allocates arguments
	behave as if they are actually IN from libffi POV. */
	ffi_args[argi] = &args[argi];
	/* Move the value on the stack *below* any already present
	temporary values. */
	lua_insert (L, -nret - 1);
	caller_allocated++;
	}
	else
	/* Normal OUT parameters. Ideally we don't have to touch
	them, but see https://github.com/pavouk/lgi/issues/118 */
	memset (&args[argi], 0, sizeof (args[argi]));

Hm... since there was no annotation before, perhaps GI ended up interpreting this as an in in parameter? Otherwise... the memset() here would mean that a NULL pointer where passed as the argument, which does not sound correct at all.

[reinerh]

Someone submitted a patch that fixes the test failure to the Debian bugtracker. I forwarded it to #342.