Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bus Error in wkb.hpp #806

Closed
iantfox opened this issue Dec 23, 2017 · 15 comments
Closed

Bus Error in wkb.hpp #806

iantfox opened this issue Dec 23, 2017 · 15 comments

Comments

@iantfox
Copy link

iantfox commented Dec 23, 2017

I keep getting a bus error trying to run osm2pgsql. I've tried 2 separate PBF files but they both failed at the same place. I'm running osm2pgsql version 0.95.0-dev on a Raspberry Pi running Raspbian Stretch.

The osm2pgsql call is:

osm2pgsql -d gis -r pbf --create --slim  -G --hstore --tag-transform-script ~/src/openstreetmap-carto/openstreetmap-carto.lua --number-processes 4 -S ~/src/openstreetmap-carto/openstreetmap-carto.style /media/pi/Rasp_Thumb/SLC.pdf

Does anyone have any thoughts as to why this is happening? Thanks in advance

GDB call stack output:

#0  ewkb::parser_t::get_ring_area (this=<optimized out>)
    at /home/pi/src/osm2pgsql/wkb.hpp:339
#1  ewkb::parser_t::get_polygon_area<osmium::geom::IdentityProjection> (
    proj=0x0, this=<optimized out>) at /home/pi/src/osm2pgsql/wkb.hpp:297
#2  ewkb::parser_t::get_area<osmium::geom::IdentityProjection> (proj=0x0, 
    this=<optimized out>) at /home/pi/src/osm2pgsql/wkb.hpp:275
#3  output_pgsql_t::pgsql_process_relation (this=0x76b73b44 <_IO_strn_jumps>, 
    rel=..., pending=<optimized out>)
    at /home/pi/src/osm2pgsql/output-pgsql.cpp:379
#4  0x0005f594 in osmdata_t::relation_add (this=<optimized out>, rel=...)
    at /home/pi/src/osm2pgsql/osmdata.cpp:65
#5  0x00070cac in parse_osmium_t::relation (this=this@entry=0x7eb7ed68, 
    rel=...) at /home/pi/src/osm2pgsql/parse-osmium.cpp:185
#6  0x0007152c in osmium::detail::apply_item_impl<parse_osmium_t&, osmium::memory::Item> (handler=..., item=...)
    at /home/pi/src/osm2pgsql/contrib/libosmium/osmium/visitor.hpp:68
#7  osmium::apply_item<osmium::memory::Item, parse_osmium_t&> (item=...)
    at /home/pi/src/osm2pgsql/contrib/libosmium/osmium/visitor.hpp:206
#8  osmium::apply<osmium::io::InputIterator<osmium::io::Reader, osmium::memory::Item>, parse_osmium_t&> (end=..., it=...)
    at /home/pi/src/osm2pgsql/contrib/libosmium/osmium/visitor.hpp:220
#9  osmium::apply<osmium::io::Reader, parse_osmium_t&> (c=...)
    at /home/pi/src/osm2pgsql/contrib/libosmium/osmium/visitor.hpp:227
#10 parse_osmium_t::stream_file (this=0x7eb7ed68, this@entry=0x7eb7ed60, 
    filename="\020\000\000\000\201", '\000' <repeats 75 times>, "\b\020\000\000`hD\001\002", '\000' <repeats 11 times>, "pgD\001\061", '\000' <repeats 27 times>, "\021\000\000\000(\027F\001\000\027F\001\020\000\000\000\201\000\000\000AuthorityKeyIdentifier", '\000' <repeats 26 times>..., fmt="pbf")
    at /home/pi/src/osm2pgsql/parse-osmium.cpp:128
#11 0x000537b0 in main (argc=<optimized out>, argv=<optimized out>)
    at /home/pi/src/osm2pgsql/osm2pgsql.cpp:86

More in depth near the failure point:

#0  ewkb::parser_t::get_ring_area (this=<optimized out>)
    at /home/pi/src/osm2pgsql/wkb.hpp:339
        i = <optimized out>
        num_pts = 87
        total = 0
        prev = <optimized out>
#1  ewkb::parser_t::get_polygon_area<osmium::geom::IdentityProjection> (
    proj=0x0, this=<optimized out>) at /home/pi/src/osm2pgsql/wkb.hpp:297
        num_rings = 2
        total = <optimized out>
#2  ewkb::parser_t::get_area<osmium::geom::IdentityProjection> (proj=0x0, 
    this=<optimized out>) at /home/pi/src/osm2pgsql/wkb.hpp:275
        total = 0
        type = 3
@SomeoneElseOSM
Copy link

You might be better just on the mailing list https://lists.openstreetmap.org/pipermail/tile-serving/ rather than here as well, but there's a bit of info missing:

  • We don't know where the osm2pgsql came from. Did you build it, or is it part of the distribution, or is it from somewhere else?
  • What version is it?
  • Is it fully 64-bit aware? I'm guessing that the answer is "yes" here, but just checking...
  • How big are the .pbfs?
  • How much memory does the system have?
  • The command line seems a bit odd. You're using 4 threads, not specifying how much cache to use and seem to be specifying a .pdf (as in an Adobe Acrobat Reader document) as the input file. I'm guessing the latter is just a typo, but again just in case...
  • Did the system run out of memory at the time that it failed?

@iantfox
Copy link
Author

iantfox commented Dec 23, 2017

  • My copy of osm2pgsql came from the raspberrypi.org mirror. Where that came from, I'm not sure.
  • I'm using version 0.95.0-dev. However, it says version 0.92.0+ds-2 in apt
  • Not sure if about 64-bit aware. Where would I check that?
  • PBF files are small. My first was 17MB, and my second was 700KB.
  • Memory is 1GB, ~700 of which are available. I also have a swap set up with 3GB.
  • Caching was set to run from anywhere from 800MB to 100MB. All attempts failed at the same spot.
  • As far as the "pdf", yes, it was a typo.
  • I originally had osm2pgsql telling me that I was running out of memory, but after turning down the cache size, I did not have that problem. I was also watching top and saw minimal memory usage.

@iantfox
Copy link
Author

iantfox commented Dec 23, 2017

I'm going to uninstall my copy and install from this project to see if that makes a difference.

@iantfox
Copy link
Author

iantfox commented Dec 23, 2017

Alright, yeah, I got the same problem. I used:
git clone git://github.com/openstreetmap/osm2pgsql.git

Here is it running:

$ osm2pgsql -d gis --create --slim  -r pbf -G --hstore --tag-transform-script ~/src/openstreetmap-carto/openstreetmap-carto.lua --number-processes 4 -S ~/src/openstreetmap-carto/openstreetmap-carto.style /media/pi/Rasp_Thumb/SLC.pdf 
osm2pgsql version 0.95.0-dev (64 bit id space)

Using lua based tag processing pipeline with script /home/pi/src/openstreetmap-carto/openstreetmap-carto.lua
Using projection SRS 3857 (Spherical Mercator)
Setting up table: planet_osm_point
Setting up table: planet_osm_line
Setting up table: planet_osm_polygon
Setting up table: planet_osm_roads
Allocating memory for sparse node cache
Node-cache: cache=800MB, maxblocks=12800*65536, allocation method=9
Mid: pgsql, cache=800
Setting up table: planet_osm_nodes
Setting up table: planet_osm_ways
Setting up table: planet_osm_rels

Reading in file: /media/pi/Rasp_Thumb/SLC.pdf
Using PBF parser.
Processing: Node(84k 28.1k/s) Way(13k 2.33k/s) Relation(10 10.00/s)Bus error

@SomeoneElseOSM
Copy link

As I understand it "bus error" means something has gone very wrong at a very low level (word alignment - see gperftools/gperftools#736 ). Unless someone's seen the same problem on the same platform, I'm not sure anyone will be able to help here. Maybe ask around the various ARM/Pi forums?

@iantfox
Copy link
Author

iantfox commented Dec 24, 2017

Huh, interesting. I guess it makes sense that this could be an ARM only issue. Yeah, I'll do some more research but it seems like I'm sunk trying to get it to work.

@pnorman
Copy link
Collaborator

pnorman commented Dec 30, 2017

I also suspect something ARM-specific.

Just to simplify this down to a minimal command, can you verify that the error still occurs with

osm2pgsql -d gis --style default.style --number-processes 1 tests/liechtenstein-2013-08-03.osm.pbf

default.style and tests/liechtenstein-2013-08-03.osm.pbf are part of the git repo.

@mmd-osm
Copy link
Contributor

mmd-osm commented Dec 30, 2017

I had similar issues with Overpass API on ARM (Raspberry Pi 2) (see wiki) due to unaligned memory accesses. Some optimization levels like -O2 or -O3 may generate instructions that fail during runtime. Maybe try a more conservative optimization level.

I would also recommend to reduce the number of parallel processes to maybe 1-2 to see if this makes any difference (currently --number-processes 4). My raspberry was sometimes unstable with lots of CPU bound activities running on all cores.

@iantfox
Copy link
Author

iantfox commented Jan 6, 2018

Sorry for the delayed response. I did the run as prescribed and ran into a bus error again.

osm2pgsql -d gis --style ~/src/default.style --number-processes 1 /media/pi/Rasp_Thumb/liechtenstein-2013-08-03.osm.pbf
osm2pgsql version 0.95.0-dev (64 bit id space)


!! You are running this on 32bit system, so at most
!! 3GB of RAM can be used. If you encounter unexpected
!! exceptions during import, you should try running in slim
!! mode using parameter -s.
Using built-in tag processing pipeline
Using projection SRS 3857 (Spherical Mercator)
Setting up table: planet_osm_point
Setting up table: planet_osm_line
Setting up table: planet_osm_polygon
Setting up table: planet_osm_roads
Allocating memory for sparse node cache
Node-cache: cache=800MB, maxblocks=12800*65536, allocation method=1

Reading in file: /media/pi/Rasp_Thumb/liechtenstein-2013-08-03.osm.pbf
Using PBF parser.
Processing: Node(65k 65.7k/s) Way(1k 1.00k/s) Relation(0 0.00/s)Bus error

Let me know if you want me to run anything else.

lonvia added a commit to lonvia/osm2pgsql that referenced this issue Jan 6, 2018
lonvia added a commit to lonvia/osm2pgsql that referenced this issue Jan 6, 2018
@lonvia
Copy link
Collaborator

lonvia commented Jan 6, 2018

I've pushed a potential fix now in #808 but couldn't really test it as my Rhaspi seems to be quite happy with unaligned memory accesses. @iantfox could you please check if the PR fixes the issue for you?

@mmd-osm
Copy link
Contributor

mmd-osm commented Jan 6, 2018

Patch looks good. Here's a log on Raspberry Pi 2

Without #808

 gdb build/osm2pgsql 
GNU gdb (Raspbian 7.7.1+dfsg-5+rpi1) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build/osm2pgsql...done.
(gdb) handle SIGILL nostop
Signal        Stop	Print	Pass to program	Description
SIGILL        No	Yes	Yes		Illegal instruction
(gdb) handle SIGINT nostop
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) y
Signal        Stop	Print	Pass to program	Description
SIGINT        No	Yes	No		Interrupt
(gdb) r -d gis --style default.style --number-processes 1 `pwd`/tests/liechtenstein-2013-08-03.osm.pbf
Starting program: /home/pi/osm2pgsql/build/osm2pgsql -d gis --style default.style --number-processes 1 `pwd`/tests/liechtenstein-2013-08-03.osm.pbf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Cannot access memory at address 0x0

Program received signal SIGILL, Illegal instruction.
osm2pgsql version 0.95.0-dev (64 bit id space)


!! You are running this on 32bit system, so at most
!! 3GB of RAM can be used. If you encounter unexpected
!! exceptions during import, you should try running in slim
!! mode using parameter -s.
Using built-in tag processing pipeline
Using projection SRS 3857 (Spherical Mercator)
Setting up table: planet_osm_point
Setting up table: planet_osm_line
Setting up table: planet_osm_polygon
Setting up table: planet_osm_roads
Allocating memory for sparse node cache
Node-cache: cache=800MB, maxblocks=12800*65536, allocation method=1

Reading in file: /home/pi/osm2pgsql/tests/liechtenstein-2013-08-03.osm.pbf
Using PBF parser.
[New Thread 0x42464430 (LWP 1633)]
[New Thread 0x419fe430 (LWP 1634)]
[Thread 0x42464430 (LWP 1633) exited]
[New Thread 0x411fe430 (LWP 1635)]
[New Thread 0x409fe430 (LWP 1636)]
[Thread 0x409fe430 (LWP 1636) exited]
Processing: Node(65k 65.7k/s) Way(3k 3.00k/s) Relation(0 0.00/s)
Program received signal SIGBUS, Bus error.
read_point (this=0x7effeed4, this@entry=0x39175d) at /home/pi/osm2pgsql/wkb.hpp:260
260	        auto y = read_data<double>();
(gdb) bt
#0  read_point (this=0x7effeed4, this@entry=0x39175d) at /home/pi/osm2pgsql/wkb.hpp:260
#1  ewkb::parser_t::get_ring_area (this=this@entry=0x7effeed4) at /home/pi/osm2pgsql/wkb.hpp:338
#2  0x000d831c in get_polygon_area<osmium::geom::IdentityProjection> (proj=0x0, this=0x7effeed4) at /home/pi/osm2pgsql/wkb.hpp:297
#3  ewkb::parser_t::get_area<osmium::geom::IdentityProjection> (this=0x7effeed4, proj=0x0) at /home/pi/osm2pgsql/wkb.hpp:275
#4  0x000d6088 in output_pgsql_t::pgsql_process_relation (this=0x1411f8, rel=..., pending=<optimized out>) at /home/pi/osm2pgsql/output-pgsql.cpp:382
#5  0x0007ea60 in osmdata_t::relation_add (this=<optimized out>, rel=...) at /home/pi/osm2pgsql/osmdata.cpp:65
#6  0x00097f2c in parse_osmium_t::relation (this=this@entry=0x7efff300, rel=...) at /home/pi/osm2pgsql/parse-osmium.cpp:185
#7  0x00098770 in apply_item_impl<parse_osmium_t&, osmium::memory::Item> (handler=..., item=...) at /home/pi/osm2pgsql/contrib/libosmium/osmium/visitor.hpp:68
#8  apply_item<osmium::memory::Item, parse_osmium_t&> (item=...) at /home/pi/osm2pgsql/contrib/libosmium/osmium/visitor.hpp:206
#9  apply<osmium::io::InputIterator<osmium::io::Reader>, parse_osmium_t&> (end=..., it=...) at /home/pi/osm2pgsql/contrib/libosmium/osmium/visitor.hpp:220
#10 apply<osmium::io::Reader, parse_osmium_t&> (c=...) at /home/pi/osm2pgsql/contrib/libosmium/osmium/visitor.hpp:227
#11 parse_osmium_t::stream_file (this=0x7efff300, this@entry=0x7efff2f8, filename="", fmt="auto") at /home/pi/osm2pgsql/parse-osmium.cpp:128
#12 0x000714b4 in main (argc=<optimized out>, argv=<optimized out>) at /home/pi/osm2pgsql/osm2pgsql.cpp:86
(gdb) disass
Dump of assembler code for function ewkb::parser_t::get_ring_area(osmium::geom::IdentityProjection*):
   0x000d7e88 <+0>:	ldm	r0, {r2, r12}
   0x000d7e8c <+4>:	push	{r4, r5, lr}
   0x000d7e90 <+8>:	add	lr, r12, #4
   0x000d7e94 <+12>:	str	lr, [r0, #4]
   0x000d7e98 <+16>:	add	r1, r12, #12
   0x000d7e9c <+20>:	ldr	r3, [r2, r12]
   0x000d7ea0 <+24>:	add	lr, r2, lr
   0x000d7ea4 <+28>:	add	r5, r2, r1
   0x000d7ea8 <+32>:	add	r4, r12, #20
   0x000d7eac <+36>:	cmp	r3, #1
   0x000d7eb0 <+40>:	vldr	d3, [lr]
=> 0x000d7eb4 <+44>:	vldr	d4, [r5]
   0x000d7eb8 <+48>:	str	r4, [r0, #4]
   0x000d7ebc <+52>:	bls	0xd7f20 <ewkb::parser_t::get_ring_area(osmium::geom::IdentityProjection*)+152>
   0x000d7ec0 <+56>:	lsl	lr, r3, #4
   0x000d7ec4 <+60>:	vldr	d0, [pc, #92]	; 0xd7f28 <ewkb::parser_t::get_ring_area(osmium::geom::IdentityProjection*)+160>
   0x000d7ec8 <+64>:	add	r1, r1, lr
   0x000d7ecc <+68>:	add	r3, r12, #28
   0x000d7ed0 <+72>:	add	r1, r2, r1
   0x000d7ed4 <+76>:	add	r3, r2, r3
   0x000d7ed8 <+80>:	vldr	d6, [r3, #-8]
   0x000d7edc <+84>:	mov	r2, r3
   0x000d7ee0 <+88>:	add	r3, r3, #16
   0x000d7ee4 <+92>:	vldr	d5, [r2]
   0x000d7ee8 <+96>:	vmul.f64	d7, d4, d6
   0x000d7eec <+100>:	cmp	r3, r1
   0x000d7ef0 <+104>:	vmov.f64	d4, d5
   0x000d7ef4 <+108>:	vnmls.f64	d7, d3, d5
   0x000d7ef8 <+112>:	vmov.f64	d3, d6
---Type <return> to continue, or q <return> to quit---
   0x000d7efc <+116>:	vadd.f64	d0, d0, d7
   0x000d7f00 <+120>:	bne	0xd7ed8 <ewkb::parser_t::get_ring_area(osmium::geom::IdentityProjection*)+80>
   0x000d7f04 <+124>:	vldr	d7, [pc, #36]	; 0xd7f30 <ewkb::parser_t::get_ring_area(osmium::geom::IdentityProjection*)+168>
   0x000d7f08 <+128>:	vabs.f64	d0, d0
   0x000d7f0c <+132>:	add	r12, r12, lr
   0x000d7f10 <+136>:	add	r12, r12, #4
   0x000d7f14 <+140>:	str	r12, [r0, #4]
   0x000d7f18 <+144>:	vmul.f64	d0, d0, d7
   0x000d7f1c <+148>:	pop	{r4, r5, pc}
   0x000d7f20 <+152>:	vldr	d0, [pc]	; 0xd7f28 <ewkb::parser_t::get_ring_area(osmium::geom::IdentityProjection*)+160>
   0x000d7f24 <+156>:	pop	{r4, r5, pc}
   0x000d7f28 <+160>:	andeq	r0, r0, r0
   0x000d7f2c <+164>:	andeq	r0, r0, r0
   0x000d7f30 <+168>:	andeq	r0, r0, r0
   0x000d7f34 <+172>:	svccc	0x00e00000
End of assembler dump.
(gdb) 

With #808

build/osm2pgsql -d gis --style default.style --number-processes 1 `pwd`/tests/liechtenstein-2013-08-03.osm.pbf
osm2pgsql version 0.95.0-dev (64 bit id space)


!! You are running this on 32bit system, so at most
!! 3GB of RAM can be used. If you encounter unexpected
!! exceptions during import, you should try running in slim
!! mode using parameter -s.
Using built-in tag processing pipeline
Using projection SRS 3857 (Spherical Mercator)
Setting up table: planet_osm_point
Setting up table: planet_osm_line
Setting up table: planet_osm_polygon
Setting up table: planet_osm_roads
Allocating memory for sparse node cache
Node-cache: cache=800MB, maxblocks=12800*65536, allocation method=1

Reading in file: /home/pi/osm2pgsql/tests/liechtenstein-2013-08-03.osm.pbf
Using PBF parser.
Processing: Node(65k 65.7k/s) Way(4k 4.00k/s) Relation(0 0.00/s)  parse time: 1s
Node stats: total(65733), max(65733) in 0s
Way stats: total(7121), max(7121) in 1s
Relation stats: total(113), max(113) in 0s
Committing transaction for planet_osm_point
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Committing transaction for planet_osm_roads
Using built-in tag processing pipeline

Going over pending ways...
	4162 ways are pending

Using 1 helper-processes
Finished processing 4162 ways in 1 s

4162 Pending ways took 1s at a rate of 4162.00/s
Committing transaction for planet_osm_point
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Committing transaction for planet_osm_roads

Going over pending relations...
	0 relations are pending

Using 1 helper-processes
Finished processing 0 relations in 0 s

Committing transaction for planet_osm_point
WARNING:  there is no transaction in progress
Committing transaction for planet_osm_line
WARNING:  there is no transaction in progress
Committing transaction for planet_osm_polygon
WARNING:  there is no transaction in progress
Committing transaction for planet_osm_roads
WARNING:  there is no transaction in progress
Sorting data and creating indexes for planet_osm_point
Sorting data and creating indexes for planet_osm_line
Sorting data and creating indexes for planet_osm_roads
Sorting data and creating indexes for planet_osm_polygon
Copying planet_osm_point to cluster by geometry finished
Creating geometry index on planet_osm_point
Creating indexes on planet_osm_point finished
All indexes on planet_osm_point created in 2s
Completed planet_osm_point
Copying planet_osm_roads to cluster by geometry finished
Creating geometry index on planet_osm_roads
Copying planet_osm_polygon to cluster by geometry finished
Creating geometry index on planet_osm_polygon
Copying planet_osm_line to cluster by geometry finished
Creating geometry index on planet_osm_line
Creating indexes on planet_osm_roads finished
All indexes on planet_osm_roads created in 3s
Completed planet_osm_roads
Creating indexes on planet_osm_line finished
Creating indexes on planet_osm_polygon finished
All indexes on planet_osm_polygon created in 4s
Completed planet_osm_polygon
All indexes on planet_osm_line created in 4s
Completed planet_osm_line
node cache: stored: 65733(100.00%), storage efficiency: 50.00% (dense blocks: 0, sparse nodes: 65733), hit rate: 100.00%

Osm2pgsql took 7s overall

@lonvia
Copy link
Collaborator

lonvia commented Jan 6, 2018

SIGILL is slightly odd. That rather sounds like the compiler has produced code that is unsuitable for your platform.

@mmd-osm
Copy link
Contributor

mmd-osm commented Jan 6, 2018 via email

@iantfox
Copy link
Author

iantfox commented Jan 6, 2018

@lonvia, that seemed to have done it, so thank you!

osm2pgsql -d gis --style ~/src/default.style --number-processes 1 /media/pi/Rasp_Thumb/liechtenstein-2013-08-03.osm.pbf
osm2pgsql version 0.95.0-dev (64 bit id space)


!! You are running this on 32bit system, so at most
!! 3GB of RAM can be used. If you encounter unexpected
!! exceptions during import, you should try running in slim
!! mode using parameter -s.
Using built-in tag processing pipeline
Using projection SRS 3857 (Spherical Mercator)
Setting up table: planet_osm_point
Setting up table: planet_osm_line
Setting up table: planet_osm_polygon
Setting up table: planet_osm_roads
Allocating memory for sparse node cache
Node-cache: cache=800MB, maxblocks=12800*65536, allocation method=1

Reading in file: /media/pi/Rasp_Thumb/liechtenstein-2013-08-03.osm.pbf
Using PBF parser.
Processing: Node(60k 60.0k/s) Way(0k 0.00k/s) Relation(0 0.00/s)  parse time: 1s
Node stats: total(65733), max(65733) in 1s
Way stats: total(7121), max(7121) in 0s
Relation stats: total(113), max(113) in 0s
Committing transaction for planet_osm_point
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Committing transaction for planet_osm_roads
Using built-in tag processing pipeline

Going over pending ways...
        4162 ways are pending

Using 1 helper-processes
Finished processing 4162 ways in 1 s

4162 Pending ways took 1s at a rate of 4162.00/s
Committing transaction for planet_osm_point
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Committing transaction for planet_osm_roads

Going over pending relations...
        0 relations are pending

Using 1 helper-processes
Finished processing 0 relations in 0 s

Committing transaction for planet_osm_point
WARNING:  there is no transaction in progress
Committing transaction for planet_osm_line
WARNING:  there is no transaction in progress
Committing transaction for planet_osm_polygon
WARNING:  there is no transaction in progress
Committing transaction for planet_osm_roads
WARNING:  there is no transaction in progress
Sorting data and creating indexes for planet_osm_point
Sorting data and creating indexes for planet_osm_line
Sorting data and creating indexes for planet_osm_polygon
node cache: stored: 65733(100.00%), storage efficiency: 50.00% (dense blocks: 0, sparse nodes: 65733), hit rate: 100.00%
Sorting data and creating indexes for planet_osm_roads
Copying planet_osm_point to cluster by geometry finished
Creating geometry index on planet_osm_point
Copying planet_osm_roads to cluster by geometry finished
Creating geometry index on planet_osm_roads
Creating indexes on planet_osm_roads finished
Creating indexes on planet_osm_point finished
All indexes on planet_osm_roads created in 0s
Completed planet_osm_roads
All indexes on planet_osm_point created in 0s
Completed planet_osm_point
Copying planet_osm_line to cluster by geometry finished
Creating geometry index on planet_osm_line
Creating indexes on planet_osm_line finished
All indexes on planet_osm_line created in 1s
Completed planet_osm_line
Copying planet_osm_polygon to cluster by geometry finished
Creating geometry index on planet_osm_polygon
Creating indexes on planet_osm_polygon finished
All indexes on planet_osm_polygon created in 3s
Completed planet_osm_polygon

Osm2pgsql took 9s overall

tomhughes pushed a commit to tomhughes/osm2pgsql that referenced this issue Feb 12, 2020
@kimmobrunfeldt
Copy link

This is an old thread but since this was one of the only Bus error issues, I wanted to give my additions. In my case, the issue was simply running out of disk space inside a Docker container. I'm importing a single country with the following command:

osm2pgsql -U osm -d osm -H localhost -P 5432 --create --slim \
      --flat-nodes osm2pgsql_flat_nodes.bin \
      --cache 4096 --number-processes 1 --hstore \
      --disable-parallel-indexing \
      --style openstreetmap-carto.style --multi-geometry \
       europe-finland.osm.pbf

I'm running the import inside Docker, Macbook as the host. I gave Docker for Mac 8 cores, 8GB RAM, and 128GB disk space and the importing seems to work now. Having 64GB disk space was not enough.

Hope this helps someone else later!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants