[perl #126390] [BUG] await start {} hangs when using HTTP::UserAgent

[Jan-Olof Hendig via RT]

On Wed, 30 Dec 2015 09:12:25 -0800, c...@zoffix.com wrote:
> To give an update on this. With Rakudo built on Dec 30, 2015, I no
> longer get any hangs with neither
> perl6 -MURI -e 'await start { say URI.new("http://localhost;) };'
> 
> nor perl6 -MIETF::RFC_Grammar::URI -e "await Promise.in(1).then({
> require IETF::RFC_Grammar::URI });"
> 
> This is on Debian Wheezy. I tried both on 32bit 2-core and 64bit 1-
> core boxes.

This problem has been fixed. Part of the problem seems to have been the
use of require in a thread, i.e. RT #126587. 

[perl #126390] [BUG] await start {} hangs when using HTTP::UserAgent

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW it's not possible to reproduce the issue on older rakudos because it was
sweeped under the rug in the URI module itself:
https://github.com/perl6-community-modules/uri/issues/21

So yes, #126587 is a “testneeded” ticket for the underlying issue.

On 2018-03-09 12:58:27, jan-olof.hen...@bredband.net wrote:
> On Wed, 30 Dec 2015 09:12:25 -0800, c...@zoffix.com wrote:
> > To give an update on this. With Rakudo built on Dec 30, 2015, I no
> > longer get any hangs with neither
> > perl6 -MURI -e 'await start { say URI.new("http://localhost;) };'
> >
> > nor perl6 -MIETF::RFC_Grammar::URI -e "await Promise.in(1).then({
> > require IETF::RFC_Grammar::URI });"
> >
> > This is on Debian Wheezy. I tried both on 32bit 2-core and 64bit 1-
> > core boxes.
>
> This problem has been fixed. Part of the problem seems to have been the
> use of require in a thread, i.e. RT #126587.

[perl #128553] [SEGV] multi method cache causes Base64 regression

[Jan-Olof Hendig via RT]

On Wed, 27 Jul 2016 17:43:48 -0700, lloyd.fo...@gmail.com wrote:
> By flag_map I mean ctx->callsite->arg_flags:
> 
> (lldb) p ctx->arg_flags
> (MVMCallsiteEntry *) $8 = 0x
> (lldb) p ctx->callsite->arg_flags
> (MVMCallsiteEntry *) $9 = 0x10a72533 ""
> 
> On Mon, Jul 11, 2016 at 3:59 AM Lloyd Fournier 
> wrote:
> 
> > I've been getting segfaults in this area recently. The trace is a bit
> > different but I guess it's related. It seems that flag_map in gc_mark
> > is no
> > longer allocated so I get segfault.
> >
> > (lldb) r
> > There is a running process, kill it and restart?: [Y/n] y
> > Process 75673 exited with status = 9 (0x0009)
> > Process 75691 launched: '/Users/llfourn/src/rakudo/install/bin/moar'
> > (x86_64)
> > Process 75691 stopped
> > * thread #1: tid = 0x23cfc68, 0x000100063ca4
> > libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> > data=, worklist=0x00010d27c1a0) + 84 at
> > MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
> > EXC_BAD_ACCESS (code=1, address=0x10a72533)
> > frame #0: 0x000100063ca4
> > libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> > data=, worklist=0x00010d27c1a0) + 84 at
> > MVMCallCapture.c:55
> >52  MVMuint16  count = ctx->arg_count;
> >53  MVMuint16  i, flag;
> >54  for (i = 0, flag = 0; i < count; i++, flag++) {
> > -> 55  if (flag_map[flag] & MVM_CALLSITE_ARG_NAMED) {
> >56  /* Current position is name, then next is
> > value. */
> >57  MVM_gc_worklist_add(tc, worklist, 
> > >args[i].s);
> >58  i++;
> > (lldb) bt
> > * thread #1: tid = 0x23cfc68, 0x000100063ca4
> > libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> > data=, worklist=0x00010d27c1a0) + 84 at
> > MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
> > EXC_BAD_ACCESS (code=1, address=0x10a72533)
> >   * frame #0: 0x000100063ca4
> > libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> > data=, worklist=0x00010d27c1a0) + 84 at
> > MVMCallCapture.c:55
> > frame #1: 0x00010003f002
> > libmoar.dylib`MVM_gc_mark_collectable(tc=,
> > worklist=, new_addr=) + 1714 at
> > collect.c:399
> > frame #2: 0x00010003e883
> > libmoar.dylib`process_worklist(tc=0x000100500290,
> > worklist=0x00010d27c1a0, wtp=0x7fff5fbff468, gen='\0') + 899
> > at
> > collect.c:313
> > frame #3: 0x00010003e324
> > libmoar.dylib`MVM_gc_collect(tc=0x000100500290,
> > what_to_do=, gen=) + 820 at collect.c:129
> > frame #4: 0x00010003b703
> > libmoar.dylib`run_gc(tc=0x000100500290, what_to_do='\0') + 131 at
> > orchestrate.c:304
> > frame #5: 0x00010003b4c8
> > libmoar.dylib`MVM_gc_enter_from_allocator(tc=0x000100500290) +
> > 984 at
> > orchestrate.c:438
> > frame #6: 0x00010003bca8 libmoar.dylib`MVM_gc_allocate_zeroed
> > [inlined] MVM_gc_allocate_nursery(tc=,
> > size=) +
> > 52 at allocation.c:32
> > frame #7: 0x00010003bc74 libmoar.dylib`MVM_gc_allocate_zeroed
> > [inlined] MVM_gc_allocate(tc=) + 23 at allocation.h:13
> > frame #8: 0x00010003bc5d
> > libmoar.dylib`MVM_gc_allocate_zeroed(tc=0x000100500290, size=40)
> > + 13
> > at allocation.c:49
> > frame #9: 0x00010003bf44
> > libmoar.dylib`MVM_gc_allocate_object(tc=0x000100500290,
> > st=) + 84 at allocation.c:86
> > frame #10: 0x00010005813f
> > libmoar.dylib`allocate(tc=,
> > st=) + 15 at P6opaque.c:60
> > frame #11: 0x000100050d27 libmoar.dylib`MVM_repr_box_str
> > [inlined]
> > MVM_repr_alloc_init(tc=0x000100500290, type=0x000101626fc0) +
> > 14 at
> > reprconv.c:13
> > frame #12: 0x000100050d19
> > libmoar.dylib`MVM_repr_box_str(tc=0x000100500290,
> > type=0x000101626fc0, val=) + 73 at reprconv.c:586
> > frame #13: 0x00019c07
> > libmoar.dylib`MVM_exception_backtrace(tc=0x000100500290,
> > ex_obj=) +  at exceptions.c:407
> > frame #14: 0x000100017488
> > libmoar.dylib`MVM_interp_run(tc=0x000100500290,
> > initial_invoke=, invoke_data=) + 47320 at
> > interp.c:3830
> > frame #15: 0x0001000c8305
> > libmoar.dylib`MVM_vm_run_file(instance=,
> > filename=) + 181 at moar.c:304
> > frame #16: 0x0001170a moar`main(argc=,
> > argv=0x7fff5fbff8e8) + 666 at main.c:191
> > frame #17: 0x7fff900c05ad libdyld.dylib`start + 1
> > frame #18: 0x7fff900c05ad libdyld.dylib`start + 1
> > (lldb) fr v
> > (MVMThreadContext *) tc = 0x000100500290
> > (MVMSTable *) st = 0x000101004f40
> > (void *) data = 
> >
> > (MVMGCWorklist *) worklist = 0x00010d27c1a0
> > (MVMCallCaptureBody *) body =  > optimized
> > out>
> >
> > (MVMArgProcContext *) ctx = 0x00010a6f3c00
> > (MVMuint16) flag = 0
> > (MVMuint16) i = 0
> > (MVMuint16) count = 
> >
> > (MVMuint8 *) flag_map = 

[perl #127011] [LTA] bad error when initialising Int var to Inf or NaN

[Jan-Olof Hendig via RT]

Duplicate of #126990 which has been resolved.

[perl #126587] [SEGV] require inside thread segfault hang

[Aleks-Daniel Jakimenko-Aleksejev via RT]

dogbert++ noticed me that this issue is resolved (according to the provided
snippets). It is indeed so.

Second snippet may need this change:

-return 200, ['Content-Type' => 'text/plain'], 'we win';
+return 200, ['Content-Type' => 'text/plain'], ['we win'];

I can confirm that both issues are not reproducible using recent-ish rakudo,
but I can't tell when these problems were fixed. The first problem is not
really reproducible on any rakudo, even the one mentioned in the OP (huh??).
Also, there's some problem using HTTP::Server::Tiny on pre 2015.12 rakudos
(“Supplier” did not exist back then?).

Anyway, marking as ｢testneeded｣. If anybody wants to find what commit affected
these snippets, I'm pretty sure you'll have to bisect it manually without a
bot.

On 2015-11-08 01:11:45, lloyd.fo...@gmail.com wrote:
> Two async + require bugs. Replace LWP::Simple with whatever you like
> (except for builtins like Test which seem to work no matter what)
>
> 1. segfault
>
> Thread.start({ say "entering"; require LWP::Simple; say "leaving" })
> #both enters and leaves but segfault when it's done.
>
> 2. HTTP::Server::Tiny hangs
>
> use HTTP::Server::Tiny;
>
> HTTP::Server::Tiny.new(port => 8080).run: sub ($env) {
> note "requiring!";
> require LWP::Simple; # or whatever
> note "we got it!";
> return 200, ['Content-Type' => 'text/plain'], 'we win';
> };
>
> # then curl localhost:8080, you'll only get "requiring!".
>
> This is perl6 version 2015.10-220-g4988c70 built on MoarVM version
> 2015.10-61-g624d504
>
> Mac OSX

[perl #114554] [BUG] Definition of zero-length postfix operator wrongly allowed in Rakudo

[Zoffix Znet via RT]

On Thu, 07 Apr 2016 10:31:20 -0700, diakopter wrote:
> new behavior:
> 
> 13:30  m: sub postfix:{}($a) { say "$a bracey brace" };
> 42{}
> 13:30  rakudo-moar 61d231: OUTPUT«===SORRY!===␤Internal
> error: find_var_decl could not find $_␤»


Couple more glitches in the same area:

14:59   Zoffix  m: my $z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «5===SORRY!5=== Error 
while compiling ␤You can't adverb $z␤at :1␤--> 3my 
$z:{:42foo}7⏏5␤»
14:59   Zoffix  m: my \z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «===SORRY!===␤Cannot 
find method 'ast' on object of type NQPMu␤»

[perl #114554] [BUG] Definition of zero-length postfix operator wrongly allowed in Rakudo

[Zoffix Znet via RT]

On Thu, 07 Apr 2016 10:31:20 -0700, diakopter wrote:
> new behavior:
> 
> 13:30  m: sub postfix:{}($a) { say "$a bracey brace" };
> 42{}
> 13:30  rakudo-moar 61d231: OUTPUT«===SORRY!===␤Internal
> error: find_var_decl could not find $_␤»


Couple more glitches in the same area:

14:59   Zoffix  m: my $z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «5===SORRY!5=== Error 
while compiling ␤You can't adverb $z␤at :1␤--> 3my 
$z:{:42foo}7⏏5␤»
14:59   Zoffix  m: my \z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «===SORRY!===␤Cannot 
find method 'ast' on object of type NQPMu␤»