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
Pushing into the same array from two threads segfaults reliably #5546
Comments
From @AlexDanielWhile it is probably a bad idea to push values into the same array from two threads, if I recall correctly rakudo is supposed to not crash like that no matter what. Code: Result: |
From @nwc10On Mon, Aug 08, 2016 at 12:25:52AM -0700, Aleks-Daniel Jakimenko-Aleksejev wrote:
Thanks for the report. Yes, I also don't think that it should crash at a VM ASAN seems to be pretty consistent: $ ./perl6-m -Ilib -e 'my @a; start loop { @a.push: rand }; start loop { @a.push: rand }; sleep 1'==25229==ERROR: AddressSanitizer: attempting double-free on 0x60c000173740 in thread T1: 0x60c000173740 is located 0 bytes inside of 128-byte region [0x60c000173740,0x60c0001737c0) previously allocated by thread T1 here: Thread T1 created by T0 here: Thread T2 created by T0 here: SUMMARY: AddressSanitizer: double-free ../../.././libsanitizer/asan/asan_malloc_linux.cc:93 __interceptor_realloc Nicholas Clark |
The RT System itself - Status changed from 'new' to 'open' |
From @lizmatAs far as I understand Jonathan’s position on this, is that you shouldn’t do that. If you want to push to an array from multiple threads, you probably should use a Channel, or use Supplies with an .act block. As to the security implications of this behaviour, I must admit I haven’t thought about that in this context myself yet. In any case, having any array automatically work correctly when being pushed to from multiple threads, is a ticket to deadlock hell (if I remember Jonathan’s wording on this subject correctly). Liz
|
From @jnthnOn Mon Aug 08 04:09:13 2016, elizabeth wrote:
Well, you shouldn't do it without concurrency control if you want correct results. But SEGV isn't an OK failure mode. So it wants addressing up to that point (and I know how to do it, just didn't get to it yet).
Or re-think your problem in a less imperative way. :-)
Well, I had many words, but the other notable issue is that it gives a false sense of security (even if array operations were to be individually safe, auto-viv would still a race, as would `while @foo { @foo.pop }`) and just leads people towards high-contention designs when a different framing of the problem would give a lower-contention design. /jnthn |
Migrated from rt.perl.org#128870 (status was 'open')
Searchable as RT128870$
The text was updated successfully, but these errors were encountered: