[Issue 13698] ICE(e2ir.c) on on simd call

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
 OS|Windows |All

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/5685

--

[Issue 15939] GC.collect causes deadlock in multi-threaded environment

[via Digitalmars-d-bugs]

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

--- Comment #1 from Aleksei Preobrazhenskii  ---
I wasn't able to reproduce the issue using simpler code using GC operations
only. I noticed that nanosleep is a syscall which should be interrupted by GC
signal. So, probably there is something else involved aside from GC. I use
standard library only and I have no custom signal-related code.

--

[Issue 15939] New: GC.collect causes deadlock in multi-threaded environment

[via Digitalmars-d-bugs]

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

  Issue ID: 15939
   Summary: GC.collect causes deadlock in multi-threaded
environment
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: blocker
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: apreobrazhen...@gmail.com

I have multi-threaded application with threads doing memory intensive work and
main thread cleaning up the garbage periodically by calling GC.collect
manually. Sometimes GC.collect causes deadlock. I don't have simple example,
but I do have stack traces of the threads at the moment of the deadlock.

It happens both for dmd 2.071.0 and for dmd 2.070.* (so it is not related to
the recent GC spinlock change).

That seems like a blocker to me, I suspect that if it happens when I call it
manually it could also happen during normal collections. I'm not familiar with
runtime code, but I would expect some sort of race condition judging from stack
traces below.


Configuration:

dmd 2.071.0 with -O -release -inline -boundscheck=off
Linux 3.2.0-95-generic #135-Ubuntu SMP Tue Nov 10 13:33:29 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux


That's the main thread's stack trace.

Thread 1 (Thread 0x7ff6653bb6c0 (LWP 6857)):
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
#1  0x007b3ff6 in thread_suspendAll ()
#2  0x0079980d in gc.gc.Gcx.fullcollect() ()
#3  0x0079c2b2 in
gc.gc.GC.__T9runLockedS49_D2gc2gc2GC11fullCollectMFNbZ2goFNbPS2gc2gc3GcxZmTPS2gc2gc3GcxZ.runLocked()
()
#4  0x00796535 in gc.gc.GC.fullCollect() ()
#5  0x0076091c in gc_collect ()
...application stack


That's how stack trace looks like for the threads which were suspended
correctly.

Thread XX (Thread 0x7ff5c6ffd700 (LWP 6897)):
#0  0x7ff6640e6454 in do_sigsuspend (set=0x7ff5c6ff9bc0) at
../sysdeps/unix/sysv/linux/sigsuspend.c:63
#1  __GI___sigsuspend (set=) at
../sysdeps/unix/sysv/linux/sigsuspend.c:78
#2  0x007c0401 in core.thread.thread_suspendHandler() ()
#3  0x007c045c in core.thread.callWithStackShell() ()
#4  0x007c038f in thread_suspendHandler ()
#5  
... application stack


That's how stack trace looks like for the threads which weren't suspended:

Thread YY (Thread 0x7ff5c67fc700 (LWP 6898)):
#0  0x7ff664d9b52d in nanosleep () at ../sysdeps/unix/syscall-template.S:82
#1  0x0075dfde in core.thread.Thread.sleep() ()
#2  0x007b46e0 in core.internal.spinlock.SpinLock.yield() ()
#3  0x007b467c in core.internal.spinlock.SpinLock.lock() ()
#4  0x0079bc21 in
gc.gc.GC.__T9runLockedS46_D2gc2gc2GC12extendNoSyncMFNbPvmmxC8TypeInfoZmS21_D2gc2gc10extendTimelS21_D2gc2gc10numExtendslTPvTmTmTxC8TypeInfoZ.runLocked()
()
#5  0x00760bcc in gc_extend ()
#6  0x00763c85 in _d_arraysetlengthT ()
... application stack

Thread ZZ (Thread 0x7ff566ffd700 (LWP 6918)):
#0  0x7ff664d9b52d in nanosleep () at ../sysdeps/unix/syscall-template.S:82
#1  0x0075dfde in core.thread.Thread.sleep() ()
#2  0x007b46e0 in core.internal.spinlock.SpinLock.yield() ()
#3  0x007b467c in core.internal.spinlock.SpinLock.lock() ()
#4  0x0079ba3c in
gc.gc.GC.__T9runLockedS47_D2gc2gc2GC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS21_D2gc2gc10mallocTimelS21_D2gc2gc10numMallocslTmTkTmTxC8TypeInfoZ.runLocked()
()
#5  0x007953be in gc.gc.GC.malloc() ()
#6  0x00760a04 in gc_malloc ()
#7  0x00762c43 in _d_newclass ()
... application stack

--

[Issue 15917] std.concurrency module destructor causes useless creation of new MessageBox

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/9d575fa33970da793a07cd7ebcccb4d1c13735fa
Fix issue 15917 - std.concurrency module destructor causes useless creation of
new MessageBox

https://github.com/dlang/phobos/commit/4f18045c7fa965be50dd0db8f0ec6531df7f63db
Merge pull request #4191 from yazd/fix-15917

Fix issue 15917 - std.concurrency module destructor causes useless cr…

--

[Issue 15919] [ndslice] Undetected spell miss in selection.reshape()

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |FIXED

--- Comment #3 from Steven Schveighoffer  ---
Not sure why this didn't auto-close.

--

[Issue 15938] ctor doesn't initialize fields when struct is static immutable

[via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m

--- Comment #1 from Mathias Lang  ---
Might be related to https://issues.dlang.org/show_bug.cgi?id=15607#c5

--

[Issue 15938] New: ctor doesn't initialize fields when struct is static immutable

[via Digitalmars-d-bugs]

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

  Issue ID: 15938
   Summary: ctor doesn't initialize fields when struct is static
immutable
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

struct S {
static foo() { int[1][1] res = 1; return res; }

union {
int[1][1] A = foo;
int[1] flat;
}

this(A...)(auto ref in A args) {
uint k;

foreach(v; args)
flat[k++] = v;
}
}

static immutable s = S(2);

void main() {
assert(s.flat[0] == 2); // fails
assert(S(2).flat[0] == 2);
}

--

[Issue 15926] Peculiar behavior of 'inout'

[via Digitalmars-d-bugs]

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

--- Comment #3 from Sobirari Muhomori  ---
https://github.com/dlang/phobos/pull/3520 - somewhat related pull to improve
concept checks.

--

[Issue 14137] std.socket.getAddressInfo breaks @safety

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/c35d4aa26efd0907ccb48d7406dffc50f470971c
Fix issue 14137: std.socket.getAddressInfo breaks @safe

Remove abuse of @trusted in template function getAddressInfo that cannot
guarantee that the incoming type argument is @safe. Localize @trusted
block of the function to the single call to getAddressInfoImpl(), so
that any @system code in T will be caught by the type system.

Add unittest to ensure such examples of T will be rejected at
compile-time.

Mark normal unittest for getAddressInfo as @safe to ensure that the
function body itself does not introduce any non-@safe code.

https://github.com/dlang/phobos/commit/8a3453129f57a9db19c15026d184fc4e9da18ac3
Merge pull request #4009 from quickfur/issue14137

Fix issue 14137: std.socket.getAddressInfo breaks @safe

--

[Issue 15549] [ndslice] byElement is broken for packed slices

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--

[Issue 14511] Profiler does not work with multithreaded programs

[via Digitalmars-d-bugs]

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

jj75...@gmail.com changed:

   What|Removed |Added

   Severity|normal  |major

--

[Issue 14511] Profiler does not work with multithreaded programs

[via Digitalmars-d-bugs]

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

jj75...@gmail.com changed:

   What|Removed |Added

 CC||jj75...@gmail.com

--- Comment #5 from jj75...@gmail.com ---
Profiler fails with atomic operations:

import core.atomic;

shared struct S
{
uint counter;

bool inc() shared
{
atomicOp!("+=")(counter, 1);
return true;
}
}

int main(string[] argv)
{
S s;

return 0;
}

This program segfaults if compiled with profiler hooks

--