Overpass API developpement

["Christian Müller" <>]

Hi Igor,

 

 

the gory details are:

 

- recompile the program update_database to contain debugging symbols (-ggdb switch if you compile with gcc, you might also have to disable optimization flags, i.e. no "-O2" or "-O3" flags

 

- after you have ensured this, you may run "update_database" with the gnu debugger (CLI programm called "gdb", but there are GUI frontends available also)

 

- once gdb has loaded your segfaulting program, you can "start" or "run" it and then "backtrace" it, once the error has occured

 

-> the backtrace will give you detailed information what function of "update_databases" ran, when the segfault occured and you can try to bugfix the source with this information

 

If update_database creates multiple threads you may have to select the segfaulting thread first to get a decent backtrace.  Read https://sourceware.org/gdb/onlinedocs/gdb/Threads.html for more information on this.

 

 

Also note that segfaults may produce a file "coredump.bin" that is loadable and interpretable by gdb.  But if the program producing the coredump was compiled without debugging symbols, then you probably won't get much out of it.  A decent backtrace should be one with pointers to line numbers into the source code of the program and its function names in plain english.

 

 

I have not looked too much into overpass source code, so I will not be of much help to you making guesses and assumptions about where the error may stem from, but this rough outline above is given to the best of my knowledge and will eventually lead you to success, if you have persistence, time and resources to further look into it.

 

 

Regards,

Christian

 

Gesendet: Sonntag, 30. Juli 2017 um 07:29 Uhr
Von: "Igor Brejc" <>
An: 
Betreff: Re: [overpass] Segmentation fault

Some more information: I've reinstalled Ubuntu (using XUbuntu 64-bit desktop image now), cloned the database and started the minute diff using the command

 

osm-3s_v0.7.54/bin/fetch_osc_and_apply.sh http://planet.osm.org/replication/minute/

 

... and again, after some 10-20 seconds of work, I get the segmentation fault:

 

osm-3s_v0.7.54/bin/fetch_osc_and_apply.sh: line 57: 18050 Done                    cat $TMP_DIFF_UNCOMPRESS

     18051 Segmentation fault      (core dumped) | $EXEC_DIR/update_database $2 >> /dev/null 2>&1

 

 

On Sat, Jul 29, 2017 at 10:13 AM, Igor Brejc <> wrote:

Answering this in a separate thread...

 

On Sat, Jul 29, 2017 at 12:13 AM, mmd <> wrote:

> 3) Both with a) and b) variant I get this kind of error:
>
>     ./apply_osc_to_db.sh: line 117: 28219 Segmentation fault      (core
>     dumped) ./update_from_dir --osc-dir=$1 --version=$DATA_VERSION $META
>     --flush-size=0
>     + EXITCODE=139

Can you provide some more details on this, e.g. dmesg output, stack
traces?

 

I've already re-cloned the database, but I will try to reproduce this error by applying diffs once again. Can you give me some basic instructions on what logs to look at or what commands to execute to get more diagnostic information about this segmentation fault?

 

Cheers,

Igor