Martin Landa wrote: > > I can't reproduce this. Running it under GDB might help, or it might > > not; memory corruption is like that.
> It seems to crash at [1]. That's where it trips over the memory corruption, but it doesn't tell us where it happened. Printing the contents of the various structures (Map_info, Plus_head, etc) might provide some clues. > In summary, the sample script works on > > * my laptop (Debian GNU/Linux unstable 32bit, gcc 4.6.1, python 2.6.7) > - GRASS compiled *without* LFS > > and fails on > > * testing server (Debian GNU/Linux stable 64bit, gcc 4.4.5, python > 2.6.6) - GRASS compiled *with* LFS LFS should be a no-op on a 64-bit platform, i.e. off_t should always be 64-bit. FWIW, it works for me on a 32-bit platform with LFS enabled. Have you tried writing an equivalent C program and seeing whether that works? We might be looking at a bug which has nothing to do with Python or ctypes. As the script is much simpler than a typical v.* C program, it's possible that some initialisation is being skipped. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
