From @TimToady

10​:41 < TimToady> m​: say "𢡊"
10​:41 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
10​:42 < TimToady> jnthn​: ^^ there's another glitch :)
10​:43 < timotimo> can you also make that with a \x literal, so that i can
more easily copy-paste it?
10​:47 < TimToady> m​: say "\xfacf"
10​:47 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
10​:47 < TimToady> m​: say "\xfad0"
10​:47 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
10​:48 < [Coke]> O_o
10​:48 < TimToady> m​: say "\xfad9"
10​:48 <+camelia> rakudo-moar 691b39​: OUTPUT«龎␤»
10​:49 < TimToady> m​: say "\xfad8"
10​:49 <+camelia> rakudo-moar 691b39​: OUTPUT«齃␤»
10​:49 < TimToady> m​: say "\xfad7"
10​:49 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
10​:49 < TimToady> there's the boundary
10​:50 < TimToady> that trailing boundary, facf is the leading boundary
10​:50 < TimToady> timotimo​: thanks
10​:51 < timotimo> er, thanks why exactly?
10​:52 < TimToady> for copy-pasting it :)
10​:52 < timotimo> damn, you expect me to fix that bug now? ;)
10​:52 < TimToady> or at least for wanting to copy-paste it :)
10​:53 < timotimo> 48543 const MVMint32 *pcs =
comp_p[plane][upper][lower];
10​:53 < timotimo> the values of the indices are, respectively, <optimized
out>, <optimized out>, and <optimized out>
10​:53 < timotimo> :P
10​:53 < TimToady> cool!
10​:54 < TimToady> "Nobody will ever use those characters!"
10​:54 < timotimo> 2, 126, and 211
10​:55 < timotimo> (gdb) print comp_p[2][126]
10​:55 < timotimo> $5 = (const MVMint32 **) 0x0
10​:56 * TimToady notes that those are, in fact, plane 0 characters
10​:56 < timotimo> so ... do we actually expect there to be something?
10​:57 < TimToady> I wouldn't expect to find something in plane 2 for them,
no :)
11​:01 < timotimo> i personally haven't a clue what that particular piece of
code is precisely supposed to achieve; you said it's supposed to
  be plane 0, do you know why it'd get plane 2 instead?
11​:02 < timotimo> given plane is just (l >> 16) & 0xF
11​:03 < TimToady> maybe upstream, the same remapping thingy that turns 艹
into 艹 is turning those compat chars into something in plane 2?
11​:03 < TimToady> but then they should find something
11​:04 < TimToady> m​: say "𢡊".ord.base(16)
11​:04 <+camelia> rakudo-moar 691b39​: OUTPUT«2284A␤»
11​:04 -!- prammer [~prammer@​157.130.171.46] has joined #perl6
11​:04 < TimToady> yeah, looks like that's what's going on
11​:05 < TimToady> m​: say "𢡊".ord.base(16).chr
11​:05 <+camelia> rakudo-moar 691b39​: OUTPUT«Cannot convert string to
number​: trailing characters after number in '2284⏏A' (indicated by ⏏)␤
  in block <unit> at /tmp/fFGuCOiKMA line 1␤␤Actually thrown
at​:␤ in block <unit> at /tmp/fFGuCOiKMA line 1␤␤»
11​:05 < TimToady> m​: say "𢡊".ord..chr
11​:05 <+camelia> rakudo-moar 691b39​: OUTPUT«===SORRY!===␤Argument to "chr"
seems to be malformed␤at /tmp/EXvSTh8KTb​:1␤------> say
  "𢡊".ord..chr⏏<EOL>␤Other potential difficulties​:␤
Unsupported use of bare "chr"; in Perl 6 please use .chr if you meant
  $_, or use an expli…»
11​:05 < TimToady> m​: say "𢡊".ord.chr
11​:05 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
11​:05 < TimToady> m​: say "\x2284a"
11​:05 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
11​:06 < timotimo> https://gist.github.com/timo/0566aa167dbf0996bab9
11​:06 < timotimo> that's the full backtrace of the thing you originally
made copy-pastable
11​:06 < TimToady> m​: say "𢡊"
11​:06 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
11​:06 < TimToady> that's the actual plane 2 character that can't print

From @jnthn

On Fri Feb 12 13​:35​:21 2016, larry wrote​:

10​:41 < TimToady> m​: say "𢡊"
10​:41 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
10​:42 < TimToady> jnthn​: ^^ there's another glitch :)
10​:43 < timotimo> can you also make that with a \x literal, so that i can
more easily copy-paste it?
10​:47 < TimToady> m​: say "\xfacf"
10​:47 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
10​:47 < TimToady> m​: say "\xfad0"
10​:47 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
10​:48 < [Coke]> O_o
10​:48 < TimToady> m​: say "\xfad9"
10​:48 <+camelia> rakudo-moar 691b39​: OUTPUT«龎␤»
10​:49 < TimToady> m​: say "\xfad8"
10​:49 <+camelia> rakudo-moar 691b39​: OUTPUT«齃␤»
10​:49 < TimToady> m​: say "\xfad7"
10​:49 <+camelia> rakudo-moar 691b39​: OUTPUT«(signal SEGV)»
10​:49 < TimToady> there's the boundary
10​:50 < TimToady> that trailing boundary, facf is the leading boundary

Turned out to be a silly thinko of mine that we'd just never managed to run into before. Fixed in MoarVM, and tests covering these added to S15-nfg/concatenation.t (the SEGV golfed to "\xfad7" ~ "\n").

/jnthn

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

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