SEGV feeding a channel

[p6rt]

Migrated from rt.perl.org#127700 (status was 'resolved')

Searchable as RT127700$

[p6rt]

From @jonathanstowe

The following code will segfault after some thousand iterations​:

#!perl6

use NativeCall;

my $samplerate = 44100;
my $frequency = 440;

sub gen-sin(Int $sample-rate, Int $frequency) {
  gather {
  loop {
  for (0 .. ($samplerate/$frequency)).map({ sin(($_/($samplerate/$frequency)) * (2 * pi))}) -> $val {
  take $val;
  }
  }
  }
}

my $chan = Channel.new;

start {
  for gen-sin($samplerate, $frequency).rotor(256) -> @​a {
  my $c = CArray[num32].new(flat @​a Z @​a);
  $chan.send([$c, 256]);
  }
}

sleep 5;

my $now = now;
react {
  whenever $chan {
  sleep 256/44100;
  say now - $now;
  $now = now;
  }
}

# vim​: expandtab shiftwidth=4 ft=perl6

Giving rise to (gdb output)​:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeffff700 (LWP 5923)]
0x00007ffff7aeb4ef in MVM_args_slurpy_named ()
  from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
Missing separate debuginfos, use​: dnf debuginfo-install glibc-2.21-12.fc22.x86_64
(gdb) bt full
#​0 0x00007ffff7aeb4ef in MVM_args_slurpy_named ()
  from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​1 0x00007ffff7af1446 in MVM_interp_run ()
  from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​2 0x00007ffff7b0de7e in start_thread ()
  from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​3 0x00007ffff7bcb3a7 in uv.thread_start ()
  from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​4 0x0000003539c07555 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#​5 0x0000003539902ded in clone () from /lib64/libc.so.6
No symbol table info available.

I'm guessing that it's the the Channel.send

This is Rakudo version 2016.02-136-g3a050fb built on MoarVM version 2016.02-25-gada3752

P.S. If the loop that feeds the channel could be at least 10x faster that would be lovely kthx ;-)

[p6rt]

From @jonathanstowe

Slightly golfed​:

use NativeCall;

my $chan = Channel.new;

sub gen() {
  gather {
  loop {
  take 0e0;
  }
  }
}

start {
  for gen.rotor(512) -> @​a {
  my $c = CArray[num32].new(@​a);
  $chan.send([$c, 256]);
  }
}

sleep 5;

my $now = now;
react {
  whenever $chan {
  sleep 256/44100;
  say now - $now;
  $now = now;
  }
}

The simplest case (no gather or rotor) doesn't segfault.

[p6rt]

From @jonathanstowe

Further to this (to eliminate golf targets)

Neither​:

use NativeCall;

my $chan = Channel.new;

start {
  for (0 .. Inf).rotor(512) -> @​a {
  my $c = CArray[num32].new(@​a.map({ Num($_) }));
  $chan.send([$c, 256]);
  }
}

sleep 5;

my $now = now;
react {
  whenever $chan {
  sleep 256/44100;
  say now - $now;
  $now = now;
  }
}

Nor

#!perl6

use NativeCall;

my $chan = Channel.new;

sub gen() {
  gather {
  loop {
  take (0e0 xx 512);
  }
  }
}
start {
  for gen() -> @​a {
  my $c = CArray[num32].new(@​a);
  $chan.send([$c, 256]);
  }
}

sleep 5;

my $now = now;
react {
  whenever $chan {
  sleep 256/44100;
  say now - $now;
  $now = now;
  }
}

Show the same problem, for several hundreds of thousands of iterations, so the combination of rotor and the iterator does seem to have a bearing.

[p6rt]

From @jonathanstowe

I've just retested with

This is Rakudo version 2016.02-156-gd56b686 built on MoarVM version 2016.02-33-g1e3d2ac

The very first, full, example still segfaults with the backtrace

[Switching to Thread 0x7fffdffff700 (LWP 28906)]
0x00007ffff7aeb5df in MVM_args_slurpy_named () from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
Missing separate debuginfos, use​: dnf debuginfo-install glibc-2.21-13.fc22.x86_64
(gdb) bt full
#​0 0x00007ffff7aeb5df in MVM_args_slurpy_named () from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​1 0x00007ffff7af17c1 in MVM_interp_run () from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​2 0x00007ffff7b0e01e in start_thread () from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​3 0x00007ffff7bcb7c7 in uv.thread_start () from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​4 0x0000003b44607555 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#​5 0x0000003b44302ded in clone () from /lib64/libc.so.6
No symbol table info available.

The other examples (including the second which *did* previously segv) do not fail after "many" iterations, (something like 10,000.)

I can't offer any suggestions as to why it is difficult to replicate.

[p6rt]

From @jonathanstowe

Confirmed on another machine just to check it's not something weird that makes it non-reproducible.

On Tue Mar 15 15​:35​:12 2016, jns+bc@​gellyfish.co.uk wrote​:

I've just retested with

This is Rakudo version 2016.02-156-gd56b686 built on MoarVM version
2016.02-33-g1e3d2ac

The very first, full, example still segfaults with the backtrace

[Switching to Thread 0x7fffdffff700 (LWP 28906)]
0x00007ffff7aeb5df in MVM_args_slurpy_named () from
/home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
Missing separate debuginfos, use​: dnf debuginfo-install glibc-2.21-
13.fc22.x86_64
(gdb) bt full
#​0 0x00007ffff7aeb5df in MVM_args_slurpy_named () from
/home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​1 0x00007ffff7af17c1 in MVM_interp_run () from
/home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​2 0x00007ffff7b0e01e in start_thread () from
/home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​3 0x00007ffff7bcb7c7 in uv.thread_start () from
/home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so
No symbol table info available.
#​4 0x0000003b44607555 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#​5 0x0000003b44302ded in clone () from /lib64/libc.so.6
No symbol table info available.

The other examples (including the second which *did* previously segv)
do not fail after "many" iterations, (something like 10,000.)

I can't offer any suggestions as to why it is difficult to replicate.

[p6rt]

From @zoffixznet

Can't reproduce it on today's Rakudo.

The example code is pretty complex. Do we still add it to tests or can we close this ticket without them? Where would these tests go? Into roast or rakudo's t/ along with other NativeCall tests?

zoffix@​VirtualBox​:~$ perl6 -v
This is Rakudo version 2016.06-154-g55c359e built on MoarVM version 2016.06-9-g8fc21d5
implementing Perl 6.c.
zoffix@​VirtualBox​:~$ uname -a
Linux VirtualBox 4.2.0-30-generic #​36~14.04.1-Ubuntu SMP Fri Feb 26 18​:49​:23 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[p6rt]

The RT System itself - Status changed from 'new' to 'open'

[p6rt]

From @zoffixznet

Closing as resolved, without tests, per http://irclog.perlgeek.de/perl6-dev/2016-07-10#i_12817089

[p6rt]

@zoffixznet - Status changed from 'open' to 'resolved'

[p6rt]

From @jonathanstowe

Yeah, confirmed that it doesn't segv any more.

On Sun Jul 10 11​:40​:24 2016, cpan@​zoffix.com wrote​:

Closing as resolved, without tests, per
http://irclog.perlgeek.de/perl6-dev/2016-07-10#i_12817089