compiling c# mapscript on F7-x86_64
Mike Leahy
mgleahy at GOLDEN.NET
Tue Jun 12 12:35:36 EDT 2007
Tamas,
I tried running each of the three tests individually...drawmap gives a
much less verbose error, while I generally get the same results for
shapeinfo and shpdump...though sometimes I'll get even more info in the
output, like in the (much abbreviated) sample below. In this latter
case, the test won't terminate on its own...or at least I haven't waited
for it to. I still don't know what to make of it all.
Does this add any further insight? When I have a chance (probably a
couple weeks from now), I can try this again on a 32-bit setup.
Mike
========================================================
[mgleahy at localhost csharp]$ LC_ALL=C mono ./drawmap.exe
../../tests/test.map test_csharp.png
# Map layers 1; Map name =
Unhandled Exception: System.NullReferenceException: Object reference not
set to an instance of an object
at DrawMap.Main (System.String[] args) [0x00000]
========================================================
[mgleahy at localhost csharp]$ LC_ALL=C mono ./shapeinfo.exe
../../tests/point.shp
ShapeType =
Num shapes = 0
(xmin, ymin) = (5.30992112211421E-317,0) (xmax, ymax) =
(2.3177853899156E-310,2.3177853900065E-310)
*** glibc detected *** mono: free(): invalid pointer: 0x00002aaaaacfefc8 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3fad070412]
/lib64/libc.so.6(cfree+0x8c)[0x3fad073b1c]
/usr/lib64/libmapscript.so(CSharp_delete_shapefileObj+0x11)[0x2aaaab568521]
[0x4023267c]
======= Memory map: ========
00400000-005ca000 r-xp 00000000 08:12 4020216
/usr/bin/mono
007ca000-007cd000 rw-p 001ca000 08:12 4020216
/usr/bin/mono
007cd000-007e6000 rw-p 007cd000 00:00 0
009cc000-009d3000 rw-p 001cc000 08:12 4020216
/usr/bin/mono
009d3000-00b40000 rw-p 009d3000 00:00 0
[heap]
40000000-40010000 rwxp 40000000 00:00 0
<snip>
3fad482000-3fad681000 ---p 00082000 08:12 978541
/lib64/libm-2.6.so
3fad681000-3fad682000 r--p 00081000 08:12 978541
/lib64/libm-2.6.so
3fad682000-3fad683000 rw-p 00082000 08:12 978541
/lib64/libm-2.6.so
<snip>
3fc0a00000-3fc0a1f000 r-xp 00000000 08:12 978328
/lib64/libncurses.so.5.6
3fc0a1f000-3fc0c1e000 ---p 0001f000 08:12 978328
/lib64/libncurses.so.5.6
3fc0c1e000-3fc0c1f000 rw-p 0001e000 08:12 978328
/lib64/libncurses.so.5.6
2aaaaaaab000-2aaaaaacc000 rw-p 2aaaaaaab000 00:00 0
2aaaaaad1000-2aaaaaaf6000 rw-p 2aaaaaad1000 00:00 0
2aaaaaaf6000-2aaaaaaf7000 r-xp 00000000 08:16 1376494
/home/sources/mapserver-4.10.2/mapscript/csharp/shapeinfo.exe
2aaaaaaf7000-2aaaaacea000 r-xp 00000000 08:12 4535523
/usr/lib64/mono/1.0/mscorlib.dll
2aaaaacea000-2aaaaacf1000 r--s 00000000 08:12 4013989
/usr/lib64/gconv/gconv-modules.cache
<snip>
2aaaafbfc000-2aaaafbfd000 rw-p 00000000 08:12 4020117
/usr/lib64/libungif.so.4.1.3
2aaab0000000-2aaab0021000 rw-p 2aaab0000000 00:00 0
2aaab0021000-2aaab4000000 ---p 2aaab0021000 00:00 0
7fff53eae000-7fff53ec3000 rw-p 7fff53eae000 00:00 0
[stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vdso]
Stacktrace:
at (wrapper managed-to-native) mapscriptPINVOKE.delete_shapefileObj
(System.Runtime.InteropServices.HandleRef) <0x00012>
at (wrapper managed-to-native) mapscriptPINVOKE.delete_shapefileObj
(System.Runtime.InteropServices.HandleRef) <0xffffffff>
at shapefileObj.Dispose () <0x00067>
at shapefileObj.Finalize () <0x00018>
at (wrapper runtime-invoke) System.Object.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>
Native stacktrace:
mono [0x517025]
/lib64/libpthread.so.0 [0x3fae00dd20]
/lib64/libc.so.6(gsignal+0x35) [0x3fad0305b5]
/lib64/libc.so.6(abort+0x110) [0x3fad032060]
/lib64/libc.so.6 [0x3fad068d0b]
/lib64/libc.so.6 [0x3fad070412]
/lib64/libc.so.6(cfree+0x8c) [0x3fad073b1c]
/usr/lib64/libmapscript.so(CSharp_delete_shapefileObj+0x11)
[0x2aaaab568521]
[0x4023267c]
<Here I need to hit Ctrl+C to quit the test>
Tamas Szekeres wrote:
> Mike,
>
> I still couldn't reproduce this behaviour. Did the shpdump sample
> display any features from the shapefile?
> Is the following bug relevant to this problem?
> http://trac.osgeo.org/mapserver/ticket/1598
>
> Do the test run if you remove the shpdump test in the csharp makefile?
>
> Best regards,
>
> Tamas
>
>
>
> 2007/6/9, Mike Leahy <mgleahy at golden.net>:
>> Hello again,
>>
>> I don't know if this helps at all, but I gave the C# dll I built a try
>> with my application despite the output from the make test...turns out it
>> actually works. Granted, my application does relatively little at the
>> moment (it essentially creates a map object with a PostGIS layer, and
>> draws the image), so this isn't a thorough test, but perhaps there's a
>> problem with the make test operation instead (at least in my context)?
>>
>> Regards,
>> Mike
>>
>> Tamas Szekeres wrote:
>> > Mike,
>> >
>> > I haven't managed to reproduce this issue using the SVN trunk on my
>> > SUSE10 vs MONO 1.2.4 configuration, the make test works fairly well.
>> > I'll be trying to set up an FC7 system to make similar tests but I
>> > guess it will take some days to complete.
>> >
>> > Best regards,
>> >
>> > Tamas
>> >
>> >
>> >
>> > 2007/6/7, Mike Leahy <mgleahy at golden.net>:
>> >> Tamas,
>> >>
>> >> Thanks for the replies. I'm fairly sure what you're suggesting is not
>> >> the
>> >> issue in my case. This is a fresh setup, so there's no previous/other
>> >> versions of mapserver. I tried what you suggested as well, and I
>> got the
>> >> same output after setting the LD_LIBRARY_PATH to point to my mapserv
>> >> binaries. Besides that, I've never had to do anything with
>> >> LD_LIBRARY_PATH
>> >> before. I'm pretty sure that mapscript_csharp.dll only relies on the
>> >> libmapscript.so that accompanies it (and through that, all of the
>> other
>> >> mapserver dependencies). As far as I can tell, libmapscript.so is
>> >> linked
>> >> from the current folder for the 'make test' operation. If
>> successful, I
>> >> normally copy libmapscript.so to /usr/lib64, along with all the other
>> >> libraries, where it is accessible to any Mono applications that use
>> the
>> >> csharp DLL.
>> >>
>> >> I figure this must be something specific to Fedora 7 and/or
>> >> Mono-1.2.3. I
>> >> did try compiling MapServer/MapScript with minimal options to
>> ensure it
>> >> wasn't some of the additional dependencies I'm using (e.g., GDAL,
>> >> PostGIS,
>> >> etc...) and it still gave the same results.
>> >>
>> >> Any other recommendations?
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >> On Thu, 7 Jun 2007 20:14:46 +0200, Tamas Szekeres
>> >> <szekerest at GMAIL.COM> wrote:
>> >>
>> >> >You should check whether other version of mapserver is installed or
>> >> >not. You probably have to set up your mapserver directory in
>> >> >LD_LIBRARY_PATH when running the tests.
>> >> >
>> >> >Best regards,
>> >> >
>> >> >Tamas
>> >> >
>> >> >
>> >> >2007/6/7, Mike Leahy <mgleahy at golden.net>:
>> >> >> I ran ./configure for MapServer with all desired options, ran make,
>> >> then
>> >> >> went into mapscript/csharp and ran make there. Is there something
>> >> else I
>> >> >> should have done?
>> >> >>
>> >> >> On Thu, 7 Jun 2007 18:10:37 +0200, Tamas Szekeres
>> >> <szekerest at GMAIL.COM>
>> >> wrote:
>> >> >>
>> >> >> >Did you compile the mapserver core and mapscript with the same
>> >> >> >configuration (by using the same GEOS option for example)?
>> >> >> >
>> >> >> >Best regards,
>> >> >> >
>> >> >> >Tamas
>> >> >> >
>> >> >> >
>> >> >> >2007/6/7, Mike Leahy <mgleahy at golden.net>:
>> >> >> >> Hello List,
>> >> >> >>
>> >> >> >> I just finished upgrading one of my 64-bit machines to Fedora
>> >> 7. I've
>> >> >> >> already noticed that binary MapServer packages are installable
>> >> from the
>> >> >> >> repositories. However, it seems these lack the csharp mapscript
>> >> module,
>> >> >> >> which is something I use frequently. So I did my usual
>> routine to
>> >> >> >> compile MapServer from source...everything looked okay, until
>> I ran
>> >> >> >> 'make test' for the c# mapscript module (see output below). I
>> >> haven't
>> >> >> >> been able to try this on a 32-bit machine, so can only guess
>> >> that it
>> >> >> >> might an issue with the 64-bit environment (though FC6-x86_64
>> >> with an
>> >> >> >> older version of Mono seemed to work fine). I'm not sure what
>> >> to make
>> >> >> >> of this output from the make test - has anyone seen anything
>> >> like this
>> >> >> >> before, or can anyone make any suggestions?
>> >> >> >>
>> >> >> >> Thanks in advance for any help,
>> >> >> >> Mike
>> >> >> >>
>> >> >> >>
>> ==================================================================
>> >> >> >>
>> >> >> >> [mgleahy at localhost csharp]$ make test
>> >> >> >> LC_ALL=C mono ./shpdump.exe ../../tests/point.shp
>> >> >> >> Stacktrace:
>> >> >> >>
>> >> >> >> at (wrapper managed-to-native)
>> mapscriptPINVOKE.delete_shapeObj
>> >> >> >> (System.Runtime.InteropServices.HandleRef) <0x00012>
>> >> >> >> at (wrapper managed-to-native)
>> mapscriptPINVOKE.delete_shapeObj
>> >> >> >> (System.Runtime.InteropServices.HandleRef) <0xffffffff>
>> >> >> >> at shapeObj.Dispose () <0x00067>
>> >> >> >> at shapeObj.Finalize () <0x00018>
>> >> >> >> at (wrapper runtime-invoke) System.Object.runtime_invoke_void
>> >> >> >> (object,intptr,intptr,intptr) <0xffffffff>
>> >> >> >>
>> >> >> >> Native stacktrace:
>> >> >> >>
>> >> >> >> mono [0x517025]
>> >> >> >> mono [0x4ddf9d]
>> >> >> >> /lib64/libpthread.so.0 [0x3fae00dd20]
>> >> >> >> /lib64/libc.so.6(cfree+0x3b) [0x3fad073acb]
>> >> >> >> ./libmapscript.so(msFreeShape+0x2c) [0x2aaaab573efc]
>> >> >> >> ./libmapscript.so(CSharp_delete_shapeObj+0x9)
>> >> [0x2aaaab53cf69]
>> >> >> >> [0x4001f90c]
>> >> >> >>
>> >> >> >> Debug info from gdb:
>> >> >> >>
>> >> >> >> (no debugging symbols found)
>> >> >> >> Using host libthread_db library "/lib64/libthread_db.so.1".
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> [Thread debugging using libthread_db enabled]
>> >> >> >> [New Thread 46912496280112 (LWP 16759)]
>> >> >> >> [New Thread 1075988816 (LWP 16761)]
>> >> >> >> [New Thread 1073822032 (LWP 16760)]
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> (no debugging symbols found)
>> >> >> >> 0x0000003fae00a597 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
>> >> >> >> from /lib64/libpthread.so.0
>> >> >> >> 3 Thread 1073822032 (LWP 16760) 0x0000003fae00d3d1 in
>> >> nanosleep ()
>> >> >> >> from /lib64/libpthread.so.0
>> >> >> >> 2 Thread 1075988816 (LWP 16761) 0x0000003fad0c9ad2 in
>> select ()
>> >> >> >> from /lib64/libc.so.6
>> >> >> >> 1 Thread 46912496280112 (LWP 16759) 0x0000003fae00a597 in
>> >> >> >> pthread_cond_timedwait@@GLIBC_2.3.2 () from
>> /lib64/libpthread.so.0
>> >> >> >>
>> >> >> >> Thread 3 (Thread 1073822032 (LWP 16760)):
>> >> >> >> #0 0x0000003fae00d3d1 in nanosleep () from
>> /lib64/libpthread.so.0
>> >> >> >> #1 0x00000000004c1890 in ?? ()
>> >> >> >> #2 0x0000003fae0061c5 in start_thread () from
>> >> /lib64/libpthread.so.0
>> >> >> >> #3 0x0000003fad0d062d in clone () from /lib64/libc.so.6
>> >> >> >>
>> >> >> >> Thread 2 (Thread 1075988816 (LWP 16761)):
>> >> >> >> #0 0x0000003fad0c9ad2 in select () from /lib64/libc.so.6
>> >> >> >> #1 0x0000003fb1c5646e in g_spawn_sync () from
>> >> /lib64/libglib-2.0.so.0
>> >> >> >> #2 0x0000003fb1c56838 in g_spawn_command_line_sync ()
>> >> >> >> from /lib64/libglib-2.0.so.0
>> >> >> >> #3 0x00000000005170c7 in ?? ()
>> >> >> >> #4 0x00000000004ddf9d in ?? ()
>> >> >> >> #5 <signal handler called>
>> >> >> >> #6 0x0000003fad073acb in free () from /lib64/libc.so.6
>> >> >> >> #7 0x00002aaaab573efc in msFreeShape () from ./libmapscript.so
>> >> >> >> #8 0x00002aaaab53cf69 in CSharp_delete_shapeObj () from
>> >> ./libmapscript.so
>> >> >> >> #9 0x000000004001f90c in ?? ()
>> >> >> >> #10 0x00002aaaaacf8d20 in ?? ()
>> >> >> >> #11 0x0000000000a86770 in ?? ()
>> >> >> >> #12 0x0000000000000001 in ?? ()
>> >> >> >> #13 0x0000003fae00fa28 in g_str_equal () from
>> >> /lib64/libpthread.so.0
>> >> >> >> #14 0x0000000000a29390 in ?? ()
>> >> >> >> #15 0x0000000040223c80 in ?? ()
>> >> >> >> #16 0x0000000040223ee0 in ?? ()
>> >> >> >> #17 0x000000004001f862 in ?? ()
>> >> >> >> #18 0x0000000000a37e68 in ?? ()
>> >> >> >> #19 0x0000000040223ee0 in ?? ()
>> >> >> >> #20 0x0000000040223e50 in ?? ()
>> >> >> >> #21 0x00002aaaaacf8d20 in ?? ()
>> >> >> >> #22 0x00002aaaaaad3e60 in ?? ()
>> >> >> >> #23 0x0000000000a86770 in ?? ()
>> >> >> >> #24 0x00002aaaaacf8d20 in ?? ()
>> >> >> >> #25 0x0000000000a86770 in ?? ()
>> >> >> >> #26 0x00002aaaaacf8d20 in ?? ()
>> >> >> >> #27 0x00000000007ccc08 in ?? ()
>> >> >> >> #28 0x000000004001f690 in ?? ()
>> >> >> >> #29 0x0000000000a5f0b0 in ?? ()
>> >> >> >> #30 0x0000000040223f50 in ?? ()
>> >> >> >> #31 0x000000004001f5d8 in ?? ()
>> >> >> >> #32 0x00002aaaaacf8d20 in ?? ()
>> >> >> >> #33 0x0000000000a86770 in ?? ()
>> >> >> >> #34 0x0000000000000001 in ?? ()
>> >> >> >> #35 0x0000000000000011 in ?? ()
>> >> >> >> #36 0x00002aaaaacf8d20 in ?? ()
>> >> >> >> #37 0x00002aaaaacf8d20 in ?? ()
>> >> >> >> #38 0x00002aaaaaad3e60 in ?? ()
>> >> >> >> #39 0x0000000000a867e0 in ?? ()
>> >> >> >> #40 0x0000000000000000 in ?? ()
>> >> >> >>
>> >> >> >> Thread 1 (Thread 46912496280112 (LWP 16759)):
>> >> >> >> #0 0x0000003fae00a597 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
>> >> >> >> from /lib64/libpthread.so.0
>> >> >> >> #1 0x00000000004bf110 in ?? ()
>> >> >> >> #2 0x00000000004c160d in ?? ()
>> >> >> >> #3 0x00000000004c5b95 in ?? ()
>> >> >> >> #4 0x000000000046ccc6 in mono_domain_finalize ()
>> >> >> >> #5 0x00000000004dc754 in ?? ()
>> >> >> >> #6 0x0000000000414678 in mono_main ()
>> >> >> >> #7 0x0000003fad01daa4 in __libc_start_main () from
>> >> /lib64/libc.so.6
>> >> >> >> #8 0x0000000000413319 in g_str_equal ()
>> >> >> >> #9 0x00007fff93e6c348 in ?? ()
>> >> >> >> #10 0x0000000000000000 in ?? ()
>> >> >> >> #0 0x0000003fae00a597 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
>> >> >> >> from /lib64/libpthread.so.0
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> =================================================================
>> >> >> >> Got a SIGSEGV while executing native code. This usually
>> indicates
>> >> >> >> a fatal error in the mono runtime or one of the native libraries
>> >> >> >> used by your application.
>> >> >> >>
>> =================================================================
>> >> >> >>
>> >> >> >> make: *** [test] Aborted
>> >> >> >>
>> >> >>
>> >>
>> >
>>
>
More information about the mapserver-users
mailing list