Closed tbonfort closed 12 years ago
Author: mgleahy Date: 2008/06/29 - 14:57 I tested this the other day with beta2 (and just now with beta3), and it seems to be fine on an F8-x86_64 system I have running, though I still get pretty much the same result on F7-x86_64. Perhaps the problem is to do with the versions of mono (1.2.5.1-3.fc8 vs 1.2.3-5.fc7), or some other unknown factor on my F7 setup...?
Author: tamas Date: 2008/06/30 - 18:34 I've tried both 5.0 and the development version with mono 1.2.2.1 and was working fine (Debian 2.6.18-5-amd64). However versions after 1.2.2.1 may suffer from this issue, but I don't think it's mapscript related. Maybe a test with the mono trace option and a valgrind test would be able to show up something. I hope I'll have a couple of days in the future to deal with this.
Author: mgleahy Date: 2008/07/01 - 05:09 I ran the mono --trace option, as well as valgrind (see attached files). I don't know the first thing about valgrind, so I hope this is what you're looking for.
Since the later mono version on my F8 system is (1.2.5.1) works fine, I guess that's not the issue. If I'm the only one that's run into this problem, and it's only on the one F7 setup, then my guess is it's a problem with something else on my F7 system.
Author: mgleahy Date: 2008/07/01 - 05:11 Sorry - here's some extra output from valgrind that didn't go into the log file:
Stacktrace:
at (wrapper managed-to-native) OSGeo.MapServer.mapscriptPINVOKE.delete_shapeObj (System.Runtime.InteropServices.HandleRef) <0x00012> at (wrapper managed-to-native) OSGeo.MapServer.mapscriptPINVOKE.delete_shapeObj (System.Runtime.InteropServices.HandleRef) <0xffffffff> at OSGeo.MapServer.shapeObj.Dispose () <0x00067> at OSGeo.MapServer.shapeObj.Finalize () <0x00018> at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>
Native stacktrace:
mono [0x51b115]
mono [0x4e208d]
/lib64/libpthread.so.0 [0x3b8bc0de00]
/usr/lib64/libmapscript.so(msFreeShape+0x1e) [0x5bc5bce]
/usr/lib64/libmapscript.so(CSharp_delete_shapeObj+0x9) [0x5b88e39]
[0x4f6b674]
Debug info from gdb:
Using host libthread_db library "/lib64/libthread_db.so.1". vgModuleLocal_do_syscall_for_client_WRK () at m_syswrap/syscall-amd64-linux.S:145 in m_syswrap/syscall-amd64-linux.S Current language: auto; currently asm
Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries
Killed
Author: tamas Date: 2009/03/07 - 20:52 I think there have been a couple of changes in the C# interface which could help to prevent from such memory related issues like this. I close this ticket now since I couldn't reproduce this behaviour. It may be reopened if someone can find this issue to exist.
Reporter: mgleahy Date: 2007/07/27 - 19:12 After mapserver/mapscript_csharp have been compiled on a 64-bit platform (F7-x86_64), the 'make test' for mapscript_csharp fails. However, it works fine when used with other applications (at least for basic operations like generating map images from PostGIS data sources).
The error from make test is below. The process does not terminate on its own, requiring ctrl+c to exit: