[gdal-dev] stack smashing when using ogrinfo with DB2 driver

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] stack smashing when using ogrinfo with DB2 driver

Nikolai Bezdna
I get a strange behaviour when using ogrinfo (or ogr2ogr) with DB2 driver.

ogrinfo "DB2ODBC:database=mydb;DSN=MYDB;Tables=MYSCHEMA.MYTABLE” MYSCHEMA.MYTABLE

Reports:

INFO: Open of `DB2ODBC:database=mydb;DSN=MYDB;Tables=MYSCHEMA.MYTABLE'
     using driver `DB2ODBC' successful.
*** stack smashing detected ***: ogrinfo terminated
======= Backtrace: =========
/lib64/libc.so.6(+0x6fb0c)[0x7fc821d9ab0c]
/lib64/libc.so.6(__fortify_fail+0x37)[0x7fc821e22a77]
/lib64/libc.so.6(__fortify_fail+0x0)[0x7fc821e22a40]
/usr/lib64/libgdal.so(+0xa874d9)[0x7fc822d504d9]
/usr/lib64/libgdal.so(_ZN16OGRDB2DataSource20CreateMetadataTablesEv+0x4f)[0x7fc822d5b91f]
/usr/lib64/libgdal.so(_ZN16OGRDB2DataSource17HasMetadataTablesEv+0xcd)[0x7fc822d5bc3d]
/usr/lib64/libgdal.so(_ZN16OGRDB2DataSource11GetMetadataEPKc+0xa3)[0x7fc822d5c783]
ogrinfo[0x4031e1]
ogrinfo[0x403309]
ogrinfo[0x401e1a]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7fc821d4b640]
ogrinfo[0x403039]

However I can get info on my table when wrapping into VRT and using ogrinfo on it.
I thought the same mechanism is used for querying wrapped sources.


Another question is - why does VRT driver switch a layer to read only mode when using FID tag to specify primary key column?
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: stack smashing when using ogrinfo with DB2 driver

Even Rouault-2

>

> Another question is - why does VRT driver switch a layer to read only mode

> when using FID tag to specify primary key column?

 

I can just answer on that non-DB2 specific part. The reason is that when explicitly setting FID, when you want to update the underlying layer, you'd need to access its real FID, but, in the general case, the exposed FID at the VRT level cannot be matched with the underlying FID.

 

For example imagine you have a CSV file with

 

my_id,foo

10,"bar"

11",baz"

 

For the OGR CSV driver, the FID of this CSV file is implicit. The first record will be FID 1, the next one 2

 

If in your VRT you set <FID>my_id</FID>, then in the OGR VRT layer, you'll have 2 features of FID 10 and 11.

If you do SetFeature(vrt_feature) where vrt_feature.my_id = 11, the VRT driver would have to realize that this vrt_feature.my_id= 11 corresponds to csv_feature.implicit_id = 2. Which he cannot do efficiently (would require a full scan)

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev