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

[Bertram, A. <ber...@um...>]

Hi again,

For anyone interested, I identified a simpler solution, and the root
cause of this problem.

Most, and maybe all, C compilers will assume type int for undeclared
functions.  In las2.c, the mymalloc() function is not declared, thus it
was assumed to be of type int, which on most systems is 32 bits long,
and the 64 bit addresses were truncated.  On 32 bit compilers this
doesn't present a problem.

The more elegant solution to this problem is to add:

#include "myutils.h"=20

to las2.c, which contains declarations for mymalloc().  I performed a
quick test, and found this to work for me on the 64 bit linux system I
use.

Regards,

Albert Bertram

> -----Original Message-----
> From: Bertram, Albert=20
> Sent: Tuesday, September 25, 2007 3:12 PM
> To: 'inf...@li...'
> Subject: Re: [infomap-nlp-users] svdinterface on 64-bit systems
>=20
> Hi,
>=20
> I don't know if anyone else has looked at infomap-build, or=20
> more specifically svdinterface, segmentation faulting on 64=20
> bit systems in the past few months, but what I've come to=20
> determine is this:
>=20
> On the 64-bit system to which I have access, calls to=20
> myutils.c::mymalloc() from within las2.c truncate results to=20
> 32-bits.  This produces very unfortunate behavior such as:=20
> free()ing memory immediately after mymalloc() causes a=20
> segmentation fault.  In testing a small driver file which=20
> used myutils.c::mymalloc(), everything works fine.  Regular=20
> malloc() in las2.c works fine.  I haven't yet looked into why=20
> this was happening, but I don't really plan to at this point,=20
> as I have a solution which works for me at the moment.
>=20
> My solution is to replace mymalloc() calls with malloc(). =20
> This means you lose all the error testing on malloc, but=20
> that's somewhat better than causing segmentation faults.
>=20
> If someone figures out why this is going on I'd be delighted=20
> to know, but until then, I figured I'd share what I saw going on.
>=20
> Regards,
>=20
> Albert Bertram
>=20