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

[via Digitalmars-d-bugs]

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

--- Comment #24 from Aleksei Preobrazhenskii  ---
(In reply to Martin Nowak from comment #23)
> Anyone still experiencing this issue? Can't seem to fix it w/o reproducing
> it.

Since I changed signals to real-time and migrated to recent kernel I haven't
seen that issue in the release builds, however, I tried running profile build
recently (unfortunately I only did it for the old kernel) and it was
consistently stuck every time. It might be something related to the issue, I
will try to reproduce it with simpler code when I have time.

--

[Issue 16526] @safe code should do null check for members when appropriate

[via Digitalmars-d-bugs]

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

--- Comment #3 from Steven Schveighoffer  ---
(In reply to Sobirari Muhomori from comment #1)
> struct S
> {
>   byte[3000] a,b;
> }
> void f(ref S s)
> {
>   g(s.b);
> }

Actually, technically this could trigger a check of s address, since b's data
is beyond the 1 page boundary.

--

[Issue 16526] @safe code should do null check for members when appropriate

[via Digitalmars-d-bugs]

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

--- Comment #2 from Steven Schveighoffer  ---
Yes, this is what I meant by "There are still ways to access data beyond one
page without incurring a check with this scheme, but we are talking about very
weird and rare code."

--

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[via Digitalmars-d-bugs]

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

--- Comment #22 from Andrei Alexandrescu  ---
(In reply to Martin Nowak from comment #21)
> Forcing everyone to use the same attributes is too limiting/breaks code,
> let's replace the old C API w/ templated library code.

Bestimmt!!!

--

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[via Digitalmars-d-bugs]

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

--- Comment #21 from Martin Nowak  ---
(In reply to Andrei Alexandrescu from comment #19)
> > Just look at core.sync, none of the methods can be implemented const or
> > pure, still they get called from const/pure code.
> 
> That's not a problem, the runtime is expected to contain nonportable code.

I'd say the real attribute problem is not the automatic mutex generated for
`synchronized (instance)`, b/c we can control how that behaves. But b/c it's
possible to assign an arbitrary Object.Monitor implementation, people can run
very different Mutex implementations.
As usual there is no deprecation path for adding attributes to an
interface/base-class, and the last time we tried to make Object.Monitor
nothrow, we broke valid use cases in vibe.d that we're using async/event-based
mutexes.

Now this bug report is about the effect that _d_monitorenter/exit do call any
Mutex implementation w/o checking for attributes.
We had so many problems w/ attributes and old C compiler-runtime APIs, and it
always boils down to this:

Forcing everyone to use the same attributes is too limiting/breaks code, let's
replace the old C API w/ templated library code.

--

[Issue 16526] @safe code should do null check for members when appropriate

[via Digitalmars-d-bugs]

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

Sobirari Muhomori  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Mac OS X|All

--- Comment #1 from Sobirari Muhomori  ---
struct S
{
byte[3000] a,b;
}
void f(ref S s)
{
g(s.b);
}
void g(ref byte[3000] b)
{
b[2000]=0;
}

Similar with slicing:
void f(ref byte[6000] a)
{
g(a[0..3000]);
}
void g(ref byte[3000] b)
{
b[2000]=0;
}

--

[Issue 16499] Misleading error message for 'in' operator with wrong argument

[via Digitalmars-d-bugs]

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

Sobirari Muhomori  changed:

   What|Removed |Added

   Keywords||diagnostic
   Hardware|x86_64  |All
Summary|Useless error message for   |Misleading error message
   |'in' expressions|for 'in' operator with
   ||wrong argument
 OS|Linux   |All
   Severity|enhancement |normal

--

[Issue 16405] Trojan Win32/Ipac.B!cl detected on dmd-2.071.1.exe

[via Digitalmars-d-bugs]

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

--- Comment #7 from Sobirari Muhomori  ---
I uploaded only ddemangle.exe

--

[Issue 16526] New: @safe code should do null check for members when appropriate

[via Digitalmars-d-bugs]

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

  Issue ID: 16526
   Summary: @safe code should do null check for members when
appropriate
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Keywords: safe
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

If I have a struct like this:

struct S
{
  int[10_000] data
}

I can access memory I'm not supposed to, even in @safe code, that is beyond the
zero page:

void main() @safe
{
   S * ptr;
   ptr.data[] = 5;
}

This data could be unmapped or mapped (on my 64-bit system, it's not mapped, so
a segfault still occurs). But it is a possible way to have an exploit in @safe
code.

I propose that if the compiler can detect at compile-time that access to a
member of a struct is beyond the zero page if a pointer happens to point at
null, then it should check for a null pointer (actually, it should just
dereference the first word pointed at by the pointer, and trigger a segfault).
It only needs to do this once if it can determine the pointer or reference will
not change.

If the access to the member is determined at compile-time to point within one
page of the front of the struct pointer (either by knowing at compile time the
index being accessed, or knowing that the struct is less than one page in
size), then no instrumentation is needed.

If the access cannot be determined to be within one page at compile-time, then
the check should still be made during runtime.

If one takes a reference to a member that is outside the one-page limit, then
the same check can be performed. There are still ways to access data beyond one
page without incurring a check with this scheme, but we are talking about very
weird and rare code.

This scheme should leave most code intact, and in rare cases, add a few null
checks here and there. Note that by null check, you aren't actually checking
against null, but simply using the built-in ability to segfault. So it's cheap.

--

[Issue 16342] std.algorithm.fill can't fill a char[]?

[via Digitalmars-d-bugs]

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

niklas.vo...@gmail.com changed:

   What|Removed |Added

 CC||niklas.vo...@gmail.com

--- Comment #2 from niklas.vo...@gmail.com ---
Was bitten by this issue today. Can we at least improve the error message?

--

[Issue 16525] New: C++ member variables have no mangling

[via Digitalmars-d-bugs]

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

  Issue ID: 16525
   Summary: C++ member variables have no mangling
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Keywords: ice
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
static immutable templ(alias var) = 1234;

struct D
{
int memvar;
}

extern(C++) struct CPP
{
int memvar;
}

void test()
{
pragma(msg, templ!(D.memvar));
pragma(msg, templ!(CPP.memvar));
pragma(msg, CPP.memvar.mangleof); // root cause
}
CODE

dmd -c bug

bug.d(10): Error: variable bug.CPP.memvar Internal Compiler Error: C++ static
non- __gshared non-extern variables not supported


Not sure if C++ defines a member variable mangling, but we need it at a couple
of places and it's blocking issue 16513.

--

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

[via Digitalmars-d-bugs]

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

--- Comment #23 from Martin Nowak  ---
Anyone still experiencing this issue? Can't seem to fix it w/o reproducing it.

--