|
From: <lei...@gm...> - 2007-09-25 19:33:02
|
Hi, I had a similar error but I think it's fixed in the latest version of Infomap. The problem was that integers and pointers were stored in the same arrays. This is fine as long as pointers are 32 bits long but on a 64 bit SUN system I had to update this. If this bug is still around I could try to find the updated source. Regards, Leif 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 > --=20 Leif Gr=F6nqvist lei...@gm... www.gslt.hum.gu.se/~leifg 0707-164380 |