Thread overview
struct initializer bug in dmd.124
May 19, 2005
Ben Hinkle
May 20, 2005
Ben Hinkle
May 20, 2005
Walter
May 20, 2005
Ben Hinkle
May 20, 2005
Walter
May 20, 2005
Ben Hinkle
May 20, 2005
Walter
May 20, 2005
Thomas Kuehne
May 19, 2005
I haven't narrowed down some reproduction steps but MinTL is busted by I
think a faulty struct initializer. The statement
Node* x = new Node;
where
struct Node {
  Node* left, right, parent;
  Key key;
  Value value;
}
allocates a Node where left is 0x20 instead of null. The result is
eventually a seg-v. It works ok when Key,Value are int,int but with
Key,Value set to char[],char[] it is wrong. Is there a way to look at the
actual symbol definition in the object file to see what it has for
_init_5mintl...


May 20, 2005
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d6j892$2pk9$1@digitaldaemon.com...
>I haven't narrowed down some reproduction steps

here are the reproduction steps:
struct Node {
  Node* left,right,parent;
  int color;
  char[] key;
  char[] value;
}
int main() {
  Node* x = new Node;
  assert( x.left is null );
  return 0;
}

Error: AssertError Failure structbug.d(9)


May 20, 2005
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d6j892$2pk9$1@digitaldaemon.com...
> I haven't narrowed down some reproduction steps but MinTL is busted by I
> think a faulty struct initializer. The statement
> Node* x = new Node;
> where
> struct Node {
>   Node* left, right, parent;
>   Key key;
>   Value value;
> }
> allocates a Node where left is 0x20 instead of null. The result is
> eventually a seg-v. It works ok when Key,Value are int,int but with
> Key,Value set to char[],char[] it is wrong. Is there a way to look at the
> actual symbol definition in the object file to see what it has for
> _init_5mintl...

obj2asm is the right tool for that.


May 20, 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben Hinkle schrieb am Thu, 19 May 2005 19:42:25 -0400:
> I haven't narrowed down some reproduction steps but MinTL is busted by I
> think a faulty struct initializer. The statement
> Node* x = new Node;
> where
> struct Node {
>   Node* left, right, parent;
>   Key key;
>   Value value;
> }
> allocates a Node where left is 0x20 instead of null. The result is
> eventually a seg-v. It works ok when Key,Value are int,int but with
> Key,Value set to char[],char[] it is wrong.

Seems to be a Windows-only bug. Added to DStress as http://dstress.kuehne.cn/run/s/struct_initialization_07.d http://dstress.kuehne.cn/run/s/struct_initialization_07_B.d

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCjdNt3w+/yD4P9tIRAu2eAJ42fJ7+UQdGoTaU35GV3r9H2S3OYQCeL1oA
sMdN6xiQvnqnpcLPTQLFBbU=
=rgKG
-----END PGP SIGNATURE-----
May 20, 2005
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d6j9fq$2qdd$1@digitaldaemon.com...
> Error: AssertError Failure structbug.d(9)

I can't reproduce on windows. Are you running on an x86 box? The function in phobos/internal/gc _d_newarrayi may be the culprit if the stack is different than x86. I'll change it to use std.c.stdarg.


May 20, 2005
"Walter" <newshound@digitalmars.com> wrote in message news:d6lc4s$1gse$1@digitaldaemon.com...
>
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d6j9fq$2qdd$1@digitaldaemon.com...
>> Error: AssertError Failure structbug.d(9)
>
> I can't reproduce on windows. Are you running on an x86 box? The function
> in
> phobos/internal/gc _d_newarrayi may be the culprit if the stack is
> different
> than x86. I'll change it to use std.c.stdarg.

I was on WinXP box at home. That was after rebuilding phobos as debug so that std.boxer would work. I'll look at it again when I get home. I just tried the example I posted here at work (WinXP again) and it worked ok both with and without a rebuild of phobos so when I get home I'll whack my dmd and redo the setup and see if it fixes the problem.


May 20, 2005
"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d6lclr$1hbj$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:d6lc4s$1gse$1@digitaldaemon.com...
> >
> > "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d6j9fq$2qdd$1@digitaldaemon.com...
> >> Error: AssertError Failure structbug.d(9)
> >
> > I can't reproduce on windows. Are you running on an x86 box? The
function
> > in
> > phobos/internal/gc _d_newarrayi may be the culprit if the stack is
> > different
> > than x86. I'll change it to use std.c.stdarg.
>
> I was on WinXP box at home. That was after rebuilding phobos as debug so that std.boxer would work. I'll look at it again when I get home. I just tried the example I posted here at work (WinXP again) and it worked ok
both
> with and without a rebuild of phobos so when I get home I'll whack my dmd and redo the setup and see if it fixes the problem.

The 0x20 value is instructive. It's the size of the struct, and is pushed on the stack as the argument to _d_newarrayi just before the ..., which is what led me to believe it's a stack issue.


May 20, 2005
"Walter" <newshound@digitalmars.com> wrote in message news:d6lfuv$1jqq$1@digitaldaemon.com...
>
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d6lclr$1hbj$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message news:d6lc4s$1gse$1@digitaldaemon.com...
>> >
>> > "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d6j9fq$2qdd$1@digitaldaemon.com...
>> >> Error: AssertError Failure structbug.d(9)
>> >
>> > I can't reproduce on windows. Are you running on an x86 box? The
> function
>> > in
>> > phobos/internal/gc _d_newarrayi may be the culprit if the stack is
>> > different
>> > than x86. I'll change it to use std.c.stdarg.
>>
>> I was on WinXP box at home. That was after rebuilding phobos as debug so that std.boxer would work. I'll look at it again when I get home. I just tried the example I posted here at work (WinXP again) and it worked ok
> both
>> with and without a rebuild of phobos so when I get home I'll whack my dmd and redo the setup and see if it fixes the problem.
>
> The 0x20 value is instructive. It's the size of the struct, and is pushed
> on
> the stack as the argument to _d_newarrayi just before the ..., which is
> what
> led me to believe it's a stack issue.

I couldn't reproduce it on my home machine after resetting my dmd installation either. Looks like I had a bogus install. I'm all set now.