www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9449] New: Segmentation fault in main()

reply d-bugmail puremagic.com writes:
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


--- Comment #0 from tbanelwebmin free.fr 2013-02-04 03:51:35 PST ---
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
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449


hsteoh quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh quickfur.ath.cx


--- Comment #1 from hsteoh quickfur.ath.cx 2013-02-08 20:36:49 PST ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449


hsteoh quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|druntime                    |DMD


--- Comment #2 from hsteoh quickfur.ath.cx 2013-02-08 21:39:27 PST ---
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 
  418632:       66 0f 6f 05 e6 77 01    movdqa 0x177e6(%rip),%xmm0        #
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #3 from Maxim Fomin <maxim maxim-fomin.ru> 2013-02-09 02:48:23 PST
---
_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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449



--- Comment #4 from hsteoh quickfur.ath.cx 2013-02-09 22:26:56 PST ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449



--- Comment #5 from Maxim Fomin <maxim maxim-fomin.ru> 2013-02-09 22:40:37 PST
---
(In reply to comment #4)
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449



--- Comment #6 from Maxim Fomin <maxim maxim-fomin.ru> 2013-02-15 23:41:19 PST
---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #7 from John Colvin <john.loughran.colvin gmail.com> 2013-04-21
17:25:52 BST ---
(In reply to comment #5)
 (In reply to comment #4)
 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. (In reply to comment #3)
 _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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449



--- Comment #8 from John Colvin <john.loughran.colvin gmail.com> 2013-04-21
17:27:06 BST ---
(In reply to comment #7)
 (In reply to comment #5)
 (In reply to comment #4)
 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. (In reply to comment #3)
 _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.

/s/_memset128/_memset128ii -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 21 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449


Maxim Fomin <maxim maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical


--- Comment #9 from Maxim Fomin <maxim maxim-fomin.ru> 2013-04-21 10:52:44 PDT
---
(In reply to comment #7)
 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.
 (In reply to comment #3)
 _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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449



--- Comment #10 from John Colvin <john.loughran.colvin gmail.com> 2013-04-21
19:56:15 BST ---
(In reply to comment #9)
 (In reply to comment #7)
 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.

It doesn't matter in this case because it is a pointer being passed, not an array at all.
 (In reply to comment #3)
 _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").

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)
 And passing a
 pointer to dynamic array is not the same thing as passing pointer to the first
 element: http://dpaste.dzfl.pl/8f91aed8

See 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449



--- Comment #11 from John Colvin <john.loughran.colvin gmail.com> 2013-04-21
20:11:09 BST ---
(In reply to comment #10)
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449



--- Comment #12 from Maxim Fomin <maxim maxim-fomin.ru> 2013-04-22 09:44:52 PDT
---
(In reply to comment #10)
 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)

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'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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9449


Ali Cehreli <acehreli yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acehreli yahoo.com


--- Comment #13 from Ali Cehreli <acehreli yahoo.com> 2013-10-26 11:30:17 PDT
---
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