[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Dlang Bot  ---
dlang/dmd pull request #9658 "fix issue 18794 - Compiling with -O causes
runtime segfault" was merged into master:

- 067645189191f9739e7151f2b02275ab3ea65557 by aG0aep6G:
  fix issue 18794 - Compiling with -O causes runtime segfault

  Just adding a test. The issue has apparently been fixed by
  d80e14ba6037373f08c6dba274368408932d9e48.

https://github.com/dlang/dmd/pull/9658

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #6 from Dlang Bot  ---
@aG0aep6G created dlang/dmd pull request #9658 "fix issue 18794 - Compiling
with -O causes runtime segfault" fixing this issue:

- fix issue 18794 - Compiling with -O causes runtime segfault

  Just adding a test. The issue has apparently been fixed by
  d80e14ba6037373f08c6dba274368408932d9e48.

https://github.com/dlang/dmd/pull/9658

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from ag0aep6g  ---
(In reply to ag0aep6g from comment #1)
> bitIdx is a DWORD at rbp-0x10. But later a QWORD is read from there and used
> in the bt instruction. So that reads garbage from the stack. The garbage can
> be controlled by prep.
It's probably worth pointing out that the result is still wrong even when prep
zeroes the high bits. An int can't just be used as the low half of a long.

(In reply to hsteoh from comment #2)
> Just a side-note that although in my own environment, the problem can be
> reproduced with -O alone, apparently in some other environments specifying
> both -O and -profile is necessary to trigger the bug.
(In reply to Jonathan M Davis from comment #3)
> I can reproduce this on FreeBSD x86_64 with master, but I have to use
> -profile with -O. -O by itself doesn't trigger it for me.
You guys are talking about the original code, right? The behavior relies on
stack garbage, so it makes sense that it isn't reproducible everywhere. If you
happen to have zeroes at the particular stack address, you won't see a
segfault.

The modified code in comment #1 should segfault consistently with just -O (and
without -inline).

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from hst...@quickfur.ath.cx ---
Just tested in my environment, -inline does indeed make the problem go away.
(Mask it, probably.)

However, I can still reproduce the problem with just -O, even though the
original problem was discovered when I compiled with -O -profile. For
reference, I'm running dmd git commit b7f9af8766af90f221227946ba52f546e3188f9c.

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #3 from Jonathan M Davis  ---
I can reproduce this on FreeBSD x86_64 with master, but I have to use -profile
with -O. -O by itself doesn't trigger it for me. And adding -inline seems to
get rid of the problem.

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from hst...@quickfur.ath.cx ---
Just a side-note that although in my own environment, the problem can be
reproduced with -O alone, apparently in some other environments specifying both
-O and -profile is necessary to trigger the bug.

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com
 Blocks||18750

--- Comment #1 from ag0aep6g  ---
Reduced:


bool method(size_t* p)
{
int bitIdx = 0;
func();
return (*p & (1UL << bitIdx)) != 0;
}

void func() {}

void prep()
{
asm {}
ulong[2] x = -1;
}

void main()
{
prep();
size_t s;
method();
}


Generated code for `method`:


   0:   55  push   rbp
   1:   48 8b ecmovrbp,rsp
   4:   48 83 ec 10 subrsp,0x10
   8:   48 89 7d f8 movQWORD PTR [rbp-0x8],rdi
   c:   c7 45 f0 00 00 00 00movDWORD PTR [rbp-0x10],0x0
  13:   e8 00 00 00 00  call   18 <_D4test6methodFPmZb+0x18>
14: R_X86_64_PLT32  _D4test4funcFZv-0x4
  18:   48 8b 45 f8 movrax,QWORD PTR [rbp-0x8]
  1c:   48 8b 4d f0 movrcx,QWORD PTR [rbp-0x10]
  20:   48 0f a3 08 bt QWORD PTR [rax],rcx
  24:   48 0f 92 c0 rex.W setb al
  28:   48 8b e5movrsp,rbp
  2b:   5d  poprbp
  2c:   c3  ret


bitIdx is a DWORD at rbp-0x10. But later a QWORD is read from there and used in
the bt instruction. So that reads garbage from the stack. The garbage can be
controlled by prep.

Looks like this is directly related to the generation of the bt instruction,
which is horribly broken. But it doesn't seem to be a duplicate of the known
issues. Adding to the tracker.


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18750
[Issue 18750] [Tracker] everything wrong with code generation for bt
instruction
--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||wrong-code

--