Skip to Content.
Sympa Menu

overpass - Re: [overpass] Segmentation fault

Subject: Overpass API developpement

List archive

Re: [overpass] Segmentation fault


Chronological Thread 
  • From: Igor Brejc <>
  • To:
  • Subject: Re: [overpass] Segmentation fault
  • Date: Sun, 30 Jul 2017 19:42:33 +0200

Hi Roland,

First trying out your instructions. Here are the results:
  • "$FLAGS" seems to be empty, the modified script returns "flags: "
  • I ran "run </tmp/crash_input.osc" in gdb and got this:
Starting program: /home/igor/overpass/osm-3s_v0.7.54/bin/update_database </tmp/crash_input.osc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Reading XML file ... finished reading nodes. Flushing to database ...... done.
Reading XML file ... finished reading ways. Flushing to database ...... done.
Reading XML file ... finished reading relations. Flushing to database ....... done.

Program received signal SIGSEGV, Segmentation fault.
File_Blocks_Index<Uint32_Index>::~File_Blocks_Index (this=0x780af0, __in_chrg=<optimized out>)
    at overpass_api/core/../../template_db/file_blocks_index.h:303
303       for (typename std::list< File_Block_Index_Entry< TIndex > >::const_iterator

Result of "backtrace full":
(gdb) backtrace full
#0  std::_List_const_iterator<File_Block_Index_Entry<Uint32_Index> >::operator++ (this=<optimized out>)
    at /usr/include/c++/5/bits/stl_list.h:244
No locals.
#1  File_Blocks_Index<Uint32_Index>::~File_Blocks_Index (this=0x780af0, __in_chrg=<optimized out>)
    at overpass_api/core/../../template_db/file_blocks_index.h:303
        it = <error reading variable it (Cannot access memory at address 0x10)>
        index_size = 24
        dest_file = {fd_ = -8048, name = ""}
        it_ptr = <optimized out>
        pos = 8
        index_buf = <optimized out>
        void_index_buf = <optimized out>
#2  0x0000000000528469 in File_Blocks_Index<Uint32_Index>::~File_Blocks_Index (this=0x780af0, __in_chrg=<optimized out>)
    at overpass_api/core/../../template_db/file_blocks_index.h:349
No locals.
#3  0x0000000000408d77 in Nonsynced_Transaction::flush (this=0x779280)
    at overpass_api/osm-backend/../../template_db/transaction.h:83
        it = {first = , second = }
#4  Nonsynced_Transaction::~Nonsynced_Transaction (this=0x779280, __in_chrg=<optimized out>)
    at overpass_api/osm-backend/../../template_db/transaction.h:75
No locals.
#5  0x00000000004fcb2a in Nonsynced_Transaction::~Nonsynced_Transaction (this=0x779280, __in_chrg=<optimized out>)
    at overpass_api/osm-backend/../../template_db/transaction.h:76
No locals.
#6  Osm_Updater::~Osm_Updater (this=0x7fffffffe350, __in_chrg=<optimized out>)
    at overpass_api/osm-backend/osm_updater.cc:613
        logger = {logfile_full_name = ""}
#7  0x00000000004051a5 in main (argc=<optimized out>, argv=0x7fffffffe4c8)
    at overpass_api/osm-backend/update_database.cc:128
        osm_updater = {transaction = 0x779280, dispatcher_client = 0x779030, node_updater_ = 0x779360,
          way_updater_ = 0x779510, relation_updater_ = 0x779690, db_dir_ = "", meta = only_data}
        db_dir = ""
        data_version = ""
        transactional = <optimized out>
        meta = <optimized out>
        abort = <optimized out>
        flush_limit = <optimized out>
        argpos = <optimized out>

If you need the contents of crash_input.osc, I can send it to you. Let me know if I can do anything more, I'll leave gdb running.

Thank you,
Igor

On Sun, Jul 30, 2017 at 12:39 PM, Roland Olbricht <> wrote:
Hello Igor,

thank you for sharing the crash information.

Please change line 80 of src/bin/fetch_osc_and_apply.sh from

cat $TMP_DIFF_UNCOMPRESS | $EXEC_DIR/update_database $2 >> /dev/null 2>&1

to

cat $TMP_DIFF_UNCOMPRESS | $EXEC_DIR/update_database $2

(drop everything after $2)

That way, we should see whether "update_database" had written some error messages before crashing and the rough location where it crashes.

You need to remake the binaries afterwards. Assuming you are running a release from https://dev.overpass-api.de/releases/, this means the command:

make install

Second step of escalation is to recompile with debugging symbols, then
running the single command that crashes:

First:

change line 80 of src/bin/fetch_osc_and_apply.sh from

cat $TMP_DIFF_UNCOMPRESS | $EXEC_DIR/update_database $2

to

cat $TMP_DIFF_UNCOMPRESS >/tmp/crash_input.osc; echo "flags: $2"; exit 0


Second:

make clean
make -j 4 CXXFLAGS="-O2 -ggdb" install


Third:

Re-run, then run

gdb bin/update_database

Then, inside gdb run (with $FLAGS replaced with the flags printed in the previous step:

run $FLAGS </tmp/crash_input.osc

This should stop at the single line where the software really crashes.

By the way: I did never manage to get useful information out of a core dump. I we get forward that way, I would like to know how because that might simplify future post-mortem analysis.

I'm sorry for the necessary effort.


Best regards,

Roland




Archive powered by MHonArc 2.6.19+.

Top of Page