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








Dave <Dave_member pathlink.com>