NativeCall SEGV from GtkListStore init.

NativeCall SEGV from GtkListStore init.md

UPDATE -- Problem solved. Types were assigned to a 32-bit value, when it should have been 64.

Getting a segment fault from the following code:

use v6.c;

use NativeCall;

sub gtk_list_store_newv (int32 $n_columns, CArray[uint32] $types)
  returns Pointer
  is native('gtk-3')
  { * }

my @types = (64, 64, 20);
my $t = CArray[int32].new;
$t[$++]=$_ for @types;

say gtk_list_store_newv($t.elems, $t);

Backtrace from perl6-gdb-m is:

================================================================================================
This is Rakudo Perl 6 running in the GNU debugger, which often allows the user to generate useful back-
traces to debug or report issues in Rakudo, the MoarVM backend or the currently running code.

This Rakudo version is 2018.09.416.g.9894.eda.5.b built on MoarVM version 2018.09.124.g.588873.f.7.a,
running on ubuntu (18.10.Cosmic.Cuttlefish) / linux (4.18.0.9.generic)

Type `bt full` to generate a backtrace if applicable, type `q` to quit or `help` for help.
------------------------------------------------------------------------------------------------
Reading symbols from /home/cbwood/Projects/rakudobrew/moar-master/install/bin/moar...(no debugging symbols found)...done.
Starting program: /home/cbwood/Projects/rakudobrew/moar-master/install/bin/moar --execname=/home/cbwood/Projects/rakudobrew/bin/../moar-master/install/bin/perl6-gdb-m --libpath=/home/cbwood/Projects/rakudobrew/moar-master/install/share/nqp/lib --libpath=/home/cbwood/Projects/rakudobrew/moar-master/install/share/perl6/lib --libpath=/home/cbwood/Projects/rakudobrew/moar-master/install/share/perl6/runtime /home/cbwood/Projects/rakudobrew/moar-master/install/share/perl6/runtime/perl6.moarvm test_list.pl6
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6e01700 (LWP 17267)]

Thread 1 "moar" received signal SIGSEGV, Segmentation fault.
0x00007ffff412011f in g_type_check_is_value_type () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
(gdb) bt
#0  0x00007ffff412011f in g_type_check_is_value_type () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x00007fffeecae3ae in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so
#2  0x00007fffeeba8838 in gtk_list_store_newv () at /usr/lib/x86_64-linux-gnu/libgtk-3.so
#3  0x00007ffff79285b4 in dcCall_x64_sysv () at //home/cbwood/Projects/rakudobrew/moar-master/install/lib/libmoar.so
#4  0x0000555555758ca0 in  ()
#5  0x00007fffffffd680 in  ()
#6  0x00007ffff79284ed in dc_callvm_call_x64 () at //home/cbwood/Projects/rakudobrew/moar-master/install/lib/libmoar.so

There does not seem to be any tc information from which to do an MVM_dump_backtrace.

Should this be a ticket?

Well, it could be that gtk_list_store_newv is doing something naughty, or is expecting int64 even though the documentation says otherwise.

OOC, why not do my $t = CArray[int32].new(64,64,20) ?

Oddly enough, if you use only one type, it works.

my @types = (20);  # Replace with 64 and it will also work.
my $t = CArray[uint32].new;
$t[$++]=$_ for @types;

say gtk_list_store_newv($t.elems, $t);

It's when you add something beyond that singular, that it doesn't.