From j.david.lowe@apple.com

On my system, this short program crashes within a few seconds of starting​:

```
#!/usr/bin/env perl6

use v6.c;

sub MAIN {
  await Promise.anyof((^2).map​: {
  start {
  loop {
  EVAL "True";
  }
  }
  });
}
```

The three failures I've observed are​:
1. Segmentation fault
2. *** glibc detected *** ... double free or corruption (fasttop) ...
3. MoarVM panic​: Internal error​: invalid thread ID ... in GC work pass

More information​:

$ perl6 --version
This is Rakudo version 2017.01 built on MoarVM version 2017.01
implementing Perl 6.c.

$ uname -a
Linux voot 3.8.13-16.2.1.el6uek.x86_64 #​1 SMP Thu Nov 7 17​:01​:44 PST 2013 x86_64 x86_64 x86_64 GNU/Linux

From @nwc10

Thanks for the bug report.

On Tue, Mar 07, 2017 at 05​:12​:34PM -0800, J . David Lowe wrote​:

```
#!/usr/bin/env perl6

use v6.c;

sub MAIN {
await Promise.anyof((^2).map​: {
start {
loop {
EVAL "True";
}
}
});
}
```

2. *** glibc detected *** ... double free or corruption (fasttop) ...

ASAN says​:

==8139==ERROR​: AddressSanitizer​: attempting double-free on 0x6020008ef610 in thread T1​:
  #​0 0x7f93cc31d8e6 in __interceptor_realloc ../../.././libsanitizer/asan/asan_malloc_linux.cc​:93
  #​1 0x7f93ca155fad in MVM_realloc src/core/alloc.h​:20
  #​2 0x7f93ca15dd71 in MVM_sc_set_object src/6model/sc.c​:230
  #​3 0x7f93c9ef1a16 in MVM_interp_run src/core/interp.c​:2948
  #​4 0x7f93c9f831bf in start_thread src/core/threads.c​:80
  #​5 0x7f93ca391e48 in uv__thread_start 3rdparty/libuv/src/unix/thread.c​:49
  #​6 0x7f93c8bdfaa0 in start_thread (/lib64/libpthread.so.0+0x7aa0)
  #​7 0x7f93c90e5aac in __clone (/lib64/libc.so.6+0xe8aac)

0x6020008ef610 is located 0 bytes inside of 16-byte region [0x6020008ef610,0x6020008ef620)
freed by thread T2 here​:
  #​0 0x7f93cc31d8e6 in __interceptor_realloc ../../.././libsanitizer/asan/asan_malloc_linux.cc​:93
  #​1 0x7f93ca155fad in MVM_realloc src/core/alloc.h​:20
  #​2 0x7f93ca15dd71 in MVM_sc_set_object src/6model/sc.c​:230
  #​3 0x7f93c9ef1a16 in MVM_interp_run src/core/interp.c​:2948
  #​4 0x7f93c9f831bf in start_thread src/core/threads.c​:80
  #​5 0x7f93ca391e48 in uv__thread_start 3rdparty/libuv/src/unix/thread.c​:49
  #​6 0x7f93c8bdfaa0 in start_thread (/lib64/libpthread.so.0+0x7aa0)

previously allocated by thread T1 here​:
  #​0 0x7f93cc31d8e6 in __interceptor_realloc ../../.././libsanitizer/asan/asan_malloc_linux.cc​:93
  #​1 0x7f93ca155fad in MVM_realloc src/core/alloc.h​:20
  #​2 0x7f93ca15dd71 in MVM_sc_set_object src/6model/sc.c​:230
  #​3 0x7f93c9ef1a16 in MVM_interp_run src/core/interp.c​:2948
  #​4 0x7f93c9f831bf in start_thread src/core/threads.c​:80
  #​5 0x7f93ca391e48 in uv__thread_start 3rdparty/libuv/src/unix/thread.c​:49
  #​6 0x7f93c8bdfaa0 in start_thread (/lib64/libpthread.so.0+0x7aa0)

Thread T1 created by T0 here​:
  #​0 0x7f93cc2ec6ea in __interceptor_pthread_create ../../.././libsanitizer/asan/asan_interceptors.cc​:183
  #​1 0x7f93ca391f7e in uv_thread_create 3rdparty/libuv/src/unix/thread.c​:66
  #​2 0x7f93c9f8374f in MVM_thread_run src/core/threads.c​:132
  #​3 0x7f93c9f12399 in MVM_interp_run src/core/interp.c​:4003
  #​4 0x7f93ca2e71c9 in MVM_vm_run_file src/moar.c​:310
  #​5 0x401cdb in main src/main.c​:201
  #​6 0x7f93c901bd1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c)

Thread T2 created by T0 here​:
  #​0 0x7f93cc2ec6ea in __interceptor_pthread_create ../../.././libsanitizer/asan/asan_interceptors.cc​:183
  #​1 0x7f93ca391f7e in uv_thread_create 3rdparty/libuv/src/unix/thread.c​:66
  #​2 0x7f93c9f8374f in MVM_thread_run src/core/threads.c​:132
  #​3 0x7f93c9f12399 in MVM_interp_run src/core/interp.c​:4003
  #​4 0x7f93ca2e71c9 in MVM_vm_run_file src/moar.c​:310
  #​5 0x401cdb in main src/main.c​:201
  #​6 0x7f93c901bd1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c)

SUMMARY​: AddressSanitizer​: double-free ../../.././libsanitizer/asan/asan_malloc_linux.cc​:93 __interceptor_realloc
==8139==ABORTING

Nicholas Clark

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

From @jnthn

On Wed, 08 Mar 2017 04​:00​:18 -0800, nicholas wrote​:

Thanks for the bug report.

On Tue, Mar 07, 2017 at 05​:12​:34PM -0800, J . David Lowe wrote​:

```
#!/usr/bin/env perl6

use v6.c;

sub MAIN {
await Promise.anyof((^2).map​: {
start {
loop {
EVAL "True";
}
}
});
}
```

2. *** glibc detected *** ... double free or corruption (fasttop) ...

ASAN says​:

==8139==ERROR​: AddressSanitizer​: attempting double-free on
0x6020008ef610 in thread T1​:
#​0 0x7f93cc31d8e6 in __interceptor_realloc
../../.././libsanitizer/asan/asan_malloc_linux.cc​:93
#​1 0x7f93ca155fad in MVM_realloc src/core/alloc.h​:20
#​2 0x7f93ca15dd71 in MVM_sc_set_object src/6model/sc.c​:230
#​3 0x7f93c9ef1a16 in MVM_interp_run src/core/interp.c​:2948
#​4 0x7f93c9f831bf in start_thread src/core/threads.c​:80
#​5 0x7f93ca391e48 in uv__thread_start
3rdparty/libuv/src/unix/thread.c​:49
#​6 0x7f93c8bdfaa0 in start_thread (/lib64/libpthread.so.0+0x7aa0)
#​7 0x7f93c90e5aac in __clone (/lib64/libc.so.6+0xe8aac)

0x6020008ef610 is located 0 bytes inside of 16-byte region
[0x6020008ef610,0x6020008ef620)
freed by thread T2 here​:
#​0 0x7f93cc31d8e6 in __interceptor_realloc
../../.././libsanitizer/asan/asan_malloc_linux.cc​:93
#​1 0x7f93ca155fad in MVM_realloc src/core/alloc.h​:20
#​2 0x7f93ca15dd71 in MVM_sc_set_object src/6model/sc.c​:230
#​3 0x7f93c9ef1a16 in MVM_interp_run src/core/interp.c​:2948
#​4 0x7f93c9f831bf in start_thread src/core/threads.c​:80
#​5 0x7f93ca391e48 in uv__thread_start
3rdparty/libuv/src/unix/thread.c​:49
#​6 0x7f93c8bdfaa0 in start_thread (/lib64/libpthread.so.0+0x7aa0)

previously allocated by thread T1 here​:
#​0 0x7f93cc31d8e6 in __interceptor_realloc
../../.././libsanitizer/asan/asan_malloc_linux.cc​:93
#​1 0x7f93ca155fad in MVM_realloc src/core/alloc.h​:20
#​2 0x7f93ca15dd71 in MVM_sc_set_object src/6model/sc.c​:230
#​3 0x7f93c9ef1a16 in MVM_interp_run src/core/interp.c​:2948
#​4 0x7f93c9f831bf in start_thread src/core/threads.c​:80
#​5 0x7f93ca391e48 in uv__thread_start
3rdparty/libuv/src/unix/thread.c​:49
#​6 0x7f93c8bdfaa0 in start_thread (/lib64/libpthread.so.0+0x7aa0)

Thread T1 created by T0 here​:
#​0 0x7f93cc2ec6ea in __interceptor_pthread_create
../../.././libsanitizer/asan/asan_interceptors.cc​:183
#​1 0x7f93ca391f7e in uv_thread_create
3rdparty/libuv/src/unix/thread.c​:66
#​2 0x7f93c9f8374f in MVM_thread_run src/core/threads.c​:132
#​3 0x7f93c9f12399 in MVM_interp_run src/core/interp.c​:4003
#​4 0x7f93ca2e71c9 in MVM_vm_run_file src/moar.c​:310
#​5 0x401cdb in main src/main.c​:201
#​6 0x7f93c901bd1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c)

Thread T2 created by T0 here​:
#​0 0x7f93cc2ec6ea in __interceptor_pthread_create
../../.././libsanitizer/asan/asan_interceptors.cc​:183
#​1 0x7f93ca391f7e in uv_thread_create
3rdparty/libuv/src/unix/thread.c​:66
#​2 0x7f93c9f8374f in MVM_thread_run src/core/threads.c​:132
#​3 0x7f93c9f12399 in MVM_interp_run src/core/interp.c​:4003
#​4 0x7f93ca2e71c9 in MVM_vm_run_file src/moar.c​:310
#​5 0x401cdb in main src/main.c​:201
#​6 0x7f93c901bd1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c)

SUMMARY​: AddressSanitizer​: double-free
../../.././libsanitizer/asan/asan_malloc_linux.cc​:93
__interceptor_realloc
==8139==ABORTING

Turned out to be a data race in producing (supposedly unique) serialization context IDs, meaning that some of the compilations were doomed to share state that should not be shared. Fixed the race, and added a test case in integration/eval-and-threads.t based on the code in this ticket.

Thanks,

/jnthn

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