Skip to content

How to debug ogr2ogr2 (and other C and C packages)

Jump to bottom
rafatower edited this page Dec 19, 2014 · 4 revisions

How to debug ogr2ogr2

Intro

In order to debug a C or C++ program, in general two conditions must be met:

  • The package must contain debugging symbols
  • The code shouldn't be optimized

These imply that a binary package suitable for production won't be in general suitable for debugging.

In this guide I'll describe the process, focusing on ogr2ogr2 binary, but similar steps can be applied to debug any other C or C++ in general.

High level overview

  1. Get the sources
  2. Figure out how to build the binaries
  3. Figure out how to configure the build in order to produce debugging symbols and non-optimized code
  4. Debug a problem: inspect a coredump or trace a live execution with a debugger

Get the sources

There are two options:

The debian source package differs from the source in that it usually contains specific build options and potentially some patches, plus some other information such as dependencies on other packages.

The ogr2ogr2 binary is actually part of the gdal project. You can get the sources from:

(the mirror works just great so most likely you won't need to use svn, commits are cross-referenced)

I forked the gdal project and added the debian stuff in a branch to ease maintenance of the package. You can find the debian source package in github here:

https://github.com/rafatower/gdal/tree/ogr2ogr2

That is probably your best option for ogr2ogr2 particular case.

Get the dependencies

If you use a debian system for building, then the debian source package contains all the information you need to get the dependencies automatically:

sudo apt-get build-dep ogr2ogr2-static-bin

Otherwise, the source code usually contains information about the dependencies in a README or INSTALL file, always worth reading. If you don't have them all, you'll get a failure at compilation time that will hint you about the missing dependency.

Figure out how to build the binaries

From the debian source package

The debian source package will always contain enough information to build the binary package in a reproducible way. You can deduce a lot about how the package is built by taking a look at the debian directory:

$ cd gdal/debian
$ ls -1
changelog # description of different versions of the package
compat 
control # description of source and binary packages, dependencies and other stuff
ogr2ogr2-static-bin.install
rules # <-- build rules
source

You can find more about debian files here: https://www.debian.org/doc/manuals/maint-guide/dreq.en.html

If you have the debian directory then you can use its tools to build the binary package. More on this here: https://github.com/CartoDB/cartodb/wiki/How-to-build-gdal-&-ogr2ogr2

From the vanilla sources

Many, many packages use autoconf & autotools plus make to manage their builds. I won't get into details but essentially:

./configure --help # displays a lot of configuration options
./configure # actually configure sources for build
make # trigger the build

otherwise check the README or INSTALL files.

Configure the build

For our particular case:

./configure --without-ld-shared --disable-shared --enable-static --with-ogdi=no --enable-debug

A bit of an explanation:

  • --without-ld-shared, --disable-shared and --enable-static are required in order to produce a binary that does not depend on shared libraries (namely gdal itself). This was done so that we could use ogr2ogr from trunk (latest version, aka v2) whereas the rest depends on latest stable gdal lib () and coexist in the same machine with no conflicts.
  • --with-ogdi=no Disable OGDI optional support. I seem to remember it broke the build in original debian package.
  • --enable-debug Enable debugging symbols and disable compiler optimizations

Bear in mind these options are very dependent on this particular package. They'll work here and on gdal but not with other packages.

Build the code

make

Make sure gcc is invoked with -g (add debugging information) and without -O2 or -O3 (optimizations disabled).

Install the binary

This is only needed if you need the binary files in the standard path (for instance, if you need to reproduce a scenario that involves an external program calling your binary in the standard installation path).

sudo make install

Trace a live execution with gdb

[ENVVAR=VALUE] gdb --args ogr2ogr2 [OPTIONAL_ARGS]

E.g:

OSM_USE_CUSTOM_INDEXING=NO PG_USE_COPY=YES PGCLIENTENCODING=ISO-8859-1 \
gdb --args \
  /usr/bin/ogr2ogr2 \
    -f PostgreSQL -oo AUTODETECT_TYPE=YES -oo QUOTED_FIELDS_AS_STRING=NO \
    PG:"host=development.localhost.lan port=5432 user=development_cartodb_user_fe3b850a-01c0-48f9-8a26-a82f09e9b53f dbname=cartodb_dev_user_fe3b850a-01c0-48f9-8a26-a82f09e9b53f_db password=cb8162e697b1240341a798dcdb89037bd8ef9c57development_cartodb_user_fe3b850a-01c0-48f9-8a26-a82f09e9b53f" \
    -lco DIM=2 -lco PRECISION=NO /tmp/imports/20141209-15448-1963j25/imapdata_user.csv  \
    -nln cdb_importer.importer_826ae8187fc011e4bf6b5e0004719e63 -nlt PROMOTE_TO_MULTI

A good gdb guide: http://www.yolinux.com/TUTORIALS/GDB-Commands.html

Debug a coredump

A core dump is an image of the process's memory at the time it crashed. You need to enable them in your system or otherwise they won't be generated. They are in general disabled in production.

Enable core dumps

TODO

Open core file

TODO

Clone this wiki locally