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

Assertion fail in cpipe_create() #4806

Closed
Totktonada opened this issue Mar 16, 2020 · 1 comment
Closed

Assertion fail in cpipe_create() #4806

Totktonada opened this issue Mar 16, 2020 · 1 comment
Assignees
Labels
bug Something isn't working crash
Milestone

Comments

@Totktonada
Copy link
Member

Tarantool version: 1.10.5-29-g99d4bf09c, Debug.
OS version: Linux.

I don't meet this on current master (2.4.0-87-g546063565), but it worth to re-check.

How to reproduce:

$ cmake . -DCMAKE_BUILD_TYPE=Debug -DENABLE_BACKTRACE=ON -DENABLE_DIST=ON -DENABLE_BUNDLED_LIBCURL=OFF && make -j
$ (cd test && ./test-run.py $(yes xlog/panic_on_broken_lsn.test.lua | head -n 1000))

What appears:

[013] Test failed! Result content mismatch:
[013] --- xlog/panic_on_broken_lsn.result	Mon Mar 16 12:21:57 2020
[013] +++ xlog/panic_on_broken_lsn.reject	Mon Mar 16 12:35:39 2020
[013] @@ -78,8 +78,8 @@
[013]  ...
[013]  (found:gsub('^.*, req: ', ''):gsub('lsn: %d+', 'lsn: <lsn>'))
[013]  ---
[013] -- '{type: ''REPLACE'', replica_id: 1, lsn: <lsn>, space_id: 272, index_id: 0, tuple:
[013] -  ["t0", "v1"]}'
[013] +- error: '[string "return (found:gsub(''^.*, req: '', ''''):gsub(''ls..."]:1: attempt
[013] +    to index global ''found'' (a nil value)'
[013]  ...
[013]  test_run:cmd('cleanup server panic')
[013]  ---

Logs:

$ tail -n 4 test/var/013_xlog/panic.log
2020-03-16 12:35:38.944 [10507] main/101/panic F> LSN for 1 is used twice or COMMIT order is broken: confirmed: 1, new: 1, req: {type: 'REPLACE', replica_id: 1, lsn: 1, space_id: 272, index_id: 0, tuple: ["t0", "v1"]}
2020-03-16 12:35:38.944 [10507] main/101/panic F> LSN for 1 is used twice or COMMIT order is broken: confirmed: 1, new: 1, req: {type: 'REPLACE', replica_id: 1, lsn: 1, space_id: 272, index_id: 0, tuple: ["t0", "v1"]}
2020-03-16 12:35:38.945 [10507] wal/101/main cbus.c:103 !> cpipe_create error 22: Success
tarantool: /home/alex/p/tarantool-meta/tarantool/src/cbus.c:103: cpipe_create: Assertion `e__ == 0' failed.

Backtrace:

(gdb) bt
#0  0x00007fdf736021f1 in raise () from /lib64/libc.so.6
#1  0x00007fdf735ea55b in abort () from /lib64/libc.so.6
#2  0x00007fdf735ea42f in __assert_fail_base.cold () from /lib64/libc.so.6
#3  0x00007fdf735f99e2 in __assert_fail () from /lib64/libc.so.6
#4  0x00005609c84bce5b in cpipe_create (pipe=0x5609c87f7758 <wal_writer_singleton+5592>, consumer=0x5609c86a99d6 "tx_prio") at /home/alex/p/tarantool-meta/tarantool/src/cbus.c:103
#5  0x00005609c847fff3 in wal_writer_f (ap=0x7fdf54c00228) at /home/alex/p/tarantool-meta/tarantool/src/box/wal.c:895
#6  0x00005609c83a891a in fiber_cxx_invoke(fiber_func, typedef __va_list_tag __va_list_tag *) (f=0x5609c847ff8a <wal_writer_f>, ap=0x7fdf54c00228)
    at /home/alex/p/tarantool-meta/tarantool/src/fiber.h:678
#7  0x00005609c84b8c61 in fiber_loop (data=0x0) at /home/alex/p/tarantool-meta/tarantool/src/fiber.c:713
#8  0x00005609c8686e56 in coro_init () at /home/alex/p/tarantool-meta/tarantool/third_party/coro/coro.c:110
@Totktonada Totktonada added crash bug Something isn't working labels Mar 16, 2020
@kyukhin kyukhin added this to the 1.10.6 milestone Apr 1, 2020
@kyukhin kyukhin modified the milestones: 1.10.6, 1.10.7 Apr 20, 2020
cyrillos added a commit that referenced this issue Apr 22, 2020
The notification of wait variable shall be done under
a bound mutex locked. Otherwise the results are not
guaranteed (see pthread manuals).

Thus when we create a new endpoint via cbus_endpoint_create
and there is an other thread which sleeps inside cpipe_create
we should notify the sleeper under cbus.mutex.

Fixes #4806

Reported-by: Alexander Turenko <alexander.turenko@tarantool.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
@cyrillos
Copy link
Contributor

kyukhin pushed a commit that referenced this issue Apr 24, 2020
The notification of wait variable shall be done under
a bound mutex locked. Otherwise the results are not
guaranteed (see pthread manuals).

Thus when we create a new endpoint via cbus_endpoint_create
and there is an other thread which sleeps inside cpipe_create
we should notify the sleeper under cbus.mutex.

Fixes #4806

Reported-by: Alexander Turenko <alexander.turenko@tarantool.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
(cherry picked from commit d6d69c9)
kyukhin pushed a commit that referenced this issue Apr 24, 2020
The notification of wait variable shall be done under
a bound mutex locked. Otherwise the results are not
guaranteed (see pthread manuals).

Thus when we create a new endpoint via cbus_endpoint_create
and there is an other thread which sleeps inside cpipe_create
we should notify the sleeper under cbus.mutex.

Fixes #4806

Reported-by: Alexander Turenko <alexander.turenko@tarantool.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
(cherry picked from commit d6d69c9)
kyukhin pushed a commit that referenced this issue Apr 24, 2020
The notification of wait variable shall be done under
a bound mutex locked. Otherwise the results are not
guaranteed (see pthread manuals).

Thus when we create a new endpoint via cbus_endpoint_create
and there is an other thread which sleeps inside cpipe_create
we should notify the sleeper under cbus.mutex.

Fixes #4806

Reported-by: Alexander Turenko <alexander.turenko@tarantool.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
(cherry picked from commit d6d69c9)
ligurio pushed a commit that referenced this issue Jul 22, 2020
The notification of wait variable shall be done under
a bound mutex locked. Otherwise the results are not
guaranteed (see pthread manuals).

Thus when we create a new endpoint via cbus_endpoint_create
and there is an other thread which sleeps inside cpipe_create
we should notify the sleeper under cbus.mutex.

Fixes #4806

Reported-by: Alexander Turenko <alexander.turenko@tarantool.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working crash
Projects
None yet
Development

No branches or pull requests

3 participants