Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SEGV feeding a channel #5173

Closed
p6rt opened this issue Mar 13, 2016 · 10 comments
Closed

SEGV feeding a channel #5173

p6rt opened this issue Mar 13, 2016 · 10 comments
Labels

Comments

@p6rt
Copy link

@p6rt p6rt commented Mar 13, 2016

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

Searchable as RT127700$

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 13, 2016

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
Copy link
Author

@p6rt p6rt commented Mar 13, 2016

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
Copy link
Author

@p6rt p6rt commented Mar 13, 2016

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
Copy link
Author

@p6rt p6rt commented Mar 15, 2016

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
Copy link
Author

@p6rt p6rt commented Mar 15, 2016

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
Copy link
Author

@p6rt p6rt commented Jul 10, 2016

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
Copy link
Author

@p6rt p6rt commented Jul 10, 2016

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

@p6rt
Copy link
Author

@p6rt p6rt commented Jul 10, 2016

From @zoffixznet

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

@p6rt
Copy link
Author

@p6rt p6rt commented Jul 10, 2016

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

@p6rt p6rt closed this Jul 10, 2016
@p6rt
Copy link
Author

@p6rt p6rt commented Jul 13, 2016

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

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant