I am replying to my own message to give an update on my own findings in
this matter. I have, after a week of unsuccessful tinkering, finally
given in and imported the new shapes into an existing (working) table
that already contained shapes within the same topic. I had hoped to keep
the two data sets separate because they involve two countries and two
different terminologies on the same subject. I added some columns to
accomodate the second country's data. I then copied (using a simple SQL
statement of the type INSERT INTO ... SELECT ...) the data from the
non-working table (the one that threw the glibc error) into the
abovementioned older table and - lo and behold - it worked! Why that is,
is beyond me. In my understanding there must be an incompatibility in
the way the newer Postgis version behaviour when one calls
CreateGeometryColumn. Somehow, only geometry columns created with the
older Postgis are compatible with Mapserver 4.0.1. This explains why all
the older tables still worked after migrating to a new server and
updating all except Mapserver. This also explains why converting the
data on the old server and then pg_dumping and reimporting it into the
new server doesn't help.
I think I now have enough reason to justify the migration to Mapserver
4.10, costly as it may be for us. Otherwise I can't add any more tables
containing geometry.
What I still wonder is if I should wait for Mapserver 5 (well, more
likely 5.0.1 or 5.0.2 to be on the stable side) or if I should take the
4.10 update first.
Dominik
Dominik Schmid wrote:
Umberto,
I have done as you suggested. The output reads as follows:
Starting program: /tmp/shp2img -m /in/irr/mb/mb_test.map -l "Zonenplan"
-all_debug 9 -layer_debug Zonenplan 9 -o test_img2.png
[Thread debugging using libthread_db enabled]
[New Thread -1208117568 (LWP 4843)]
[Mon Jul 9 13:38:33 2007].267262 msPOSTGISLayerOpen called
datastatement: the_geom from zp_au
[Mon Jul 9 13:38:33 2007].288259 msPOSTGISLayerFreeItemInfo called
[Mon Jul 9 13:38:33 2007].288715 msPOSTGISLayerInitItemInfo called
[Mon Jul 9 13:38:33 2007].291176 msPOSTGISLayerWhichShapes called
[Mon Jul 9 13:38:33 2007].291959 msPOSTGISLayerParseData: unique column
= OID, srid='', geom_column_name = the_geom, table_name=zp_au
[Mon Jul 9 13:38:33 2007].293130 query_string_0_6:DECLARE mycursor
BINARY CURSOR FOR SELECT
grundnut::text,asbinary(force_collection(force_2d(the_geom)),'NDR'),OID::text
from zp_au WHERE the_geom && setSRID('BOX3D(760644.999999999
249797.999999997,769195.000000001 261197.000000002)'::BOX3D,
find_srid('','zp_au','the_geom') )
*** glibc detected *** double free or corruption (!prev): 0x08f02a40 ***
Program received signal SIGABRT, Aborted.
[Switching to Thread -1208117568 (LWP 4843)]
0x005027a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
As I'm not a programmer but just a simple web developer my debugging
abilities are naturally rather limited.
Dominik
Umberto Nicoletti schrieb:
Dominik,
this is getting very hard to do if you don't know a bit about
programming.
If you want to try anyway, run shp2img under gdb with the following
command:
#gdb /path/to/shp2img
run -m pathtothefile.map -o /tmp/map.png
When it segfaults issue this command in the gdb shell:
#backtrace
and post its output here.
Umberto
On 7/9/07, Dominik Schmid <[EMAIL PROTECTED]> wrote:
I have recompiled 4.0.1 with debug enabled. I then replaced the existing
shp2img and mapserv.cgi with the newly compiled binaries. Next I ran
shp2img with '-all_debug 9' and 'layer_debug 9' for the offending layer
(data from zp_au). Since I have no idea what possible debug levels there
are or what numbers can be set I have chosen to use a value of 9. Here's
the output of shp2img:
[Mon Jul 9 12:18:03 2007].176107 msPOSTGISLayerOpen called
datastatement: the_geom from zp_au
[Mon Jul 9 12:18:03 2007].185943 msPOSTGISLayerFreeItemInfo called
[Mon Jul 9 12:18:03 2007].186621 msPOSTGISLayerInitItemInfo called
[Mon Jul 9 12:18:03 2007].189609 msPOSTGISLayerWhichShapes called
[Mon Jul 9 12:18:03 2007].190383 msPOSTGISLayerParseData: unique column
= OID, srid='', geom_column_name = the_geom, table_name=zp_au
[Mon Jul 9 12:18:03 2007].192024 query_string_0_6:DECLARE mycursor
BINARY CURSOR FOR SELECT
grundnut::text,asbinary(force_collection(force_2d(the_geom)),'NDR'),OID::text
from zp_au WHERE the_geom && setSRID('BOX3D(760644.999999999
249797.999999997,769195.000000001 261197.000000002)'::BOX3D,
find_srid('','zp_au','the_geom') )
*** glibc detected *** double free or corruption (!prev): 0x0956da40 ***
Since this debug information doesn't help me pinpoint the problem I have
to ask back here at the list if this tells anyone here anything.
Any help is appreciated.
Dominik
Umberto Nicoletti wrote:
> If you still have the 4.0.1 sources recompile them with enable debug
> and run shp2img under gdb. This at least will tell you where the
> double free is happening and then you might even be able to fix it.
>
> Umberto
>
> On 7/4/07, Dominik Schmid <[EMAIL PROTECTED]> wrote:
>> Hi
>>
>> I have run into this persistent problem and I have already spent
hours
>> upon
>> hours without any result whatsoever. First of all my setup:
>>
>> - Centos 4.4
>> - apache 2.0.52
>> - php 5.1.6
>> - postgresql 8.1.8
>> - mapserver 4.0.1 (I know, I should update mapserver, but having to
>> rebuild
>> all the legends in our system and possibly avoid some other side
effects
>> would be a major headache and have so far kept me from doing this)
>> - gdal 1.4.0
>> - postgis 1.2.1
>> - geos 2.2.3
>> - proj 4.5.0
>> - glibc 2.3.4-2.25
>>
>> The error in the httpd error_log reads as stated in the subject.
>>
>> I have added some multipolygon data that I had previously obtained by
>> converting it from a shape file using shp2pgsql.
>>
>> The odd part about this error is, that I use the same syntax in the
>> map file
>> as for a working multipolygon layer that I had imported using older
>> versions
>> of postgis etc. and the older data works just fine.
>> I have reimported said working data from the original shape file and
>> compared it to the existing data in the working table. the_geom
and other
>> relevant stuff is identical. And still the newly imported data
>> produces this
>> error.
>>
>> I have checked projection, db access privs and just about
everything else
>> that crossed my mind as playing a part to no avail.
>>
>> So, is this problem a known issue? What else could I try/look into?
>> Any advice?
>>
>> Thanks
>> Dominik
>>
>
--
Dominik Schmid
Dipl. Umweltnaturwissenschafter ETH
ilu AG
Zentralstrasse 2a
CH-8610 Uster
Tel: +41 44 / 944 55 56 (Direktwahl)
Tel: +41 44 / 944 55 55 (allgemein)
Fax: +41 44 / 944 55 66
mailto:[EMAIL PROTECTED]
http://www.ilu.ch
--
Dominik Schmid
Dipl. Umweltnaturwissenschafter ETH
ilu AG
Zentralstrasse 2a
CH-8610 Uster
Tel: +41 44 / 944 55 56 (Direktwahl)
Tel: +41 44 / 944 55 55 (allgemein)
Fax: +41 44 / 944 55 66
mailto:[EMAIL PROTECTED]
http://www.ilu.ch
