GitLab

- explicitly include config.h in these tests
- move helper function only used with USE_SHARED_MEMORY inside the ifdef block

Skip some code if no shared memory support is present.

Use bigger type, check it never overflows.

If we throw an exception from the constructor, destructor is not called.
Call the clean-up manually there, so we don't leak memory.

Only allocate the memory for segment holder in the constructor, set it
in separate method. The allocation might throw.

Conflicts:
	src/lib/datasrc/memory/zone_writer.cc
	src/lib/datasrc/tests/memory/Makefile.am
	src/lib/datasrc/tests/memory/zone_data_updater_unittest.cc
	src/lib/datasrc/tests/memory/zone_finder_unittest.cc

Attempt to write a test that loads a bunch of zones, probably causing a
relocation.

However, it currently crashes and does so before the relocation happens,
which is strange. It does not crash with the local segment, only with
the mapped, which is stranger.

So remove the condition to check it. Keep an assert there, just in case
there was a reason originally, so we know about it.

Store it separately as named address and access it every time, instead
of sneaking into the updater internal.

Just to be sure

Disable tests using the shared memory utilities (eg. mapped segment)
when there's no shared memory support.

Store the named address for the whole lifetime of the zone data updater.
This should be better for performance.

Currently untested, as there's no reasonable way to create a zone table
with mapped segment :-(.

... now that we handle this with an offset_ptr inside setNamedAddress()
itself.

This commit introduces a problem that allMemoryDeallocated() doesn't
work anymore, because the reserved memory is freed only when the segment
is destroyed.

One workaround is to temporarily release and re-reserve this memory in
allMemoryDeallocated(), but that would make it a non-const method.  I
don't see any other clean way of doing this.

the original setup was not really portable and quite dangerous, making
a very large file.

otherwise, subsequent cleanup to be exception safe will cause a crash.
and, if the remap fails simply abort(); there's no hope to recover from
this situation reasonably.  and clarify in shrinkToFit() why it behaves
differently.

I was confused at the time I removed it in #2831.  these were actually
necessary.

We don't attempt to recover in this case.

Also change some error handling to simply asserts.