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
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 ---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. -- 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.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: -------_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 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