Re: [infomap-nlp-users] svdinterface on 64-bit systems

[<lei...@gm...>]

On Solaris-64bit I had to change the structure of the xv1-array to a
2-dimensional array. The allocation in my code looks like:

  /* compute eigenvectors */
  if (vectors) {
    int i;

    fprintf(stderr, "nrows: %d, ncols: %d, steps: %d\n", nrow, ncol, j);
    if (!(xv1 =3D (double **) mymalloc((j+1)*sizeof(double), "las2: xv1")) =
||
!(xv2 =3D (double *) mymalloc(ncol * sizeof(double), "las2: xv2")))
errormessage("SECOND MALLOC FAILED in LANDR()","",NON);
    for(i=3D0; i<=3Dj; i++) {
      char t[25];
      sprintf(t, "las2: xv1 %d", i);
      if(!(xv1[i]=3Dmymalloc((nrow+ncol)*sizeof(double), t)))
errormessage("Third MALLOC FAILED in LANDR()","",NON);
    }
    kappa =3D max(fabs(kappa), eps34);
    ritvec(n,kappa,ritz,bnd,wptr[6],wptr[9],wptr[4],wptr[5],right,maxprs);
  }

instead of:

  /* compute eigenvectors */
  if (vectors) {
    if (!(xv1 =3D (double *) mymalloc((nrow+ncol)*(j+1)*sizeof(double))) ||
    !(xv2 =3D (double *) mymalloc(ncol * sizeof(double))))
      errormessage("SECOND MALLOC FAILED in LANDR()","",NON);
    kappa =3D dmax(fabs(kappa), eps34);
    ritvec(n,kappa,ritz,bnd,wptr[6],wptr[9],wptr[4],wptr[5],right,maxprs);
  }


And in ritvec():

       * Obs! xv1 is now 2-dimensional to avoid 32-bit memory
       * problems. Th shape is xv1[0 - j][0 - (nrow+ncol-1)] */

      for (i =3D 0; i < n; i++) xv1[kk][i] =3D w1[i];
      nsig +=3D 1;
      kk++;
    }
    id2++;

instead of:

      for (i =3D 0; i < n; i++) xv1[id++] =3D w1[i];
      id +=3D nrow;
      nsig +=3D 1;
    }
    id2++;

Maybe there are some more places, but it's a bit difficult to find since I
made more changes to be able to scale up.

Regards,
Leif


On 9/25/07, Bertram, Albert <ber...@um...> wrote:
>
> Hi Scott,
>
> The modified code works for me.  Using some sample data, I'm able to
> finish the infomap-build, and search using associate. The results look
> reasonable.  This is all on 64-bit linux.
>
> %uname -a
> Linux <hostname> 2.6.17.6 #1 SMP Thu Feb 8 16:09:22 EST 2007 x86_64
> GNU/Linux
>
> I don't think I have access to any other 64 bit environments though.  So
> I can't guarantee it works on solaris or whatever else may be out there.
>
> Regards
>
> Albert
>
> > -----Original Message-----
> > From: Scott Cederberg [mailto:ced...@gm...]
> > Sent: Tuesday, September 25, 2007 3:30 PM
> > To: Bertram, Albert
> > Cc: inf...@li...
> > Subject: Re: [infomap-nlp-users] svdinterface on 64-bit systems
> >
> > Hi Albert,
> >
> >     Thank you!  I looked into this a while back, and what
> > you're saying corresponds to what I found, although I didn't
> > get as far as an actual fix.  Have you been able to run the
> > modified code successfully on 64-bit systems?
> >
> >
> >                Scott
> >
> > On 9/25/07, Bertram, Albert <ber...@um...> wrote:
> > > Hi,
> > >
> > > I don't know if anyone else has looked at infomap-build, or more
> > > specifically svdinterface, segmentation faulting on 64 bit
> > systems in
> > > the past few months, but what I've come to determine is this:
> > >
> > > On the 64-bit system to which I have access, calls to
> > > myutils.c::mymalloc() from within las2.c truncate results
> > to 32-bits.
> > > This produces very unfortunate behavior such as: free()ing memory
> > > immediately after mymalloc() causes a segmentation fault.
> > In testing
> > > a small driver file which used myutils.c::mymalloc(),
> > everything works
> > > fine.  Regular malloc() in las2.c works fine.  I haven't yet looked
> > > into why this was happening, but I don't really plan to at
> > this point,
> > > as I have a solution which works for me at the moment.
> > >
> > > My solution is to replace mymalloc() calls with malloc().
> > This means
> > > you lose all the error testing on malloc, but that's
> > somewhat better
> > > than causing segmentation faults.
> > >
> > > If someone figures out why this is going on I'd be
> > delighted to know,
> > > but until then, I figured I'd share what I saw going on.
> > >
> > > Regards,
> > >
> > > Albert Bertram
> > >
> > >
> > ----------------------------------------------------------------------
> > > --- This SF.net email is sponsored by: Microsoft Defy all
> > challenges.
> > > Microsoft(R) Visual Studio 2005.
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > _______________________________________________
> > > infomap-nlp-users mailing list
> > > inf...@li...
> > > https://lists.sourceforge.net/lists/listinfo/infomap-nlp-users
> > >
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> infomap-nlp-users mailing list
> inf...@li...
> https://lists.sourceforge.net/lists/listinfo/infomap-nlp-users
>



--=20
Leif Gr=F6nqvist lei...@gm...
www.gslt.hum.gu.se/~leifg   0707-164380