Thread overview
[bug?] executable segfaults
Jan 26, 2005
Manfred Nowak
Jan 28, 2005
David Friedman
Jan 30, 2005
Manfred Nowak
Jan 30, 2005
Manfred Nowak
January 26, 2005
I have not compared stage2 and stage3 of the compiler built. So it is possible that the compiler is broken.

<code>
// executable segfaults if line 43 is uncommented
// gdc (GCC) 3.4.4 20050121 (prerelease) under cygwin
// flawless run when compiled from dmd.0.111.win32
module set;


class Set( Base, Value=bit){

  Value[ Base] data;

  int opApply(int delegate(inout Base b, inout Value v) dg){
    printf("[opApply ");
    int result = 0;
    for (int i = 0; i < data.length; i++) {
      result = dg(i, data[i]);
      if( result) break;
    }
    printf("]");
    return result;
  }


  void empty(){
    foreach( Base b, Value v; data){
      delete data[ b];
    }
  }

  void include( Base b){
    data[ b]= data[ b];
  }
}


void main(){
  printf("[main ");

  alias char[] String;
  alias Set!( int) InstSet;
  InstSet m= new InstSet;
  m.include( 1);
  printf("%d ", m.data.length);
  //m.empty();
  printf("%d ", m.data.length);

  printf("]");
}
</code>

-manfred
January 26, 2005
Manfred Nowak wrote:

> // executable segfaults if line 43 is uncommented
> // gdc (GCC) 3.4.4 20050121 (prerelease) under cygwin
> // flawless run when compiled from dmd.0.111.win32

> I have not compared stage2 and stage3 of the compiler built. So it is possible that the compiler is broken.

The code works fine (with m.empty();) on Linux
and Darwin, except that it doesn't print anything
on Mac OS X since you left out the \n at the end.

Did you try changing the venerable bit[]
into wbit[] instead ? (that is: byte[])

--anders
January 28, 2005
Manfred Nowak wrote:
> I have not compared stage2 and stage3 of the compiler built. So it is possible that the compiler is broken.
> 
> <code>
> // executable segfaults if line 43 is uncommented
> // gdc (GCC) 3.4.4 20050121 (prerelease) under cygwin
> // flawless run when compiled from dmd.0.111.win32
> module set;
> 
> 
> class Set( Base, Value=bit){
> 
>   Value[ Base] data;
>     int opApply(int delegate(inout Base b, inout Value v) dg){
>     printf("[opApply ");
>     int result = 0;
>     for (int i = 0; i < data.length; i++) {
>       result = dg(i, data[i]);
>       if( result) break;
>     }
>     printf("]");
>     return result;
>   }
> 
> 
>   void empty(){
>     foreach( Base b, Value v; data){
>       delete data[ b];
>     }
>   }
> 
>   void include( Base b){
>     data[ b]= data[ b];
>   }
> }
> 
> 
> void main(){
>   printf("[main ");
> 
>   alias char[] String;
>   alias Set!( int) InstSet;
>   InstSet m= new InstSet;
>   m.include( 1);
>   printf("%d ", m.data.length);
>   //m.empty();
>   printf("%d ", m.data.length);
>     printf("]");
> }
> </code>
> 
> -manfred

I'm not getting the problem on Cygwin or Darwin, but I haven't tried 3.4.4 yet.  I don't think deleting from AAs in a foreach is supported in general, but this example shouldn't crash.

An easier way to clear an AA to simply assign 'null' to it.

David
January 30, 2005
Manfred Nowak wrote:

>   int opApply(int delegate(inout Base b, inout Value v) dg){
>     printf("[opApply ");
>     int result = 0;
>     for (int i = 0; i < data.length; i++) {
>       result = dg(i, data[i]);
>       if( result) break;
>     }
>     printf("]");
>     return result;
>   }

This is wrong. Instead it should be used:
<code>
  int opApply(int delegate(inout Base b, inout Value v) dg){
    fprintf( stderr, "[opApply ");
    int result = 0;
    Base[] keys= data.keys;
    for (int i = 0; i < keys.length; i++) {
      fprintf( stderr, "+");
      result = dg(keys[i], data[keys[i]]);
      if( result) break;
    }
    fprintf( stderr, "]");
    return result;
  }
</code>

But the crash persists. According to gdb the reference to the delegate in the third parameter of phobos.internal.(aaA.d)._aaApply2 is wrong. I'll try to revert to an older snapshot of gcc.

-manfred

January 30, 2005
Manfred Nowak wrote:

> I'll try to revert to an older snapshot of gcc.

Reverted to the version that currently is distributed with cygwin, i.e. gcc-3.3.4 with a D-version that does not understand some features. Problem remains...giving up.

-manfred