digitalmars.D.bugs - [Issue 9449] New: Segmentation fault in main()
- d-bugmail puremagic.com (32/32) Feb 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (33/33) Feb 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (57/57) Feb 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (20/20) Feb 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (6/6) Feb 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (13/14) Feb 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (12/12) Feb 15 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (21/37) Apr 21 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (7/39) Apr 21 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (16/35) Apr 21 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (19/48) Apr 21 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (9/11) Apr 21 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (16/25) Apr 22 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
- d-bugmail puremagic.com (20/20) Oct 26 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9449
http://d.puremagic.com/issues/show_bug.cgi?id=9449
Summary: Segmentation fault in main()
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nobody puremagic.com
ReportedBy: tbanelwebmin free.fr
This small code crashs.
----------------------------------
import core.simd;
void main()
{
ubyte16 table[1];
}
----------------------------------
It crashes in:
void[] *_memset128ii(void[] *p, void[] value, size_t count);
It seems that a wrong "count" is passed in by the _Dmain() function.
Details:
DMD64 D Compiler v2.061
Linux Ubuntu
x86_64
AMD Phenom II
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 04 2013
d-bugmail puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=9449
hsteoh quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hsteoh quickfur.ath.cx
Something is very screwy with the executable that DMD produces for this code.
For example:
$ cat test.d
import core.simd;
void main() {
ubyte16 table[1];
}
$ dmd -L--export-dynamic -g -m64 test.d
$ gdb test
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/test...done.
(gdb) break Dmain
Segmentation fault
$
Commenting out the ubyte16 line makes the problem go away (it will correctly
set the breakpoint). Looks like the codegen is screwed up somewhere?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449
hsteoh quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|druntime |DMD
Actually, this looks like a compiler bug. The ubyte16 alias translates to
__vector(ubyte[16]), which is a compiler built-in magic type.
Here's the disassembly of Dmain:
0000000000418620 <_Dmain>:
418620: 55 push %rbp
418621: 48 8b ec mov %rsp,%rbp
418624: 48 83 ec 10 sub $0x10,%rsp
418628: 48 be 01 00 00 00 00 movabs $0x1,%rsi
41862f: 00 00 00
42fe20 <_IO_stdin_used+0x10>
418639: 00
41863a: 48 8d 7d f0 lea -0x10(%rbp),%rdi
41863e: e8 a9 07 00 00 callq 418dec <_memset128ii>
418643: 31 c0 xor %eax,%eax
418645: c9 leaveq
418646: c3 retq
Here's the disassembly of _memset128ii:
0000000000418dec <_memset128ii>:
418dec: 55 push %rbp
418ded: 48 8b ec mov %rsp,%rbp
418df0: 48 83 ec 20 sub $0x20,%rsp
418df4: 48 89 75 e8 mov %rsi,-0x18(%rbp)
418df8: 48 89 55 f0 mov %rdx,-0x10(%rbp)
418dfc: 49 89 f8 mov %rdi,%r8
418dff: 49 89 fb mov %rdi,%r11
418e02: 49 89 c9 mov %rcx,%r9
418e05: 49 c1 e1 04 shl $0x4,%r9
418e09: 4c 03 cf add %rdi,%r9
418e0c: 4d 3b c1 cmp %r9,%r8
418e0f: 73 18 jae 418e29 <_memset128ii+0x3d>
418e11: 48 8b 55 f0 mov -0x10(%rbp),%rdx
418e15: 48 8b 45 e8 mov -0x18(%rbp),%rax
418e19: 49 89 00 mov %rax,(%r8)
418e1c: 49 89 50 08 mov %rdx,0x8(%r8)
418e20: 49 83 c0 10 add $0x10,%r8
418e24: 4d 39 c8 cmp %r9,%r8
418e27: 72 e8 jb 418e11 <_memset128ii+0x25>
418e29: 49 8b c3 mov %r11,%rax
418e2c: 48 8b e5 mov %rbp,%rsp
418e2f: 5d pop %rbp
418e30: c3 retq
Note that the expected parameters to memset128ii appear to not be passed by
Dmain; I traced the execution into memset128ii and found that it was trying to
memset an unreasonably large range of memory (2e+15 bytes), probably because
the wrong arguments were passed to it.
Since the only druntime code involved is template wrapper around the compiler
magic type __vector, the fault must lie with the compiler SIMD intrinsics.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449
Maxim Fomin <maxim maxim-fomin.ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |maxim maxim-fomin.ru
---
_memset128ii expects:
%rcx => size_t count
%rdx => .ptr of value array
$rsi => .length of value array
%rdi => pointer to first argument array
what _Dmain passes:
%rcx => nothing (garbage)
%rdx => nothing (garbage)
%rsi => size_t count
%rdi => pointer to 16 byte object
%xmm0 => ubyte16[1] array
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449 Seems to be related to bug 8518. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449 ---Seems to be related to bug 8518.Thanks for founding. The root of the problem (at least this one) is when dmd frontend parses and generates list of expressions, it does not create "hidden" expression which calls _memset128ii. Instead it does this when it executes AssignExpression::toElem() and later calls setArray() which issues call to _memset128ii. However it does not convert ubyte16[1] from static array to dynamic array and passes it as a static array. Since _memset128ii expects dynamic array, the program goes off the rails. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449 --- It may be a regression. 8 month ago Walter introduced two commits to e2ir.c (https://github.com/D-Programming-Language/dmd/commit/6c2a2878200e0df1c73db976a747abf61b6a5e1a) and src/memset.d (https://github.com/D-Programming-Language/druntime/commit/a405a02394e2c26c6a66c3fc5ef3777bb86cd973) to fix reg pair. However there is no crosstalk between how e2ir.c pass arguments and how _memset128ii takes it. I do not know whether original code was supported before these changes, but if it was, this is a regression. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 15 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449
John Colvin <john.loughran.colvin gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |john.loughran.colvin gmail.
| |com
17:25:52 BST ---
Seems to be related to bug 8518.
Thanks for founding. The root of the problem (at least this one) is when dmd
frontend parses and generates list of expressions, it does not create "hidden"
expression which calls _memset128ii. Instead it does this when it executes
AssignExpression::toElem() and later calls setArray() which issues call to
_memset128ii. However it does not convert ubyte16[1] from static array to
dynamic array and passes it as a static array. Since _memset128ii expects
dynamic array, the program goes off the rails.
I'm pretty sure the use of void[] in _memset128ii is simply so as to have a
128bit data type. It's never used as, or expected to be, an array.
_memset128ii doesn't care whether it's being passed a static or dynamic array,
it just blindly increments a pointer and writes to it "count" times.
_memset128ii expects:
%rcx => size_t count
%rdx => .ptr of value array
$rsi => .length of value array
%rdi => pointer to first argument array
This is incorrect. _memset128 expects:
RCX: size_t count
RDX: higher 64 bits of value
RSI: lower 64 bits of value
RDI: pointer to the 1st element of the destination array.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 21 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449 17:27:06 BST ---/s/_memset128/_memset128ii -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------I'm pretty sure the use of void[] in _memset128ii is simply so as to have a 128bit data type. It's never used as, or expected to be, an array. _memset128ii doesn't care whether it's being passed a static or dynamic array, it just blindly increments a pointer and writes to it "count" times.Seems to be related to bug 8518.Thanks for founding. The root of the problem (at least this one) is when dmd frontend parses and generates list of expressions, it does not create "hidden" expression which calls _memset128ii. Instead it does this when it executes AssignExpression::toElem() and later calls setArray() which issues call to _memset128ii. However it does not convert ubyte16[1] from static array to dynamic array and passes it as a static array. Since _memset128ii expects dynamic array, the program goes off the rails._memset128ii expects: %rcx => size_t count %rdx => .ptr of value array $rsi => .length of value array %rdi => pointer to first argument arrayThis is incorrect. _memset128 expects: RCX: size_t count RDX: higher 64 bits of value RSI: lower 64 bits of value RDI: pointer to the 1st element of the destination array.
Apr 21 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449
Maxim Fomin <maxim maxim-fomin.ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |critical
---
I'm pretty sure the use of void[] in _memset128ii is simply so as to have a
128bit data type. It's never used as, or expected to be, an array.
_memset128ii doesn't care whether it's being passed a static or dynamic array,
it just blindly increments a pointer and writes to it "count" times.
I think it does matter whether dynamic array was passed or a static one due to
how arguments are passed.
_memset128ii expects:
%rcx => size_t count
%rdx => .ptr of value array
$rsi => .length of value array
%rdi => pointer to first argument array
This is incorrect. _memset128 expects:
RCX: size_t count
RDX: higher 64 bits of value
RSI: lower 64 bits of value
RDI: pointer to the 1st element of the destination array.
I see no difference between length dynamic array property and your "lower 64
bits of value" (also between ptr and "higher 64 bits of value"). And passing a
pointer to dynamic array is not the same thing as passing pointer to the first
element: http://dpaste.dzfl.pl/8f91aed8
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 21 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449 19:56:15 BST ---It doesn't matter in this case because it is a pointer being passed, not an array at all.I'm pretty sure the use of void[] in _memset128ii is simply so as to have a 128bit data type. It's never used as, or expected to be, an array. _memset128ii doesn't care whether it's being passed a static or dynamic array, it just blindly increments a pointer and writes to it "count" times.I think it does matter whether dynamic array was passed or a static one due to how arguments are passed.because value is not an array. As I said before, void[] is just used because conveniently void[].sizeof == 16 (128 bits) on x64 (the check for x64 is done inside e2ir.c)I see no difference between length dynamic array property and your "lower 64 bits of value" (also between ptr and "higher 64 bits of value")._memset128ii expects: %rcx => size_t count %rdx => .ptr of value array $rsi => .length of value array %rdi => pointer to first argument arrayThis is incorrect. _memset128 expects: RCX: size_t count RDX: higher 64 bits of value RSI: lower 64 bits of value RDI: pointer to the 1st element of the destination array.And passing a pointer to dynamic array is not the same thing as passing pointer to the first element: http://dpaste.dzfl.pl/8f91aed8See my comment above. Each *element* of the array is being represented by a void[]. There is no D style array passing happening here, static or otherwise, it's just pointers. Imagine replacing void[] with a hypothetical _128BitType and you'll see what I mean. I'm currently re-implementing memset.d and updating the compiler to interact with the new functions. This should hopefully fix this bug and maybe 9969 also, if there isn't a nasty backend bug hiding behind it all. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 21 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449 20:11:09 BST ---There is no D style array passing happening here, static or otherwise, it's just pointers.Sorry, mistake. There is an array being passed as "value", but from the callers point of view (generated in dmd) it's not an array at all, it's just a 128 bit type. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 21 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449 ---Value is actually accepted as an array due to passing conversions and unusual usage inside memset function is no excuse for changing ABI interpretation. Clearly, anyone can pass many different things through some inappropriate parameter but it does not mean that each time callee would adjust passing convention for different types. I don't see point in this dispute further . I argue that value is technically accepted as dynamic array and you argue that it is treated as 128 bit element. These points don't contradict and however arguments are called (lower value or length property) does change the picture - there is no correspondence between what is passed and what is received.I see no difference between length dynamic array property and your "lower 64 bits of value" (also between ptr and "higher 64 bits of value").because value is not an array. As I said before, void[] is just used because conveniently void[].sizeof == 16 (128 bits) on x64 (the check for x64 is done inside e2ir.c)I'm currently re-implementing memset.d and updating the compiler to interact with the new functions. This should hopefully fix this bug and maybe 9969 also, if there isn't a nasty backend bug hiding behind it all.I doubt that it is possible without dmd hacking but good luck. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 22 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9449
Ali Cehreli <acehreli yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |acehreli yahoo.com
---
I hit the same bug without any obvious SIMD operations:
struct Point
{
double f;
double g;
}
void main()
{
Point[1] arr;
}
Ali
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 26 2013