[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #14 from github-bugzi...@puremagic.com ---
Commits pushed to newCTFE at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/5caa66ef31e40725c5548d40ead7dbefd19a0d79
Fix issue 16352 - dead-lock in std.allocator.free_list unittest

https://github.com/dlang/phobos/commit/05e9cba20e2455cb94b5d70a0d6e873bf45cec14
Merge pull request #4988 from WalterWaldron/fix16352

https://github.com/dlang/phobos/commit/f7e14e905b9d668ac788024f3c03c600adf0d84f
Fix issue 16352 - dead-lock in std.allocator.free_list unittest

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #13 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/5caa66ef31e40725c5548d40ead7dbefd19a0d79
Fix issue 16352 - dead-lock in std.allocator.free_list unittest

https://github.com/dlang/phobos/commit/05e9cba20e2455cb94b5d70a0d6e873bf45cec14
Merge pull request #4988 from WalterWaldron/fix16352

https://github.com/dlang/phobos/commit/f7e14e905b9d668ac788024f3c03c600adf0d84f
Fix issue 16352 - dead-lock in std.allocator.free_list unittest

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #12 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/f7e14e905b9d668ac788024f3c03c600adf0d84f
Fix issue 16352 - dead-lock in std.allocator.free_list unittest

This fixes the actual unittest.

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #11 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/5caa66ef31e40725c5548d40ead7dbefd19a0d79
Fix issue 16352 - dead-lock in std.allocator.free_list unittest

https://github.com/dlang/phobos/commit/05e9cba20e2455cb94b5d70a0d6e873bf45cec14
Merge pull request #4988 from WalterWaldron/fix16352

Fix issue 16352 - dead-lock in std.allocator.free_list unittest

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #10 from safety0ff.bugz  ---
(In reply to safety0ff.bugz from comment #9)
> 
> I'm just going to slap core.internal.spinlock on it for now.

https://github.com/dlang/phobos/pull/4988

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #9 from safety0ff.bugz  ---
(In reply to Rainer Schuetze from comment #8)
> 
> I agree. The actual pattern to use depends on the hardware, but x86 usually
> uses a modification counter modified in lock step.

I'm just going to slap core.internal.spinlock on it for now.
Somebody else can improve it later.
I just don't want the autotester choking on unrelated changes.

There's also the issue on x86_64 that we can't use the upper bits (because
ParentAllocator could be GCAllocator,) and not all x86_64 machines have
cmpxchg16b.

AFAIK shared free lists aren't very good for high contention regardless.

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #8 from Rainer Schuetze  ---
> SharedFreeList.allocate looks ABA prone:

I agree. The actual pattern to use depends on the hardware, but x86 usually
uses a modification counter modified in lock step.

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #7 from safety0ff.bugz  ---
(In reply to safety0ff.bugz from comment #6)
> 
> But the value of `next` could have changed between the load and the cas.

I meant `oldRoot.next`. i.e. next != oldRoot.next after the cas succeeds.

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

safety0ff.bugz  changed:

   What|Removed |Added

 CC||safety0ff.b...@gmail.com

--- Comment #6 from safety0ff.bugz  ---
SharedFreeList.allocate looks ABA prone:

A thread does:
do
{
oldRoot = _root; // atomic load
if (!oldRoot) return allocateFresh(bytes);
next = oldRoot.next; // atomic load
}
while (!cas(&_root, oldRoot, next));

But the value of `next` could have changed between the load and the cas.

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com
   Assignee|nob...@puremagic.com|edi33...@gmail.com

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #5 from John Colvin  ---
It seems that all the threads exit but (in my tests) one message either is
never sent or is never received by the main thread, so it sits in
receiveOnly!bool

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #4 from John Colvin  ---
To reproduce on linux x86_64:

% ../dmd/src/dmd -conf= -I../druntime/import  -w -dip25 -m64  -O -release -main
-unittest generated/linux/release/64/libphobos2.a -defaultlib= -debuglib=
-L-ldl std/experimental/allocator/building_blocks/free_list.d
% seq 1 | xargs -Iz ./free_list

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #3 from John Colvin  ---
After a bunch of testing I've managed to reproduce this reliably, stop it,
attach gdb and get a backtrace.

The hang happens here:
https://github.com/dlang/phobos/blob/19445fc71e8aabdbd42f0ad8a571a57601a5ff39/std/experimental/allocator/building_blocks/free_list.d#L1025

In the backtrace you'll se
std.experimental.allocator.building_blocks.free_list.__unittestL1020_10, that's
just a consequence of some accidental reformatting before i tested, the real
line number is 1025 as in the link above

#0  0x667f4afa810f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x0042e8cd in core.sync.condition.Condition.wait() ()
#2  0x00414b80 in std.concurrency.MessageBox.get!(void(bool) pure
nothrow @nogc @safe delegate, void(std.concurrency.LinkTerminated) pure @nogc
@safe function, void(std.concurrency.OwnerTerminated) pure @nogc @safe
function, void(std.variant.VariantN!(32uL).VariantN) function).get(void(bool)
pure nothrow @nogc @safe delegate, void(std.concurrency.LinkTerminated) pure
@nogc @safe function, void(std.concurrency.OwnerTerminated) pure @nogc @safe
function, void(std.variant.VariantN!(32uL).VariantN) function) ()
#3  0x00414146 in std.concurrency.receiveOnly!(bool).receiveOnly() ()
#4  0x00402faa in
std.experimental.allocator.building_blocks.free_list.__unittestL1020_10() ()
#5  0x00419eba in
std.experimental.allocator.building_blocks.free_list.__modtest() ()
#6  0x0042c5a1 in
core.runtime.runModuleUnitTests().__foreachbody2(object.ModuleInfo*) ()
#7  0x0041bb6c in object.ModuleInfo.opApply(scope
int(object.ModuleInfo*) delegate).__lambda2(immutable(object.ModuleInfo*)) ()
#8  0x00421fb3 in rt.minfo.moduleinfos_apply(scope
int(immutable(object.ModuleInfo*)) delegate).__foreachbody2(ref
rt.sections_elf_shared.DSO) ()
#9  0x004221b5 in rt.sections_elf_shared.DSO.opApply(scope int(ref
rt.sections_elf_shared.DSO) delegate) ()
#10 0x00421f44 in rt.minfo.moduleinfos_apply(scope
int(immutable(object.ModuleInfo*)) delegate) ()
#11 0x0041bb48 in object.ModuleInfo.opApply(scope
int(object.ModuleInfo*) delegate) ()
#12 0x0042c493 in runModuleUnitTests ()
#13 0x0041eab3 in rt.dmain2._d_run_main(int, char**, extern(C)
int(char[][]) function).runAll() ()
#14 0x0041ea51 in rt.dmain2._d_run_main(int, char**, extern(C)
int(char[][]) function).tryExec(scope void() delegate) ()
#15 0x0041e9cb in _d_run_main ()
#16 0x00419ff6 in main ()
#17 0x667f4a4fa291 in __libc_start_main () from /usr/lib/libc.so.6
#18 0x0040280a in _start ()

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #2 from Martin Nowak  ---
They do, thanks. There is not much information in the log other than it did
hang at the commit hashes.

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
Created attachment 1606
  --> https://issues.dlang.org/attachment.cgi?id=1606=edit
Capture of log from failed test.

I'm pretty sure those logs go away. I've attached the log in any case.

--