CounterMutexSingleton sample crashes

[p6rt]

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

Searchable as RT123434$

[p6rt]

From ryan@bastic.net

Hi,

please see github.com/rbastic/CounterMutexSingleton

This code crashes consistently on the latest MoarVM on Mac OS X 10.9.5

It does not crash with the JVM.

ab5tract has also helped to work on this and reproduce it FWIW. We can
probably provide more details if needed.

[p6rt]

From @coke

On Mon Dec 15 03​:50​:26 2014, ryan@​bastic.net wrote​:

Hi,

please see github.com/rbastic/CounterMutexSingleton

This code crashes consistently on the latest MoarVM on Mac OS X 10.9.5

It does not crash with the JVM.

ab5tract has also helped to work on this and reproduce it FWIW. We can
probably provide more details if needed.

What kind of crash? Please attach the test script here, along with the expected results, and the actual results.

It would be nice if you could reduce the amount of code from 87 lines, but I understand this isn't always possible.

--
Will "Coke" Coleda

[p6rt]

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

[p6rt]

From @coke

On Fri Oct 30 06​:54​:00 2015, coke wrote​:

On Mon Dec 15 03​:50​:26 2014, ryan@​bastic.net wrote​:

Hi,

please see github.com/rbastic/CounterMutexSingleton

This code crashes consistently on the latest MoarVM on Mac OS X
10.9.5

It does not crash with the JVM.

ab5tract has also helped to work on this and reproduce it FWIW. We
can
probably provide more details if needed.

What kind of crash? Please attach the test script here, along with the
expected results, and the actual results.

It would be nice if you could reduce the amount of code from 87 lines,
but I understand this isn't always possible.

Verified, segfault​:

$ git clone https://github.com/rbastic/CounterMutexSingleton
...
$ perl6 -v
This is Rakudo version 2016.07.1 built on MoarVM version 2016.07
implementing Perl 6.c.
$ perl6 CounterMutexSingleton.pl6
Segmentation fault​: 11

--
Will "Coke" Coleda

[p6rt]

From ryan@bastic.net

Hi,

I'm pretty sure this is related to not mutexing / synchronizing around
shared resource usage of STDOUT, etc.

In talking with Jonathan before, this seemed to be a likely cause. Adding
synchronization primitives around the mutexed usage of the print() command
fixed it previously, if memory served.

On Wed, Jul 27, 2016 at 11​:15 AM, Will Coleda via RT <
perl6-bugs-followup@​perl.org> wrote​:

On Fri Oct 30 06​:54​:00 2015, coke wrote​:

On Mon Dec 15 03​:50​:26 2014, ryan@​bastic.net wrote​:

Hi,

please see github.com/rbastic/CounterMutexSingleton

This code crashes consistently on the latest MoarVM on Mac OS X
10.9.5

It does not crash with the JVM.

ab5tract has also helped to work on this and reproduce it FWIW. We
can
probably provide more details if needed.

What kind of crash? Please attach the test script here, along with the
expected results, and the actual results.

It would be nice if you could reduce the amount of code from 87 lines,
but I understand this isn't always possible.

Verified, segfault​:

$ git clone https://github.com/rbastic/CounterMutexSingleton
...
$ perl6 -v
This is Rakudo version 2016.07.1 built on MoarVM version 2016.07
implementing Perl 6.c.
$ perl6 CounterMutexSingleton.pl6
Segmentation fault​: 11

--
Will "Coke" Coleda

[p6rt]

From @timo

Hi,

we've put in an improved error message for when libuv refuses to create an eventloop for us (for example because you've surpassed your allowance of file descriptors).

Instead of segfaulting when accessing the NULL it returned instead of the eventloop, we'll throw an exception for you.

With the very latest moarvm, behaviour is now this​:

  timo@​schmand /tmp> perl6 CounterMutexSingleton.pl6 --num_threads=252
  252
  timo@​schmand /tmp> perl6 CounterMutexSingleton.pl6 --num_threads=253
  Could not create a new Thread.
  in sub MAIN at CounterMutexSingleton.pl6 line 76
  in block <unit> at CounterMutexSingleton.pl6 line 71

Setting the default num_threads to 100000 is ... quite optimistic to say the least :)

[p6rt]

From @timo

Now the exception also contains the error as reported by libuv​:

  timo@​schmand /tmp> perl6 CounterMutexSingleton.pl6 --num_threads=253
  Could not create a new Thread​: too many open files
  in sub MAIN at CounterMutexSingleton.pl6 line 76
  in block <unit> at CounterMutexSingleton.pl6 line 71

I think this bug can now be closed; any other problems with this code should be reported in a different ticket, IMO, because i'd like to make this the ticket for "segfault when too many threads are created".

Cheers!

[p6rt]

From ryan@bastic.net

Sounds good! Thanks.

On Thu, Feb 23, 2017 at 12​:21 PM, Timo Paulssen via RT <
perl6-bugs-followup@​perl.org> wrote​:

Now the exception also contains the error as reported by libuv​:

timo@​schmand /tmp> perl6 CounterMutexSingleton\.pl6 \-\-num\_threads=253
Could not create a new Thread​: too many open files
  in sub MAIN at CounterMutexSingleton\.pl6 line 76
  in block \<unit> at CounterMutexSingleton\.pl6 line 71

I think this bug can now be closed; any other problems with this code
should be reported in a different ticket, IMO, because i'd like to make
this the ticket for "segfault when too many threads are created".

Cheers!

[p6rt]

From ryan@bastic.net

Indeed :) It was just a simple test case to demonstrate some things to
ab5tract.

Thanks for your work!

On Thu, Feb 23, 2017 at 11​:53 AM, Timo Paulssen via RT <
perl6-bugs-followup@​perl.org> wrote​:

Hi,

we've put in an improved error message for when libuv refuses to create an
eventloop for us (for example because you've surpassed your allowance of
file descriptors).

Instead of segfaulting when accessing the NULL it returned instead of the
eventloop, we'll throw an exception for you.

With the very latest moarvm, behaviour is now this​:

timo@​schmand /tmp> perl6 CounterMutexSingleton\.pl6 \-\-num\_threads=252
252
timo@​schmand /tmp> perl6 CounterMutexSingleton\.pl6 \-\-num\_threads=253
Could not create a new Thread\.
  in sub MAIN at CounterMutexSingleton\.pl6 line 76
  in block \<unit> at CounterMutexSingleton\.pl6 line 71

Setting the default num_threads to 100000 is ... quite optimistic to say
the least :)

[p6rt]

From @dogbert17

On Thu, 23 Feb 2017 09​:01​:40 -0800, ryan@​bastic.net wrote​:

Indeed :) It was just a simple test case to demonstrate some things to
ab5tract.

Thanks for your work!

On Thu, Feb 23, 2017 at 11​:53 AM, Timo Paulssen via RT <
perl6-bugs-followup@​perl.org> wrote​:

Hi,

we've put in an improved error message for when libuv refuses to create an
eventloop for us (for example because you've surpassed your allowance of
file descriptors).

Instead of segfaulting when accessing the NULL it returned instead of the
eventloop, we'll throw an exception for you.

With the very latest moarvm, behaviour is now this​:

timo@​schmand /tmp> perl6 CounterMutexSingleton\.pl6 \-\-num\_threads=252
252
timo@​schmand /tmp> perl6 CounterMutexSingleton\.pl6 \-\-num\_threads=253
Could not create a new Thread\.
  in sub MAIN at CounterMutexSingleton\.pl6 line 76
  in block \<unit> at CounterMutexSingleton\.pl6 line 71

Setting the default num_threads to 100000 is ... quite optimistic to say
the least :)

Closing issue, better late than never.

[p6rt]

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