Found that on 19.02.2020 APT repositories with packages
for Ubuntu 18.10 Cosmic were removed from Ubuntu archive:

 E: The repository 'http://security.ubuntu.com/ubuntu cosmic-security Release' does not have a Release file.
 E: The repository 'http://archive.ubuntu.com/ubuntu cosmic Release' does not have a Release file.
 E: The repository 'http://archive.ubuntu.com/ubuntu cosmic-updates Release' does not have a Release file.
 E: The repository 'http://archive.ubuntu.com/ubuntu cosmic-backports Release' does not have a Release file.

Also found the half a year old message about Ubuntu 18.10
Cosmic EOL:
 https://fridge.ubuntu.com/2019/07/19/ubuntu-18-10-cosmic-cuttlefish-end-of-life-reached-on-july-18-2019/

Removed the Ubuntu 18.10 Cosmic from gitlab-ci and
travis-ci testings.

(cherry picked from commit 961e8c5f)

The server used to crash when any option argument was passed with
a value concatenated to it, like this: '-lvalue', '-evalue'
instead of '-l value' and '-e value'.

However this is a valid way of writing values, and it should not
have crashed regardless of its validity.

The bug was in usage of 'optind' global variable from getopt()
function family. It is not supposed to be used for getting an
option's value. It points to a next argv to parse. Next argv !=
value of current argv, like it was with '-lvalue' and '-evalue'.

For getting a current value there is a variable 'optarg'.

Closes #4775

(cherry picked from commit 29cfd564)

os.setenv() and os.environ() are Lua API for

    extern char **environ;
    int setenv();

The Open Group standardized access points for environment
variables. But there is no a word about that environ never
changes. Programs can't relay on that. For example, addition of
a new variable may cause realloc of the whole environ array, and
therefore change of its pointer value. That was exactly the case
in os.environ() - it was using value of environ array remembered
when Tarantool started.

And os.setenv() could realloc the array and turn the saved pointer
into garbage.

Closes #4733

(cherry picked from commit 954d4bdc)

Revert "build: introduce LUAJIT_ENABLE_PAIRSMM flag"

Related to #4770

(cherry picked from commit 04dd6f43)

After 7fd6c809
(buffer: port static allocator to Lua) uri started to use
static_allocator - cyclic buffer that also is used in
several modules.

However situation when uri.format output is zero-length
string was not handled properly and ffi.string could
return data that was previously written in static buffer
because use as string terminator the first zero byte.

To prevent such situation let's pass result length explicitly.

Closes #4779

(cherry picked from commit 57f6fc93)

When json.decode is used with 2 arguments, 2nd argument seeps out to the
json configuration of the instance. Moreover, due to current
serializer.cfg implementation it remains invisible while checking
settings using json.cfg table.

This fixes commit 6508ddb7 ('json: fix
stack-use-after-scope in json_decode()').

Closes #4761

(cherry picked from commit f54f4dc0)

box_process_call/eval() in the end check if there is an
active transaction. If there is, it is rolled back, and
an error is set.

But rollback is not needed anymore, because anyway in
the end of the request the fiber is stopped, and its
not finished transaction is rolled back. Just setting
of the error is enough.

Follow-up #4662

(cherry picked from commit f5d51448)

Fiber.storage was not deleted when created in a fiber started from
the thread pool used by IProto requests. The problem was that
fiber.storage was created and deleted in Lua land only, assuming
that only Lua-born fibers could have it. But in fact any fiber can
create a Lua storage. Including the ones used to serve IProto
requests.

Not deletion of the storage led to a possibility of meeting a
non-empty fiber.storage in the beginning of an iproto request, and
to not deletion of the memory caught by the storage until its
explicit nullification.

Now the storage destructor works for any fiber, which managed to
create the storage. The destructor unrefs and nullifies the
storage.

For destructor purposes the fiber.on_stop triggers were reworked.
Now they can be called multiple times during fiber's lifetime.
After every request done by that fiber.

Closes #4662
Closes #3462

@TarantoolBot document
Title: Clarify fiber.storage lifetime

Fiber.storage is a Lua table created when it is first accessed. On
the site it is said that it is deleted when fiber is canceled via
fiber:cancel(). But it is not the full truth.

Fiber.storage is destroyed when the fiber is finished. Regardless
of how is it finished - via :cancel(), or the fiber's function
did 'return', it does not matter. Moreover, from that moment the
storage is cleaned up even for pooled fibers used to serve IProto
requests. Pooled fibers never really die, but nonetheless their
storage is cleaned up after each request. That makes possible to
use fiber.storage as a full featured request-local storage.

Fiber.storage may be created for a fiber no matter how the fiber
itself was created - from C, from Lua. For example, a fiber could
be created in C using fiber_new(), then it could insert into a
space, which had Lua on_replace triggers, and one of the triggers
could create fiber.storage. That storage will be deleted when the
fiber is stopped.

Another place where fiber.storage may be created - for replication
applier fiber. Applier has a fiber from which it applies
transactions from a remote instance. In case the applier fiber
somehow creates a fiber.storage (for example, from a space trigger
again), the storage won't be deleted until the applier fiber is
stopped.

(cherry picked from commit 7692e08f)

Fiber.storage is a table, available from anywhere in the fiber. It
is destroyed after fiber function is finished. That provides a
reliable fiber-local storage, similar to thread-local in C/C++.

But there is a problem that the storage may be created via one
struct lua_State, and destroyed via another. Here is an example:

    function test_storage()
        fiber.self().storage.key = 100
    end
    box.schema.func.create('test_storage')
    _ = fiber.create(function()
        box.func.test_storage:call()
    end)

There are 3 struct lua_State:
    tarantool_L - global always alive state;
    L1 - Lua coroutine of the fiber, created by fiber.create();
    L2 - Lua coroutine created by that fiber to execute
         test_storage().

Fiber.storage is created on stack of L2 and referenced by global
LUA_REGISTRYINDEX. Then it is unreferenced from L1 when the fiber
is being destroyed.

That is generally ok as soon as the storage object is always in
LUA_REGISTRYINDEX, which is shared by all Lua states.

But soon during destruction of the fiber.storage there will be
only tarantool_L and the original L2. Original L2 may be already
deleted by the time the storage is being destroyed. So this patch
makes unref of the storage via reliable tarantool_L.

Needed for #4662

(cherry picked from commit 5b3e8a72)

Every new error introduced into error engine cause massive update in
test even if only one key is introduced.

To minimize diff output better print them in sorted order.

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
(cherry picked from commit 95b9a48d)

We should first check that primary key is not NULL.

Closes #4745

(cherry picked from commit e9aa3784)

LuaJIT records traces while interpreting Lua bytecode (considering it's
hot enough) in order to compile the corresponding execution flow to a
machine code. A Lua/C call aborts trace recording, but an FFI call does
not abort it per se. If code inside an FFI call yields to another fiber
while recording a trace and the new current fiber interpreting a Lua
bytecode too, then unrelated instructions will be recorded to the
current trace.

In short, we should not yield a current fiber inside an FFI call.

There is another problem. Machine code of a compiled trace may sink a
value from a Lua state down to a host register, change it and write back
only at trace exit. So the interpreter state may be outdated during the
compiled trace execution. A Lua/C call aborts a trace and so the code
inside a callee always see an actual interpreter state. An FFI call
however can be turned into a single machine's CALL instruction in the
compiled code and if the callee accesses a Lua state, then it may see an
irrelevant value.

In short, we should not access a Lua state directly or reenter to the
interpreter from an FFI call.

The box.rollback_to_savepoint() function may yield and another fiber
will be scheduled for execution. If this fiber touches a Lua state, then
it may see an inconsistent state and the behaviour will be undefined.

Noted that <struct txn>.id starts from 1, because we lean on this fact
to use luaL_toint64(), which does not distinguish an unexpected Lua type
and cdata<int64_t> with zero value. It seems that this assumption
already exists: the code that prepare arguments for 'on_commit' triggers
uses luaL_toint64() too (see lbox_txn_pairs()).

Fixes #4427

Co-authored-by: Alexander Turenko <alexander.turenko@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>
(cherry picked from commit 34234427)

We're going to use S3 compatible storage for Deb and RPM repositories
instead of packagecloud.io service. The main reason is that
packagecloud.io provides a limited amount of storage, which is not
enough for keeping all packages (w/o regular pruning of old versions).

Note: At the moment packages are still pushed to packagecloud.io from
Travis-CI. Disabling this is out of scope of this patch.

This patch implements saving of packages on an S3 compatible storage and
regeneration of a repository metadata.

The layout is a bit different from one we have on packagecloud.io.

packagecloud.io:

 | - 1.10
 | - 2.1
 | - 2.2
 | - ...

S3 compatible storage:

 | - live
 |   - 1.10
 |   - 2.1
 |   - 2.2
 |   - ...
 | - release
 |   - 1.10
 |   - 2.1
 |   - 2.2
 |   - ...

Both 'live' and 'release' repositories track release branches (named as
<major>.<minor>) and master branch. The difference is that 'live' is
updated on every push, but 'release' is only for tagged versions
(<major>.<minor>.<patch>.0).

Packages are also built on '*-full-ci' branches, but only for testing
purposes: they don't pushed anywhere.

The core logic is in the tools/update_repo.sh script, which implements
the following flow:

- create metadata for new packages
- fetch relevant metadata from the S3 storage
- push new packages to the S3 storage
- merge and push the updated metadata to the S3 storage

The script uses 'createrepo' for RPM repositories and 'reprepro' for Deb
repositories.

Closes #3380

(cherry picked from commit 05d3ed4b)

This patch makes the INSTEAD OF DELETE trigger work for every row
in VIEW. Prior to this patch, it worked only once for each group
of non-unique rows.

Also, this patch adds tests to check that the INSTEAD OF UPDATE
trigger work for every row in VIEW.

Closes #4740

(cherry picked from commit 6ddccda4)

Revert "Free all slabs on region reset" commit.

Closes #4736

(cherry picked from commit fc8d42f50073f9b4f1510ce55ee514af14f672af)

Update decNumber library to silence the build warning produced on too
long integer constant.

(cherry picked from commit aab03a73)

Fix build on Mac with gcc and XCode 11

Part of https://github.com/tarantool/tarantool/issues/4580

Test multireturn in lua output mode and lack of a parameter in '\set
output <...>' command.

Co-developed-by: Alexander Turenko <alexander.turenko@tarantool.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
(cherry picked from commit cdf502c6)

In case if output format is not specified we should exit
with more readable error message.

Fixes #4638

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
(cherry picked from commit 9cc2c9c5)

Currently we handle only first member of multireturn statement.
Fix it processing each element separately.

n.b.: While at this file add vim settings.

 | tarantool> \set output lua
 | true;
 | tarantool> 1,2,3,4
 | 1, 2, 3, 4;

Fixes #4604

Reported-by: Alexander Turenko <alexander.turenko@tarantool.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
(cherry picked from commit d7cbd007)

Transaction adds a redo log for each statement. The log is an xrow
header. Some requests don't have a header (local requests), some
do (from remote client, from replication).

When a request had a header, it was written as is to WAL. But
requests from remote client have an xrow header, however barely
filled. Most of its fields are default values, usually 0.
Including group id. Indeed, remote clients should not care about
setting such deep system fields.

That led to a problem when a space had group id local (!= 0), but
it was ignored because in a request header from a remote client
the group id was default (== 0). On the summary, it was possible
to force Tarantool to replicate a replica-local space.

Now group id setting is server-authoritative. Box always sets it
regardless of what is present in an xrow header received from a
client.

Thanks Kostja Osipov (@kostja) for the diagnostics and the
solution.

Closes #4729

(cherry picked from commit 3d0f12968a8f5349eedb1778d6e29950f04785d5)

'pragma collation_list' uses _collation space, although user
may have no access to it. Thus, we replace it with the
corresponding view.

Closes #4713

(cherry picked from commit 28370f19)

Usually functions return pair `nil, err` and expected that err is string.
Let's make the behaviour of error object closer to string
and define __concat metamethod.

The case of error "error_mt.__concat(): neither of args is an error"
is not covered by tests because of #4723

Closes #4489

(cherry picked from commit 935db173)

Struct of type tuple_format is being passed as an argument to
tuple_format_unref() where it might be freed. On such occasion any
further references to format fields should not take place.

Acked-by: Cyrill Gorcunov <gorcunov@gmail.com>

Closes #4658

(cherry picked from commit c08b94ed)

- If an optional argument is provided for
  space_object:frommap() (which is {table = true|false}),
  type match for first arguments is omitted, which is
  incorrect. We should return the result only after making
  sure it is possible to build a tuple.

- If there is a type mismatch, however, frommap() does not
  return nil, err as it is mentioned in the description, so we
  change it to be this way.

Closes #4262

(cherry picked from commit ba2deae5acca0bf65e65433c67098a10946e7fd3)

Despite the lack of documentation, fio.mktree() was designed to work
similar to mkdir -p: it creates the directory along with it's parents
and doesn't complain about existing ones.

But this function was subject to a race if two different processes were
trying to create the same directory at the same time. It was caused by
the fact that directory existence check and its creation aren't atomic.

This patch fixes the race by impoving error handling: it's not an error
if directory exists, even if it was created by someone else and mktree
failed.

Related to https://github.com/tarantool/doc/issues/1063
Closes #4660

(cherry picked from commit 21ae2899)

It appears due to improper conflict resolution after pushing the
following commits in the reverse order:

* 2b9ef8d1 lua: don't modify pointer type in msgpack.decode*
* 84bcba52 lua: keeping the pointer type in msgpackffi.decode()

Originally 84bcba52 (which should land first) fixes the msgpackffi
module and introduces the test_decode_buffer() function locally for the
msgpackffi test. Then 2b9ef8d1 fixes the msgpack module in the same
way, expands and moves the test_decode_buffer() function to
serializer_test.lua (to use in msgpack and msgpackffi tests both).

After changes made to push the commits in the reverse order, those
commits doing something weird around tests. However the resulting state
is different from the right one just in the dead function in
msgpackffi.test.lua.

Follows up #3926.

(cherry picked from commit ec324247)

Method decode_unchecked returns two values - the one that has
been decoded and a pointer to the new position within the buffer
given as a parameter. The type of returned pointer used to be
cdata<unsigned char *> and it was not possible to assign returned
value to buf.rpos due to the following error:

> cannot convert 'const unsigned char *' to 'char *'

The patch fixes this by making decode_unchecked method return either
cdata<char *> or cdata<const char *> depending on the given parameter.

Closes #3926

(cherry picked from commit 84bcba52)

msgpackffi.decode_unchecked([const] char *) returns two values: a
decoded result and a new pointer within passed buffer. After #3926 a
cdata type of the returned pointer follows a type of passed buffer.

This commit modifies behaviour of msgpack module in the same way. The
following functions now returns cdata<char *> or cdata<const char *>
depending of its argument:

* msgpack.decode(cdata<[const] char *>, number)
* msgpack.decode_unchecked(cdata<[const] char *>)
* msgpack.decode_array_header(cdata<[const] char *>, number)
* msgpack.decode_map_header(cdata<[const] char *>, number)

Follows up #3926.

(cherry picked from commit 2b9ef8d1)

The tarantool_free() call in the end of main() works all the time except
when we exit due to a panic. We need to clear terminal state in this
case also, so return to using atexit() to clear readline state.

Closes #4466

(cherry picked from commit c6d4f010)

master1.lua did not reach all needed remote branches with
adb0a01b.
It is needed for join_vclock test.

socket.test had a number of flaky problems:
- socket readiness expectation & read timeouts
- race conditions on socket shutdown in emulation test cases
- UDP datagrams losses on mac os
- excessive random port searches
Now they are solved. 127.0.0.1 is now used instead of 0.0.0.0 or
localhost to prevent wrong connections where appropriate. Socket test
is not fragile anymore.

Closes #4426
Closes #4451
Closes #4469

(cherry picked from commit 4137134c)

join_vclock test is assumed to verify that changes are not being lost
on the replica. Due to this the test is changed to explicitly check
that all changes on master are applied on replica.
Previously this test was also indirectly verifying that changes are
being applied in the correct order. Now there is separate test for
this, called replica_apply_order.
As far as changed join_vclock test might fail due to #4669, we are now
creating cluster out of fresh instances instead of using default
instance. Considering mentioned fixes it is not fragile anymore.

Closes #4160

(cherry picked from commit adb0a01b)

* Support to set default SQL engine using _session_settings space in
  addition to pragma sql_default_engine. This feature is only for
  *.test.sql tests. Needed for #4511.

* Use exact IPv4/IPv6 address in test_run:cmd() in order to avoid rare
  failures due to using wrong address (PR #197).

(cherry picked from commit a6535ab3b8d3e395d2f81699cf35329118412307)

In scope of 8fac6972 it was fixed misbehavior while passing floating
point values to integer iterator. Unfortunately, that patch introduced
off-by-one error. Number of constraints (equalities and inequalities)
can not be greater than number of key parts (obviously, each constraint
can be tested against at most one index part). Inequality constraint can
involve only field representing last key part. To get it number of
constraints was used as index. However, since array is 0-based, the last
key part should be calculated as parts[eq_numb - 1]. Before this patch
it was parts[eq_numb].

Closes #4558

(cherry picked from commit bb905d1d)

The test re encoding of -2^63 Lua number value did use update by a field
name, which does not supported in 1.10 and 2.2 branches. Field name
updates are orthogonal to Lua number serialization and we don't intend
to test them here. So it is safe and logical to get rid of them in the
test.

This change allow the test to pass on 1.10 and 2.2 branches.

Follows up #4672.

Reviewed-by: Alexander Tikhonov <avtikhon@tarantool.org>
Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
(cherry picked from commit 408b9ad4)

Accidentally, number of indexes to be considered during query planning
in presence of INDEXED BY is calculated wrong. Instead of one (INDEXED
BY is not a hint but requirement) index to be used (which is indicated
in INDEXED BY clause), all space indexes take part in query planning.
There are not so many tests checking this feature, so unfortunately this
bug was hidden. Let's fix it and force only one index to be used in QP
in case of INDEXED BY clause.

(cherry picked from commit 49fedfe3)

libcurl-7.66.0 and older returns CURLE_WRITE_ERROR when a server
responds with unknown or unsupported Content-Encoding (see [1] and [2]).
This was fixed in future libcurl-7.67.0 and proper
CURLE_BAD_CONTENT_ENCODING code will be returned in this case.

We should process the code in the same way as we do for
CURLE_WRITE_ERROR.

[1]: curl/curl#4310
[2]: curl/curl#4449

Closes #4579

Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
(cherry picked from commit e3432636)

After executing curl request we need to process curl_request code. It
might be CURLE_WRITE_ERROR. We had special case for it, which assumed
diagnostic message being set and contained corresponding assert, though
it is incorrect. Better way is to handle it as any other non-standard
event.

It was discovered while adding accept_encoding option. In case of
unknown encoding curl_request code is currently set to CURLE_WRITE_ERROR
and therefore we come to an assert assuming we have some diagnostics
set. However, it is not being set and it is totally fine. This means we
are failing on assert and it is not correct behavior.

Prerequisites: #4232

Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
(cherry picked from commit 728d08a6)