ogr2ogr: malloc(): with -overwrite flag

[aestrada]

All,

I have come across a something that looks like a bug from yesterday's build. I am running the following command

ogr2ogr -skipfailures -progress -overwrite -s_srs EPSG:4326 -t_srs EPSG:4326 -f "GML" middlearth.gml PG:"host=my user=db dbname=my password=password" -sql "SELECT d.id as id, d.service as service, d.title as title, d.date_taken as date_taken, d.date_inserted as date_inserted,d.url as url, d.description as description, d.geom as geom FROM getdata d, world_boundaries b WHERE (b.cntry_name = '%middlearth%') AND d.geom && b.wkb_geometry AND intersects(d.geom, b.wkb_geometry)" -nln "middlearth" -nlt POINT &

it throws this: * glibc detected * ogr2ogr: malloc(): memory corruption: 0x0000000001f374c0 *

When I remove -overwrite as an argument it works fine. There is no file there initially but -overwrite should also not care if its there or not. If the file is there, it should be overwritten if its not there a new one should be created. Am I wrong in assuming that?

[Even Rouault]

I'm unable to reproduce any crash. Could you mention the GDAL version you are using, and provide an example where the source dataset is a shapefile (or any other file based input) that you could attach to the ticket ?

But anyway -overwrite will not work as you expect with GML. -overwrite works when you can open a file in update mode and the driver supports deleting at the layer level (but not to overwrite a file). But GML cannot be updated per layer. So you will have to delete the file for your purpose.

But it shouldn't crash, so I'm interested in having a way of reproducing this.

[aestrada]

All of the data I inserted in to postgres I did through ogr so one would assume that this can be replicated on any machine as long as its a point geometry. As for the build of GDAL, I did this yesterday on an up to date version of CentOS 6.0.

    svn checkout https://svn.osgeo.org/gdal/trunk/gdal gdal

	yum install libcurl | libcurl-devel
	yum install expat | expat-devel
	yum install xerces-c | xerces-c-devel
	
    ./configure --with-libz=internal --with-curl=/usr/bin/curl-config --with-fgdb=/root/Documents/FileGDB_API \
    --with-png=internal --with-libtiff=internal --with-geotiff=internal \
    --with-jpeg=internal --with-gif=internal --with-geos=yes \
    --with-pg=/usr/bin/pg_config --with-sqlite3=/usr/local/lib  \
    --with-threads=yes --with-poppler=yes --with-python --with-liblzma=yes \
    --with-xerces=yes --with-expat=yes

Do that help at all?

[Even Rouault]

Not really. I just see you are using trunk ;-) And I've tried with a PG table with point geometry, but no issue.

But I really insist : try replicating with a shapefile for example (you can in a first step convert your PG table into a shapefile, and then try convert the shapefile to GML).

Otherwise running the ogr2ogr command line under Valgrind (and/or gdb) and post its output could help. But being able to replicate the issue with my machine is the preferred and fastest way.

[aestrada]

Even,

I rebuilt GDAL with the most current code from trunk and I am not seeing this error anymore. The only difference in what I did today with what I did last week *I think* is that I didn't specifically run ldconfig after make install. I don't know if that makes a difference or not but I figured it wouldn't hurt to report it.

Adam

[Even Rouault]

Ok, I'll consider the ticket as invalid.