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

CounterMutexSingleton sample crashes #3607

Closed
p6rt opened this issue Dec 15, 2014 · 11 comments
Closed

CounterMutexSingleton sample crashes #3607

p6rt opened this issue Dec 15, 2014 · 11 comments
Labels
SEGV Segmentation fault, bus error, etc.

Comments

@p6rt
Copy link

p6rt commented Dec 15, 2014

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

Searchable as RT123434$

@p6rt
Copy link
Author

p6rt commented Dec 15, 2014

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

p6rt commented Oct 30, 2015

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

p6rt commented Oct 30, 2015

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

@p6rt
Copy link
Author

p6rt commented Jul 27, 2016

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

p6rt commented Jul 28, 2016

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

p6rt commented Feb 23, 2017

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

p6rt commented Feb 23, 2017

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

p6rt commented Feb 23, 2017

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@&#8203;schmand /tmp> perl6 CounterMutexSingleton\.pl6 \-\-num\_threads=253
Could not create a new Thread&#8203;: 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
Copy link
Author

p6rt commented Feb 23, 2017

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@&#8203;schmand /tmp> perl6 CounterMutexSingleton\.pl6 \-\-num\_threads=252
252
timo@&#8203;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
Copy link
Author

p6rt commented Jul 9, 2017

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@&#8203;schmand /tmp> perl6 CounterMutexSingleton\.pl6 \-\-num\_threads=252
252
timo@&#8203;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
Copy link
Author

p6rt commented Jul 9, 2017

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

@p6rt p6rt closed this as completed Jul 9, 2017
@p6rt p6rt added the SEGV Segmentation fault, bus error, etc. label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
SEGV Segmentation fault, bus error, etc.
Projects
None yet
Development

No branches or pull requests

1 participant