[geos-devel] Segmentation Fault in ARM platform

[Adriano C Naspolini]

Paul and Frank, thank you for your time.
I made some tests here and, with a simple example and some time expent, 
I could realize the problem was not with geos. I wote an example to read 
a shapefile, get it's "center point" and iterate each feature to check 
if it "Contains(centerPoint)".
Compiling this test "alone", inside a simple main.cpp it works, but the 
same main.cpp linked with my hole program it fails (seg fault).
So, maybe the problem is not the platform, but a library conflict, or a 
bug in my program. I'll try to find it and so I tell you.

Thank you again and best regards.

Adriano

Frank Warmerdam escreveu:
> Paul Ramsey wrote:
>> You're going to want to find someone who can re-produce this, which
>> means someone with a big-endian platform. Perhaps Frank can on his old
>> iBook. Note that you are transferring WKB from OGR to GEOS, so the
>> problem could be the writing step in OGR (writing something invalid)
>> or the reading step in GEOS (screwing up). Attach your program to an
>> issue in trac.
>
> Paul,
>
> As I understand it the ARM is being used in "middle endian"
> mode, or at least is not a traditional big endian system so I
> don't believe my iBook will produce the same problem.
>
> I'm personally not too keen on making all my software support this
> ... distinct ... endian case.  I'm fairly confident that Adriano is
> only seeing the tip of the iceberg so far.
>
> Best regards,
>
>> On Sat, Feb 28, 2009 at 12:45 PM, Adriano C Naspolini
>> <adriano at arvus.com.br> wrote:
>>> Hi people,
>>> I recently installed gdal-1.6.0+geos-3.0.3 in my pc as in my target
>>> prataform (an ARM). Initially, i had an endianess problem with gdal 
>>> (the
>>> target arm is little endian in bytes but big endian in words, so 0x1234
>>> becomes 0x3412 and 0x12345678 becomes 0x56781234). After patching 
>>> shapelib
>>> it's working.
>>> The problem now is with geos: a segmentation fault when I use 
>>> Contains()
>>> function (also with Crosses(), there are certainly others). I think 
>>> this
>>> could be the same endianness problem, or something like it, because the
>>> program runs normally on my pc.
>>>
>>> Backtrace from GDB:
>>> #0  0x2c327dfc in memcpy () from /lib/libc.so.6
>>> #1  0x2c204d7c in std::basic_streambuf<char, std::char_traits<char>
>>>> ::xsgetn () from /usr/lib/libstdc++.so.5
>>> #2  0x2c43e580 in std::istream::read () from /usr/lib/libstdc++.so.6
>>> #3  0x2abb58a4 in geos::io::WKBReader::readGeometry 
>>> (this=0x7f5ff8a0) at
>>> ../../source/headers/geos/io/ByteOrderDataInStream.inl:58
>>> #4  0x2aad8ed8 in GEOSGeomFromWKB_buf (wkb=0x247f28 "\001\003", 
>>> size=93) at
>>> geos_c.cpp:598
>>> #5  0x2b148d4c in OGRGeometry::exportToGEOS (this=0x263fa0) at
>>> ogrgeometry.cpp:1706
>>> #6  0x2b148614 in OGRGeometry::Contains (this=0x7f5ff8b0, 
>>> poOtherGeom=0x0)
>>> at ogrgeometry.cpp:2560
>>> #7  0x0001ee8c in Mapa::getAttr (this=0xac818,
>>> longitude=-47.590694333333332, latitude=-15.337605333333332) at
>>> src/model/mapa.cpp:191
>>>
>>> Any Idea?
>>>
>>> Thank you.
>>>
>>> Adriano
>>>
>>>
>>> _______________________________________________
>>> geos-devel mailing list
>>> geos-devel at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>
>