[Issue 23980] New: OpenBSD: Add getthrname(2) and setthrname(2) to unistd.d
https://issues.dlang.org/show_bug.cgi?id=23980 Issue ID: 23980 Summary: OpenBSD: Add getthrname(2) and setthrname(2) to unistd.d Product: D Version: D2 Hardware: All OS: Other Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: bcal...@openbsd.org Add some new system functions that get and set the name of a thread. --
[Issue 23980] OpenBSD: Add getthrname(2) and setthrname(2) to unistd.d
https://issues.dlang.org/show_bug.cgi?id=23980 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ibara created dlang/dmd pull request #15301 "Fix Issue 23980 - OpenBSD: Add getthrname(2) and setthrname(2) to unistd.d" fixing this issue: - Fix Issue 23980 - OpenBSD: Add getthrname(2) and setthrname(2) to unistd.d https://github.com/dlang/dmd/pull/15301 --
[Issue 23966] [REG2.102] Cannot use traits(getAttributes) with overloaded template
https://issues.dlang.org/show_bug.cgi?id=23966 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #1 from Adam D. Ruppe --- this also affected me in the jsvar.d internals. i worked around by calling getOverloads again inside the getOverloads loop. foreach(idx, _ignored; __traits(getOverloads)) __traits(getAttributes, __traits(getOverloads)[idx]) that kind of thing. --
[Issue 23978] [REG 2.103.0] ICE: Segmentation fault in dmd.root.aav.dmd_aaGetRvalue at src/dmd/root/aav.d:127
https://issues.dlang.org/show_bug.cgi?id=23978
--- Comment #11 from Iain Buclaw ---
(In reply to Vladimir Panteleev from comment #7)
> I have not been able to reproduce this. It would be good to have a test case
> which more reliably reproduces the bug. I tried wrapping the code into a
> static foreach, but that did not help.
(In reply to Vladimir Panteleev from comment #8)
> Also because we need something to put in the test suite to prevent this from
> regressing again.
Can you drop this into compiler/test/compilable/test23978.d?
---
// REQUIRED_ARGS: -preview=dip1021 -lowmem
// PERMUTE_ARGS: -debug=A -debug=B -debug=C -debug=D -debug=E -debug=F -debug=G
-debug=H
class LUBench { }
void lup(ulong , ulong , int , int = 1)
{
new LUBench;
}
void lup_3200(ulong iters, ulong flops)
{
lup(iters, flops, 3200);
}
void raytrace()
{
struct V
{
float x, y, z;
auto normalize() { }
struct Tid { }
auto spawnLinked() { }
string[] namesByTid;
class MessageBox { }
auto cross() { }
}
}
---
The long list of permutations should make the test compile ~256 times. Enough
to ensure that it never succeeds on any of my dev machines.
--
[Issue 23979] ICE on failed alias this attempt on pointer expression
https://issues.dlang.org/show_bug.cgi?id=23979 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @dkorpel created dlang/dmd pull request #15300 "Fix 23979 - ICE on failed alias this attempt on pointer expression" fixing this issue: - Fix 23979 - ICE on failed alias this attempt on pointer expression https://github.com/dlang/dmd/pull/15300 --
[Issue 23979] ICE on failed alias this attempt on pointer expression
https://issues.dlang.org/show_bug.cgi?id=23979 Dennis changed: What|Removed |Added Summary|2.104 segfaults |ICE on failed alias this ||attempt on pointer ||expression Severity|major |regression --
[Issue 23978] [REG 2.103.0] ICE: Segmentation fault in dmd.root.aav.dmd_aaGetRvalue at src/dmd/root/aav.d:127
https://issues.dlang.org/show_bug.cgi?id=23978 --- Comment #10 from Iain Buclaw --- What the Mem.xmalloc/xrealloc calls are telling me is that the D front-end with `-lowmem` is reusing some memory that was previously allocated (and subsequently freed) for some other purpose. --- Despite non-determinism, some things are always constant: 1. The object that causes segfault is a ThisDeclaration 2. The AA struct always has 9 nodes, and a bucket size 32. 3. It's always array index 7 that has a value assigned seemingly from out of nowhere. --- Is it plausible that there might still be references within the AST to memory xrealloc'd or xfree'd by the front-end? I could at least believe that can happen. Why did it take the switch from function _d_newclass to template _d_newclassT to hit this? Still haven't a clue, but it is very clear that before `_d_newclassT`, it is impossible to hit this segfault. --
[Issue 23978] [REG 2.103.0] ICE: Segmentation fault in dmd.root.aav.dmd_aaGetRvalue at src/dmd/root/aav.d:127
https://issues.dlang.org/show_bug.cgi?id=23978
--- Comment #9 from Iain Buclaw ---
The printf dumps really don't give any hint as to what went wrong, but there is
at least a common pattern I see for each time it crashes.
-
Mem.xrealloc((nil), 624) = 0x7f3686b63000 <-- !!! This address ends up as aa.b
...
...
Mem.xrealloc(0x7f3686b63000, 832) = 0x7f3686b8d400 <-- !!! marked free
...
...
--
from: dmd_aaRehash++
this = 0x7f3686b95a20
nodes = 9
b_length = 4
[
b[0] 0x7f3686b95a38 = 0x7f3686b95a58 {
next = 0x7f3686b98c20
key = 0x7f3687f32fc0
value = 0x7f3687f2c500
}
b[1] 0x7f3686b95a40 = 0x7f3686b98bc0 {
next = (nil)
key = 0x7f3687f36060
value = 0x7f3687f37000
}
b[2] 0x7f3686b95a48 = 0x7f3686b98b80 {
next = 0x7f3686b98be0
key = 0x7f3687f32fe0
value = 0x7f3687f2c600
}
b[3] 0x7f3686b95a50 = 0x7f3686b98ba0 {
next = 0x7f3686b98c00
key = 0x7f3687f36000
value = 0x7f3687f2c700
}
]
Mem.xmalloc(768) = 0x7f3686b63000 <-- !!! rehash wants memory, reuse old
address
--
from: dmd_aaRehash--
this = 0x7f3686b95a20
nodes = 9
b_length = 32
[
b[0] 0x7f3686b63000 = (nil)
b[1] 0x7f3686b63008 = (nil)
b[2] 0x7f3686b63010 = (nil)
b[3] 0x7f3686b63018 = (nil)
b[4] 0x7f3686b63020 = (nil)
b[5] 0x7f3686b63028 = (nil)
b[6] 0x7f3686b63030 = (nil)
b[7] 0x7f3686b63038 = (nil) <-- !!! This index is null
b[8] 0x7f3686b63040 = (nil)
b[9] 0x7f3686b63048 = (nil)
b[10] 0x7f3686b63050 = (nil)
b[11] 0x7f3686b63058 = (nil)
b[12] 0x7f3686b63060 = (nil)
b[13] 0x7f3686b63068 = (nil)
b[14] 0x7f3686b63070 = (nil)
b[15] 0x7f3686b63078 = (nil)
b[16] 0x7f3686b63080 = (nil)
b[17] 0x7f3686b63088 = (nil)
b[18] 0x7f3686b63090 = (nil)
b[19] 0x7f3686b63098 = 0x7f3686b98ba0 {
next = (nil)
key = 0x7f3687f36000
value = 0x7f3687f2c700
}
b[20] 0x7f3686b630a0 = 0x7f3686b95a58 {
next = (nil)
key = 0x7f3687f32fc0
value = 0x7f3687f2c500
}
b[21] 0x7f3686b630a8 = 0x7f3686b98bc0 {
next = (nil)
key = 0x7f3687f36060
value = 0x7f3687f37000
}
b[22] 0x7f3686b630b0 = 0x7f3686b98b80 {
next = (nil)
key = 0x7f3687f32fe0
value = 0x7f3687f2c600
}
b[23] 0x7f3686b630b8 = 0x7f3686b98c00 {
next = (nil)
key = 0x7f3687f36040
value = 0x7f3687f37330
}
b[24] 0x7f3686b630c0 = 0x7f3686b98c20 {
next = (nil)
key = 0x7f3687f360a0
value = 0x7f3687f2c800
}
b[25] 0x7f3686b630c8 = (nil)
b[26] 0x7f3686b630d0 = 0x7f3686b98be0 {
next = (nil)
key = 0x7f3687f36080
value = 0x7f3687f34200
}
b[27] 0x7f3686b630d8 = (nil)
b[28] 0x7f3686b630e0 = 0x7f3686b98c60 {
next = (nil)
key = 0x7f3687f360e0
value = (nil)
}
b[29] 0x7f3686b630e8 = (nil)
b[30] 0x7f3686b630f0 = 0x7f3686b98c40 {
next = (nil)
key = 0x7f3687f360c0
value = 0x7f3687f37660
}
b[31] 0x7f3686b630f8 = (nil)
]
...
...
Mem.xmalloc(80) = 0x7f3686ba2b40
--
from: dmd_aaGet
this = 0x7f3686ba2b40
nodes = 0
--
from: dmd_aaGet==
this = 0x7f3686ba2b40
nodes = 1
b_length = 4
[
b[0] 0x7f3686ba2b58 = (nil)
b[1] 0x7f3686ba2b60 = 0x7f3686ba2b78 {
next = (nil)
key = 0x7f3687f285e0
value = (nil)
}
b[2] 0x7f3686ba2b68 = (nil)
b[3] 0x7f3686ba2b70 = (nil)
]
--
from: dmd_aaGet
this = 0x7f3686ba2b40
nodes = 1
b_length = 4
[
b[0] 0x7f3686ba2b58 = (nil)
b[1] 0x7f3686ba2b60 = 0x7f3686ba2b78 {
next = (nil)
key = 0x7f3687f285e0
value = 0x7f3686b9fb00 <-- !!! This is what corrupts aa.b[7]
}
b[2] 0x7f3686ba2b68 = (nil)
b[3] 0x7f3686ba2b70 = (nil)
]
...
...
--
from: dmd_aaGetRvalue
this = 0x7f3686ba2b40 <-- !!! Last access of this AA
nodes = 2
b_length = 4
[
b[0] 0x7f3686ba2b58 = (nil)
b[1] 0x7f3686ba2b60 = 0x7f3686ba2b78 {
next =
[Issue 23979] 2.104 segfaults
https://issues.dlang.org/show_bug.cgi?id=23979
--- Comment #2 from Dennis ---
Reduced to:
```D
class A {}
void h()
{
const auto classPtr = SPtr.init;
assert(!__traits(compiles, *classPtr));
}
struct SPtr
{
A ptr() { return A.init; }
alias ptr this;
}
```
--
[Issue 23979] 2.104 segfaults
https://issues.dlang.org/show_bug.cgi?id=23979 Dennis changed: What|Removed |Added CC||dkor...@live.nl --- Comment #1 from Dennis --- The segfaults happens in: ``` ExpressionSemanticVisitor::visit(PtrExp*) (this=0x7fff69d8, exp=0x7fffeb62d720) at src/dmd/expressionsem.d:7442 7442Type tb = exp.e1.type.toBasetype(); (gdb) bt #0 ExpressionSemanticVisitor::visit(PtrExp*) (this=0x7fff69d8, exp=0x7fffeb62d720) at src/dmd/expressionsem.d:7442 #1 0x559b66b6 in PtrExp::accept(Visitor*) (this=0x7fffeb62d720, v=0x7fff69d8) at src/dmd/expression.d:5481 ``` The PtrExp in question comes from this line: source/mud/memory/smartpointers.d:179 ``` assert(!__traits(compiles, *classPtr)); ``` I'm looking into reducing it --
[Issue 23979] New: 2.104 segfaults
https://issues.dlang.org/show_bug.cgi?id=23979 Issue ID: 23979 Summary: 2.104 segfaults Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: grimmapl...@gmail.com Since 2.104 rolled out, one of my dub packages started segfaulting. See results here: https://github.com/GrimMaple/mud/actions/runs/5203283642/jobs/9402955265 --
[Issue 23978] [REG 2.103.0] ICE: Segmentation fault in dmd.root.aav.dmd_aaGetRvalue at src/dmd/root/aav.d:127
https://issues.dlang.org/show_bug.cgi?id=23978 --- Comment #8 from Vladimir Panteleev --- Also because we need something to put in the test suite to prevent this from regressing again. --
