8000 Ability to save all deleted tuples and groups em by operation date by dmitry-grytsovets · Pull Request #9 · tarantool/tarantool · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Ability to save all deleted tuples and groups em by operation date #9

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 19 commits into from
Closed

Ability to save all deleted tuples and groups em by operation date #9

wants to merge 19 commits into from

Conversation

dmitry-grytsovets
Copy link

Subj.

@dmitry-grytsovets
First version of atchive mod
f9fb029
@dmitry-grytsovets
Makelist with archive.m
360f9f0
@dmitry-grytsovets
Add forgotten const to log_format
0688bcb
@dmitry-grytsovets
Add archive_dir and archive_filename_format variables to config
2262f4b
@dmitry-grytsovets
Some change in tarantool header files to reuse existing data structur…
faa316a 
…es and code

Refactoring of archive module
Commited version is not fully tested it only compiles :)
@dmitry-grytsovets
Add flush for header and batch flush on stop
ad068ce
@dmitry-grytsovets
Merge git://github.com/mailru/tarantool
ceac300
@dmitry-grytsovets
Add archive_fsync_delay property
a0eed09
@dmitry-grytsovets
Add check that archive directory is not null
a7da660 
Add more exact wait to sync thread
@dmitry-grytsovets
Fix timedwait mistake
8dd427f
@dmitry-grytsovets
Fix more exact time
240f5ef
@dmitry-grytsovets
Comment h&m files headers
57b6616
@dmitry-grytsovets
Merge git://github.com/mailru/tarantool
22d1d01
@dmitry-grytsovets
Move hook at txn_commit to right place
9a8a3c9 
Fix sigsegv in wakeup_fibers
@dmitry-grytsovets
Remove some spaces to reduce size of patch file
657e4db
@dmitry-grytsovets
Rollback format
7daf954
@dmitry-grytsovets
Rollback format
ae8eed0
@dmitry-grytsovets
Fix gc_pool release at recovery mode
afafc0f 
Return hooks at box.m
@dmitry-grytsovets
Copy link
Author

nb output

WAL and Archive

.----------.---------------.---------------.---------------.
| type | minimal | average | maximum |
.----------.---------------.---------------.---------------.
| read/s | 24100 | 27158 | 28550 |
| write/s | 96432 | 108663 | 114227 |
| req/s | 120539 | 135830 | 142785 |
| rtt/ms | 0.07006 | 0.08365 | 0.132163 |
'----------.---------------.---------------.---------------'

No WAL

.----------.---------------.---------------.---------------.
| type | minimal | average | maximum |
.----------.---------------.---------------.---------------.
| read/s | 22799 | 31441 | 33659 |
| write/s | 91219 | 125798 | 134665 |
| req/s | 114028 | 157252 | 168331 |
| rtt/ms | 0.05943 | 0.06622 | 0.096169 |
'----------.---------------.---------------.---------------'

No Archive

.----------.---------------.---------------.---------------.
| type | minimal | average | maximum |
.----------.---------------.---------------.---------------.
| read/s | 30492 | 32000 | 32720 |
| write/s | 122005 | 128033 | 130916 |
| req/s | 152508 | 160045 | 163647 |
| rtt/ms | 0.06119 | 0.07060 | 0.105937 |
'----------.---------------.---------------.---------------'

@dmitry-grytsovets
Merge git://github.com/mailru/tarantool
85db869 
Conflicts:
	src/box/CMakeLists.txt
@knizhnik knizhnik mentioned this pull request Apr 27, 2014
Closed
@kostja kostja mentioned this pull request Jun 18, 2014
Closed
@kostja kostja mentioned this pull request Sep 5, 2014
Closed
@pmwkaa pmwkaa mentioned this pull request Sep 17, 2014
Closed
@ilejn ilejn mentioned this pull request Nov 6, 2014
Closed
@pmwkaa pmwkaa mentioned this pull request Feb 4, 2015
Closed
zloidemon added a commit that referenced this pull request Mar 24, 2015
@zloidemon
Translated screen #9 to Russian
c7b3a89
@YadrovSergey YadrovSergey mentioned this pull request Feb 8, 2016
Closed
@kostja kostja mentioned this pull request Feb 10, 2016
Closed
nshy added a commit to nshy/tarantool that referenced this pull request Jul 8, 2024
@nshy
lsan: fix memory leak on vinyl dump/compaction failure
6b4aa94 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

NO_TEST=covered by existing tests (ASAN build)
NO_DOC=bugfix
nshy added a commit to nshy/tarantool that referenced this pull request Jul 8, 2024
@nshy
lsan: fix memory leak on vinyl dump/compaction failure
6d3ca4e 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

NO_TEST=covered by existing tests (ASAN build)
NO_DOC=bugfix
nshy added a commit to nshy/tarantool that referenced this pull request Jul 9, 2024
@nshy
lsan: fix memory leak on vinyl dump/compaction failure
d620475 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

NO_TEST=covered by existing tests (ASAN build)
NO_DOC=bugfix
nshy added a commit to nshy/tarantool that referenced this pull request Jul 12, 2024
@nshy
lsan: fix memory leak on vinyl dump/compaction failure
c48dcc0 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

NO_TEST=covered by existing tests (ASAN build)
NO_DOC=bugfix
nshy added a commit to nshy/tarantool that referenced this pull request Jul 15, 2024
@nshy
vinyl: fix memory leak on dump/compaction failure
9b8a6e7 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

NO_TEST=covered by existing tests (ASAN build)
NO_DOC=bugfix
ligurio added a commit to ligurio/tarantool that referenced this pull request Aug 19, 2024
@ligurio
test.mk
b574572 
Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option.

```
 [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua                     [ pass ]
[050]
[050]
[050] [Instance "box" returns with non-zero exit code: 1]
[050]
[050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log:
[050]     tarantool#9 0x55d6c6868851  (<unknown module>)
[050]
[050] Direct leak of 342 byte(s) in 5 object(s) allocated from:
[050]     #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa)
[050]     tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
[050]     tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5
[050]     tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27
[050]     tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9
[050]     tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22
[050]     tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12
[050]     tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9
[050]     tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11
[050]     tarantool#9 0x55d6c685ea09  (<unknown module>)
[050]
[050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s).
[055] box-luatest/gh_8530_alter_space_snapshot_test.>               [ pass ]
```

1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431
2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal
ligurio added a commit to ligurio/tarantool that referenced this pull request Aug 19, 2024
@ligurio
test.mk
6002a3e 
Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option.

```
 [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua                     [ pass ]
[050]
[050]
[050] [Instance "box" returns with non-zero exit code: 1]
[050]
[050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log:
[050]     tarantool#9 0x55d6c6868851  (<unknown module>)
[050]
[050] Direct leak of 342 byte(s) in 5 object(s) allocated from:
[050]     #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa)
[050]     tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
[050]     tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5
[050]     tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27
[050]     tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9
[050]     tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22
[050]     tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12
[050]     tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9
[050]     tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11
[050]     tarantool#9 0x55d6c685ea09  (<unknown module>)
[050]
[050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s).
[055] box-luatest/gh_8530_alter_space_snapshot_test.>               [ pass ]
```

1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431
2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal
ligurio added a commit to ligurio/tarantool that referenced this pull request Aug 20, 2024
@ligurio
test.mk
578b95c 
Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option.

```
 [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua                     [ pass ]
[050]
[050]
[050] [Instance "box" returns with non-zero exit code: 1]
[050]
[050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log:
[050]     tarantool#9 0x55d6c6868851  (<unknown module>)
[050]
[050] Direct leak of 342 byte(s) in 5 object(s) allocated from:
[050]     #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa)
[050]     tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
[050]     tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5
[050]     tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27
[050]     tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9
[050]     tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22
[050]     tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12
[050]     tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9
[050]     tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11
[050]     tarantool#9 0x55d6c685ea09  (<unknown module>)
[050]
[050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s).
[055] box-luatest/gh_8530_alter_space_snapshot_test.>               [ pass ]
```

1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431
2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal
@d-enk d-enk mentioned this pull request Aug 20, 2024
Closed
nshy added a commit to nshy/tarantool that referenced this pull request Aug 28, 2024
@nshy
vinyl: fix memory leak on dump/compaction failure
7039452 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

NO_TEST=covered by existing tests (ASAN build)
NO_DOC=bugfix
nshy added a commit to nshy/tarantool that referenced this pull request Aug 28, 2024
@nshy
vinyl: fix memory leak on dump/compaction failure
953dfa3 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

NO_TEST=covered by existing tests (ASAN build)
NO_DOC=bugfix
nshy added a commit to nshy/tarantool that referenced this pull request Aug 29, 2024
@nshy
vinyl: fix memory leak on dump/compaction failure
da4d934 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes tarantool#10489
Part-of tarantool#10211

NO_TEST=covered by existing tests
NO_DOC=bugfix
nshy added a commit to nshy/tarantool that referenced this pull request Aug 29, 2024
@nshy
vinyl: fix memory leak on dump/compaction failure
3449e37 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes tarantool#10489
Part-of tarantool#10211

NO_TEST=covered by existing tests
NO_DOC=bugfix
nshy added a commit to nshy/tarantool that referenced this pull request Aug 30, 2024
@nshy
vinyl: fix memory leak on dump/compaction failure
94e44e9 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes tarantool#10489
Part-of tarantool#10211

NO_TEST=covered by existing tests
NO_DOC=bugfix
ligurio added a commit to ligurio/tarantool that referenced this pull request Aug 30, 2024
@ligurio
test.mk
b2b5669 
Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option.

```
 [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua                     [ pass ]
[050]
[050]
[050] [Instance "box" returns with non-zero exit code: 1]
[050]
[050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log:
[050]     tarantool#9 0x55d6c6868851  (<unknown module>)
[050]
[050] Direct leak of 342 byte(s) in 5 object(s) allocated from:
[050]     #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa)
[050]     tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
[050]     tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5
[050]     tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27
[050]     tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9
[050]     tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22
[050]     tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12
[050]     tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9
[050]     tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11
[050]     tarantool#9 0x55d6c685ea09  (<unknown module>)
[050]
[050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s).
[055] box-luatest/gh_8530_alter_space_snapshot_test.>               [ pass ]
```

1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431
2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal
nshy added a commit to nshy/tarantool that referenced this pull request Aug 30, 2024
@nshy
vinyl: fix memory leak on dump/compaction failure
ba28288 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes tarantool#10489
Part-of tarantool#10211

NO_TEST=covered by existing tests
NO_DOC=bugfix
locker pushed a commit that referenced this pull request Aug 30, 2024
@nshy @locker
vinyl: fix memory leak on dump/compaction failure
84101f6 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    #1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    #2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    #3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    #4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    #5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    #6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    #7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    #8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    #9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    #10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes #10489
Part-of #10211

NO_TEST=covered by existing tests
NO_DOC=bugfix
locker pushed a commit that referenced this pull request Aug 30, 2024
@nshy @locker
vinyl: fix memory leak on dump/compaction failure
503b599 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    #1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    #2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    #3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    #4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    #5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    #6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    #7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    #8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    #9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    #10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes #10489
Part-of #10211

NO_TEST=covered by existing tests
NO_DOC=bugfix

(cherry picked from commit 84101f6)
locker pushed a commit that referenced this pull request Aug 30, 2024
@nshy @locker
vinyl: fix memory leak on dump/compaction failure
b6cd6bb 
The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    #1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    #2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    #3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    #4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    #5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    #6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    #7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    #8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    #9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    #10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes #10489
Part-of #10211

NO_TEST=covered by existing tests
NO_DOC=bugfix

(cherry picked from commit 84101f6)
ligurio added a commit to ligurio/tarantool that referenced this pull request Sep 5, 2024
@ligurio
test.mk
b32c5d1 
Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option.

```
 [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua                     [ pass ]
[050]
[050]
[050] [Instance "box" returns with non-zero exit code: 1]
[050]
[050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log:
[050]     tarantool#9 0x55d6c6868851  (<unknown module>)
[050]
[050] Direct leak of 342 byte(s) in 5 object(s) allocated from:
[050]     #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa)
[050]     tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
[050]     tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5
[050]     tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27
[050]     tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9
[050]     tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22
[050]     tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12
[050]     tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9
[050]     tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11
[050]     tarantool#9 0x55d6c685ea09  (<unknown module>)
[050]
[050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s).
[055] box-luatest/gh_8530_alter_space_snapshot_test.>               [ pass ]
```

1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431
2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal
ligurio added a commit to ligurio/tarantool that referenced this pull request Sep 5, 2024
@ligurio
test.mk
6503a8e 
Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option.

```
 [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua                     [ pass ]
[050]
[050]
[050] [Instance "box" returns with non-zero exit code: 1]
[050]
[050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log:
[050]     tarantool#9 0x55d6c6868851  (<unknown module>)
[050]
[050] Direct leak of 342 byte(s) in 5 object(s) allocated from:
[050]     #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa)
[050]     tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
[050]     tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5
[050]     tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27
[050]     tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9
[050]     tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22
[050]     tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12
[050]     tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9
[050]     tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11
[050]     tarantool#9 0x55d6c685ea09  (<unknown module>)
[050]
[050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s).
[055] box-luatest/gh_8530_alter_space_snapshot_test.>               [ pass ]
```

1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431
2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal
Totktonada added a commit that referenced this pull request Oct 11, 2024
@Totktonada
build: update libcurl to curl-8_10_1-241-g461ce6c61
44013f4 
The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally
Totktonada added a commit that referenced this pull request Oct 14, 2024
@Totktonada
build: update libcurl to curl-8_10_1-241-g461ce6c61
d48ac5e 
The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally
Totktonada added a commit that referenced this pull request Oct 14, 2024
@Totktonada
build: update libcurl to curl-8_10_1-241-g461ce6c61
fbe6d0a 
The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally
Totktonada added a commit that referenced this pull request Oct 14, 2024
@Totktonada
build: update libcurl to curl-8_10_1-241-g461ce6c61
ca53657 
The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

(cherry picked from commit fbe6d0a)
Totktonada added a commit that referenced this pull request Oct 14, 2024
@Totktonada
build: update libcurl to curl-8_10_1-241-g461ce6c61
825a847 
The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

(cherry picked from commit fbe6d0a)
Totktonada added a commit that referenced this pull request Oct 14, 2024
@Totktonada
build: update libcurl to curl-8_10_1-241-g461ce6c61
94be5c1 
The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

(cherry picked from commit fbe6d0a)
Totktonada added a commit that referenced this pull request Oct 14, 2024
@Totktonada
build: update libcurl to curl-8_10_1-241-g461ce6c61
89b2760 
The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

(cherry picked from commit fbe6d0a)
mandesero pushed a commit to mandesero/tarantool that referenced this pull request Oct 16, 2024
@Totktonada @mandesero
build: update libcurl to curl-8_10_1-241-g461ce6c61
f9a78b2 
The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
tarantool#4  __assert_fail
tarantool#5  curl_multi_assign            // <- called by us
tarantool#6  curl_multi_sock_cb           // <- this is our callback
tarantool#7  Curl_multi_pollset_ev
tarantool#8  cpool_update_shutdown_ev
tarantool#9  cpool_discard_conn
tarantool#10 cpool_close_and_destroy_all
tarantool#11 Curl_cpool_destroy
tarantool#12 curl_multi_cleanup
tarantool#13 curl_env_finish              // <- destroy the multi handle
tarantool#14 httpc_env_finish
tarantool#15 luaT_httpc_cleanup
tarantool#16 lj_BC_FUNCC
tarantool#17 gc_call_finalizer
tarantool#18 gc_finalize
tarantool#19 gc_onestep
tarantool#20 lj_gc_fullgc
tarantool#21 lua_gc
tarantool#22 lj_cf_collectgarbage
tarantool#23 lj_BC_FUNCC
tarantool#24 lua_pcall
tarantool#25 luaT_call
tarantool#26 lua_main
tarantool#27 run_script_f
tarantool#28 fiber_cxx_invoke
tarantool#29 fiber_loop
tarantool#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally
@ivan2kh ivan2kh mentioned this pull request Mar 7, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@dmitry-grytsovets
0