8000 [FreeBSD]: port files. by zloidemon · Pull Request #4 · tarantool/tarantool · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[FreeBSD]: port files. #4

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
Merged
merged 1 commit into from
Aug 3, 2012
Merged

[FreeBSD]: port files. #4

merged 1 commit into from
Aug 3, 2012

Conversation

zloidemon
Copy link
Contributor

Please add it for FreeBSD users.

kostja added a commit that referenced this pull request Aug 3, 2012
@kostja
Merge pull request #4 from zloidemon/master
ac0fedb 
[FreeBSD]: port files.
@kostja kostja merged commit ac0fedb into tarantool:master Aug 3, 2012
@kostja kostja mentioned this pull request Dec 2, 2013
Closed
@whiteglasses whiteglasses mentioned this pull request Jan 24, 2014
Closed
delamonpansie referenced this pull request in delamonpansie/octopus Feb 26, 2014
@pygy
Merge pull request #4 from Yonaba/patch-1
371e9c0 
Typo fix and prettyfication
@pgulutzan pgulutzan mentioned this pull request Apr 25, 2014
Closed
@knizhnik knizhnik mentioned this pull request Apr 27, 2014
Closed
@pgulutzan pgulutzan mentioned this pull request Apr 27, 2014
Closed
@kostja kostja mentioned this pull request Jun 3, 2014
Closed
@kostja kostja mentioned this pull request Jun 18, 2014
Closed
@vocalbit vocalbit mentioned this pull request Jun 29, 2014
Closed
This was referenced Aug 15, 2014
Closed
Closed
@kostja kostja mentioned this pull request Sep 5, 2014
Closed
@pgulutzan pgulutzan mentioned this pull request Sep 10, 2014
Closed
@pmwkaa pmwkaa mentioned this pull request Sep 17, 2014
Closed
This was referenced Sep 25, 2014
Closed
Closed
@avid avid mentioned this pull request Nov 1, 2014
Closed
@ilejn ilejn mentioned this pull request Nov 6, 2014
Closed
@pgulutzan pgulutzan mentioned this pull request Dec 12, 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 #4 to Russian
9e18930
@mialinx mialinx mentioned this pull request Apr 3, 2015
Closed
@kostja kostja mentioned this pull request Apr 24, 2015
Closed
@a0s a0s mentioned this pull request Oct 6, 2015
Closed
@pgulutzan pgulutzan mentioned this pull request Oct 7, 2015
Closed
@pgulutzan pgulutzan mentioned this pull request Dec 10, 2015
Closed
@YadrovSergey YadrovSergey mentioned this pull request Feb 8, 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
1E0A 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.
2 participants
@zloidemon @kostja
0