digitalmars.D.bugs - char[] ~= causes segfault on Linux (DMD v0.101) - sc_diff.txt
DMD v0.101 for Linux _After_ rebuilding libphobos.a on Linux, this code will cause a segfault: void main() { char[] str; str ~= "test"; // segfault //str = str ~ "test"; // Ok } Tracing it into internal/gc/gc.d, it will cause the segfault at this line of code (dereferencing px.data is the culprit): extern (C) Array _d_arrayappend(Array *px, byte[] y, uint size) { uint cap = _gc.capacity(px.data); // segfault here Used ar to extract and obj2asm to dump the assembler from both the newly recompiled gc.o and the as-shipped gc.o. The diff file showed differences in the generated code for the _d_arrayappend function. as-shipped: _d_arrayappend: push EBP mov EBP,ESP sub ESP,0Ch push EBX mov EBX,8[EBP] ; <----------- mov EAX,_D3std2gc3_gcPS3gcx2GC push ESI push EDI mov EDI,014h[EBP] push dword ptr 4[EBX] call near ptr _D3gcx2GC8capacityFPvZk as-compiled: _d_arrayappend: push EBP mov EBP,ESP sub ESP,010h push EBX mov EBX,0Ch[EBP] ; <---------- mov EAX,_D3std2gc3_gcPS3gcx2GC push ESI push EDI mov EDI,018h[EBP] push dword ptr 4[EBX] call near ptr _D3gcx2GC8capacityFPvZk The obj2asm for the program (-O -inline -release): _Dmain: push EBP mov EBP,ESP sub ESP,8 push 1 lea EAX,-8[EBP] mov dword ptr -8[EBP],0 mov dword ptr -4[EBP],0 push dword ptr _TMP0[01Fh] push dword ptr _TMP0[021h] push EAX call near ptr _d_arrayappend add ESP,010h mov ESP,EBP pop EBP ret The relavant assembler for the non-release build is the same, and also causes the segfault. The diff file is attached. - Dave begin 0644 sc_diff.txt M-SDX8S P-`T*/"`)"6UO= E%05 L,$-H6T5"4%T-"BTM+0T*/B`)"6UO= E% M/B`)"6UO= E;15-)72Q%05 -"CX "0EM;W8)14%8+$5320T*/B`)"6UO= DT ` end
Sep 02 2004
Anything else I could provide regarding this? Thanks, - Dave In article <ch8ukr$172i$1 digitaldaemon.com>, Dave says...DMD v0.101 for Linux _After_ rebuilding libphobos.a on Linux, this code will cause a segfault: void main() { char[] str; str ~= "test"; // segfault //str = str ~ "test"; // Ok } Tracing it into internal/gc/gc.d, it will cause the segfault at this line of code (dereferencing px.data is the culprit): extern (C) Array _d_arrayappend(Array *px, byte[] y, uint size) { uint cap = _gc.capacity(px.data); // segfault here Used ar to extract and obj2asm to dump the assembler from both the newly recompiled gc.o and the as-shipped gc.o. The diff file showed differences in the generated code for the _d_arrayappend function. as-shipped: _d_arrayappend: push EBP mov EBP,ESP sub ESP,0Ch push EBX mov EBX,8[EBP] ; <----------- mov EAX,_D3std2gc3_gcPS3gcx2GC push ESI push EDI mov EDI,014h[EBP] push dword ptr 4[EBX] call near ptr _D3gcx2GC8capacityFPvZk as-compiled: _d_arrayappend: push EBP mov EBP,ESP sub ESP,010h push EBX mov EBX,0Ch[EBP] ; <---------- mov EAX,_D3std2gc3_gcPS3gcx2GC push ESI push EDI mov EDI,018h[EBP] push dword ptr 4[EBX] call near ptr _D3gcx2GC8capacityFPvZk The obj2asm for the program (-O -inline -release): _Dmain: push EBP mov EBP,ESP sub ESP,8 push 1 lea EAX,-8[EBP] mov dword ptr -8[EBP],0 mov dword ptr -4[EBP],0 push dword ptr _TMP0[01Fh] push dword ptr _TMP0[021h] push EAX call near ptr _d_arrayappend add ESP,010h mov ESP,EBP pop EBP ret The relavant assembler for the non-release build is the same, and also causes the segfault. The diff file is attached. - Dave begin 0644 sc_diff.txt M-SDX8S P-`T*/"`)"6UO= E%05 L,$-H6T5"4%T-"BTM+0T*/B`)"6UO= E% M/B`)"6UO= E;15-)72Q%05 -"CX "0EM;W8)14%8+$5320T*/B`)"6UO= DT ` end
Sep 08 2004
"Dave" <Dave_member pathlink.com> wrote in message news:chnlj1$14uf$1 digitaldaemon.com...Anything else I could provide regarding this?No, I know what's wrong. The calling conventions on linux are slightly different, and that tripped me up. It's now fixed.
Sep 11 2004
In article <chvn4n$3tt$1 digitaldaemon.com>, Walter says..."Dave" <Dave_member pathlink.com> wrote in message news:chnlj1$14uf$1 digitaldaemon.com...Thanks! - DaveAnything else I could provide regarding this?No, I know what's wrong. The calling conventions on linux are slightly different, and that tripped me up. It's now fixed.
Sep 12 2004