Error: *** glibc detected *** double free or corruption (!prev)

[Dominik Schmid]

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 <dominik.schmid at ilu.ch> 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 <dominik.schmid at ilu.ch> 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:dominik.schmid at ilu.ch
>>> 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:dominik.schmid at ilu.ch
http://www.ilu.ch