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
+109 −0

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
ligurio added a commit to ligurio/nanodata 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/nanodata 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/nanodata 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/nanodata 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
locker added a commit that referenced this pull request Aug 7, 2025
@locker
lsan: add suppressions
51d4e47 
After updating clang to 19 and luatest to 1.2.0, running the test
replication-luatest/gh_9399_raft_leader_steps_off_on_ER_WAL_IO_test.lua
reports new memory leaks:

```
=================================================================
==61990==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 584 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891b920 in region_prepare_buf /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:39:4
    #3 0x55555891c237 in region_aligned_alloc /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:94:14
    #4 0x555557a517fb in fiber_gc_checker_init /__w/tarantool/tarantool/src/lib/core/fiber.c:1542:3
    #5 0x555557a568c3 in cord_create /__w/tarantool/tarantool/src/lib/core/fiber.c:1870:2
    #6 0x555557a5d242 in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1984:2
    #7 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

Direct leak of 564 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891346d in mempool_alloc /__w/tarantool/tarantool/src/lib/small/small/mempool_asan.c:67:4
    #3 0x5555568c8db8 in iproto_msg_new(iproto_connection*) /__w/tarantool/tarantool/src/box/iproto.cc:1010:24
    #4 0x5555568e691d in iproto_thread_accept(iproto_thread*, iostream*, sockaddr*, unsigned int, session*) /__w/tarantool/tarantool/src/box/iproto.cc:3420:27
    #5 0x5555568e687e in iproto_on_accept_cb(evio_service*, iostream*, sockaddr*, unsigned int) /__w/tarantool/tarantool/src/box/iproto.cc:3438:2
    #6 0x555557abc5b5 in evio_service_entry_accept_cb /__w/tarantool/tarantool/src/lib/core/evio.c:207:3
    #7 0x55555896db7b in ev_invoke_pending /__w/tarantool/tarantool/third_party/libev/ev.c:3797:11
    #8 0x55555896f5bd in ev_run /__w/tarantool/tarantool/third_party/libev/ev.c:4221:7
    #9 0x555557a660a6 in cord_costart_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:2203:3
    #10 0x555557a5f6ee in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1996:14
    #11 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

SUMMARY: AddressSanitizer: 1148 byte(s) leaked in 2 allocation(s).
```

It's unclear what exactly triggered the new leaks detection. Let's file
tickets and add suppressions.

See #10701
See #11740

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan
locker added a commit that referenced this pull request Aug 7, 2025
@locker
lsan: add suppressions
28ede31 
After updating clang to 19 and luatest to 1.2.0, running the test
replication-luatest/gh_9399_raft_leader_steps_off_on_ER_WAL_IO_test.lua
reports new memory leaks:

```
=================================================================
==61990==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 584 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891b920 in region_prepare_buf /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:39:4
    #3 0x55555891c237 in region_aligned_alloc /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:94:14
    #4 0x555557a517fb in fiber_gc_checker_init /__w/tarantool/tarantool/src/lib/core/fiber.c:1542:3
    #5 0x555557a568c3 in cord_create /__w/tarantool/tarantool/src/lib/core/fiber.c:1870:2
    #6 0x555557a5d242 in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1984:2
    #7 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

Direct leak of 564 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891346d in mempool_alloc /__w/tarantool/tarantool/src/lib/small/small/mempool_asan.c:67:4
    #3 0x5555568c8db8 in iproto_msg_new(iproto_connection*) /__w/tarantool/tarantool/src/box/iproto.cc:1010:24
    #4 0x5555568e691d in iproto_thread_accept(iproto_thread*, iostream*, sockaddr*, unsigned int, session*) /__w/tarantool/tarantool/src/box/iproto.cc:3420:27
    #5 0x5555568e687e in iproto_on_accept_cb(evio_service*, iostream*, sockaddr*, unsigned int) /__w/tarantool/tarantool/src/box/iproto.cc:3438:2
    #6 0x555557abc5b5 in evio_service_entry_accept_cb /__w/tarantool/tarantool/src/lib/core/evio.c:207:3
    #7 0x55555896db7b in ev_invoke_pending /__w/tarantool/tarantool/third_party/libev/ev.c:3797:11
    #8 0x55555896f5bd in ev_run /__w/tarantool/tarantool/third_party/libev/ev.c:4221:7
    #9 0x555557a660a6 in cord_costart_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:2203:3
    #10 0x555557a5f6ee in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1996:14
    #11 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

SUMMARY: AddressSanitizer: 1148 byte(s) leaked in 2 allocation(s).
```

It's unclear what exactly triggered the new leaks detection. Let's file
tickets and add suppressions.

See #10701
See #11740

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan
locker added a commit that referenced this pull request Aug 7, 2025
@locker
lsan: add suppressions
ebf850d 
After updating clang to 19 and luatest to 1.2.0, running the test
replication-luatest/gh_9399_raft_leader_steps_off_on_ER_WAL_IO_test.lua
reports new memory leaks:

```
=================================================================
==61990==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 584 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891b920 in region_prepare_buf /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:39:4
    #3 0x55555891c237 in region_aligned_alloc /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:94:14
    #4 0x555557a517fb in fiber_gc_checker_init /__w/tarantool/tarantool/src/lib/core/fiber.c:1542:3
    #5 0x555557a568c3 in cord_create /__w/tarantool/tarantool/src/lib/core/fiber.c:1870:2
    #6 0x555557a5d242 in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1984:2
    #7 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

Direct leak of 564 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891346d in mempool_alloc /__w/tarantool/tarantool/src/lib/small/small/mempool_asan.c:67:4
    #3 0x5555568c8db8 in iproto_msg_new(iproto_connection*) /__w/tarantool/tarantool/src/box/iproto.cc:1010:24
    #4 0x5555568e691d in iproto_thread_accept(iproto_thread*, iostream*, sockaddr*, unsigned int, session*) /__w/tarantool/tarantool/src/box/iproto.cc:3420:27
    #5 0x5555568e687e in iproto_on_accept_cb(evio_service*, iostream*, sockaddr*, unsigned int) /__w/tarantool/tarantool/src/box/iproto.cc:3438:2
    #6 0x555557abc5b5 in evio_service_entry_accept_cb /__w/tarantool/tarantool/src/lib/core/evio.c:207:3
    #7 0x55555896db7b in ev_invoke_pending /__w/tarantool/tarantool/third_party/libev/ev.c:3797:11
    #8 0x55555896f5bd in ev_run /__w/tarantool/tarantool/third_party/libev/ev.c:4221:7
    #9 0x555557a660a6 in cord_costart_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:2203:3
    #10 0x555557a5f6ee in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1996:14
    #11 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

SUMMARY: AddressSanitizer: 1148 byte(s) leaked in 2 allocation(s).
```

It's unclear what exactly triggered the new leaks detection. Let's file
tickets and add suppressions.

See #10701
See #11740

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan
sergepetrenko added a commit to sergepetrenko/tarantool that referenced this pull request Aug 12, 2025
@sergepetrenko
lsan: add suppression for Curl_http_write_resp
fb4d65a 
Leak sanitizer started detecting new leaks in etcd-client tests in
the enterprise repo. This only happens on 3.2 branch, and must be
due to the fact we haven't backported commits regarding correct Lua
state cleanup on shutdown. Commit 80a11c4 ("box: close Lua state
on exit") in particular.

Since that patch series is rather heavy, let's simply suppress the leak
in 3.2 branch.

The leak in question:
```
Direct leak of 52 byte(s) in 1 object(s) allocated from:
   #0 0x556c873b3aae in malloc (/__w/tarantool-ee/tarantool-ee/tarantool/src/tarantool+0x1573aae) (BuildId: b2a73382837eb52617097838e12bd4d33ce21792)
   tarantool#1 0x556c89ebd8ec in small_asan_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
   tarantool#2 0x556c89eb5f84 in region_prepare_buf /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
   tarantool#3 0x556c89eb6919 in region_aligned_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
   tarantool#4 0x556c8895d4b9 in region_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
   tarantool#5 0x556c8894b88a in curl_easy_header_cb /__w/tarantool-ee/tarantool-ee/tarantool/src/httpc.c:124:12
   tarantool#6 0x556c89477809 in cw_out_ptr_flush /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
   tarantool#7 0x556c89477364 in cw_out_do_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:377:14
   tarantool#8 0x556c89476df4 in cw_out_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:415:14
   tarantool#9 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#10 0x556c894bc525 in cw_download_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:253:14
   tarantool#11 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#12 0x556c8948578e in hds_cw_collect_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/headers.c:367:10
   tarantool#13 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#14 0x556c894bcb6d in cw_raw_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:367:10
   tarantool#15 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#16 0x556c894ba8fe in Curl_client_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:91:12
   tarantool#17 0x556c89493ab4 in http_write_header /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3363:12
   tarantool#18 0x556c89492fab in http_on_response /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3399:14
   tarantool#19 0x556c894909fe in http_rw_hd /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3688:14
   tarantool#20 0x556c894918b2 in http_parse_headers /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3929:14
   tarantool#21 0x556c894913f9 in Curl_http_write_resp_hds /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3986:14
   tarantool#22 0x556c8948a3af in Curl_http_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:4010:12
   tarantool#23 0x556c894d6385 in Curl_xfer_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:1168:14
   tarantool#24 0x556c894d45b4 in sendrecv_dl /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:343:14
   tarantool#25 0x556c894d3eb3 in Curl_sendrecv /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:451:14
   tarantool#26 0x556c894af0b0 in multi_runsingle /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:2374:16
   tarantool#27 0x556c894b388a in multi_run_expired /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3151:14
   tarantool#28 0x556c894b15d4 in multi_socket /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3234:12
   tarantool#29 0x556c894b1701 in curl_multi_socket_action /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3358:10
```

In scope of tarantool/tarantool-ee#1407

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan
nshy pushed a commit to nshy/tarantool that referenced this pull request Aug 21, 2025
@sergepetrenko @nshy
lsan: add suppression for Curl_http_write_resp
0e99c58 
Leak sanitizer started detecting new leaks in etcd-client tests in
the enterprise repo. This only happens on 3.2 branch, and must be
due to the fact we haven't backported commits regarding correct Lua
state cleanup on shutdown. Commit 80a11c4 ("box: close Lua state
on exit") in particular.

Since that patch series is rather heavy, let's simply suppress the leak
in 3.2 branch.

The leak in question:
```
Direct leak of 52 byte(s) in 1 object(s) allocated from:
   #0 0x556c873b3aae in malloc (/__w/tarantool-ee/tarantool-ee/tarantool/src/tarantool+0x1573aae) (BuildId: b2a73382837eb52617097838e12bd4d33ce21792)
   tarantool#1 0x556c89ebd8ec in small_asan_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
   tarantool#2 0x556c89eb5f84 in region_prepare_buf /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
   tarantool#3 0x556c89eb6919 in region_aligned_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
   tarantool#4 0x556c8895d4b9 in region_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
   tarantool#5 0x556c8894b88a in curl_easy_header_cb /__w/tarantool-ee/tarantool-ee/tarantool/src/httpc.c:124:12
   tarantool#6 0x556c89477809 in cw_out_ptr_flush /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
   tarantool#7 0x556c89477364 in cw_out_do_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:377:14
   tarantool#8 0x556c89476df4 in cw_out_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:415:14
   tarantool#9 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#10 0x556c894bc525 in cw_download_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:253:14
   tarantool#11 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#12 0x556c8948578e in hds_cw_collect_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/headers.c:367:10
   tarantool#13 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#14 0x556c894bcb6d in cw_raw_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:367:10
   tarantool#15 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#16 0x556c894ba8fe in Curl_client_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:91:12
   tarantool#17 0x556c89493ab4 in http_write_header /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3363:12
   tarantool#18 0x556c89492fab in http_on_response /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3399:14
   tarantool#19 0x556c894909fe in http_rw_hd /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3688:14
   tarantool#20 0x556c894918b2 in http_parse_headers /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3929:14
   tarantool#21 0x556c894913f9 in Curl_http_write_resp_hds /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3986:14
   tarantool#22 0x556c8948a3af in Curl_http_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:4010:12
   tarantool#23 0x556c894d6385 in Curl_xfer_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:1168:14
   tarantool#24 0x556c894d45b4 in sendrecv_dl /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:343:14
   tarantool#25 0x556c894d3eb3 in Curl_sendrecv /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:451:14
   tarantool#26 0x556c894af0b0 in multi_runsingle /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:2374:16
   tarantool#27 0x556c894b388a in multi_run_expired /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3151:14
   tarantool#28 0x556c894b15d4 in multi_socket /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3234:12
   tarantool#29 0x556c894b1701 in curl_multi_socket_action /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3358:10
```

In scope of tarantool/tarantool-ee#1407

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan
nshy pushed a commit to nshy/tarantool that referenced this pull request Aug 21, 2025
@sergepetrenko @nshy
lsan: add more suppressions for reported leaks
7e9ebbb 
Leak sanitizer started detecting new leaks in etcd-client tests in
the enterprise repo. This only happens on 3.2 branch, and must be
due to the fact we haven't backported commits regarding correct Lua
state cleanup on shutdown. Commit 80a11c4 ("box: close Lua state
on exit") in particular.

Since that patch series is rather heavy, let's simply suppress the leak
in 3.2 branch.

The leaks in question:
```
Direct leak of 52 byte(s) in 1 object(s) allocated from:
   #0 0x556c873b3aae in malloc (/__w/tarantool-ee/tarantool-ee/tarantool/src/tarantool+0x1573aae) (BuildId: b2a73382837eb52617097838e12bd4d33ce21792)
   tarantool#1 0x556c89ebd8ec in small_asan_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
   tarantool#2 0x556c89eb5f84 in region_prepare_buf /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
   tarantool#3 0x556c89eb6919 in region_aligned_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
   tarantool#4 0x556c8895d4b9 in region_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
   tarantool#5 0x556c8894b88a in curl_easy_header_cb /__w/tarantool-ee/tarantool-ee/tarantool/src/httpc.c:124:12
   tarantool#6 0x556c89477809 in cw_out_ptr_flush /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
   tarantool#7 0x556c89477364 in cw_out_do_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:377:14
   tarantool#8 0x556c89476df4 in cw_out_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:415:14
   tarantool#9 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#10 0x556c894bc525 in cw_download_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:253:14
   tarantool#11 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#12 0x556c8948578e in hds_cw_collect_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/headers.c:367:10
   tarantool#13 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#14 0x556c894bcb6d in cw_raw_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:367:10
   tarantool#15 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#16 0x556c894ba8fe in Curl_client_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:91:12
   tarantool#17 0x556c89493ab4 in http_write_header /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3363:12
   tarantool#18 0x556c89492fab in http_on_response /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3399:14
   tarantool#19 0x556c894909fe in http_rw_hd /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3688:14
   tarantool#20 0x556c894918b2 in http_parse_headers /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3929:14
   tarantool#21 0x556c894913f9 in Curl_http_write_resp_hds /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3986:14
   tarantool#22 0x556c8948a3af in Curl_http_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:4010:12
   tarantool#23 0x556c894d6385 in Curl_xfer_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:1168:14
   tarantool#24 0x556c894d45b4 in sendrecv_dl /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:343:14
   tarantool#25 0x556c894d3eb3 in Curl_sendrecv /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:451:14
   tarantool#26 0x556c894af0b0 in multi_runsingle /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:2374:16
   tarantool#27 0x556c894b388a in multi_run_expired /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3151:14
   tarantool#28 0x556c894b15d4 in multi_socket /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3234:12
   tarantool#29 0x556c894b1701 in curl_multi_socket_action /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3358:10

Direct leak of 843 byte(s) in 10 object(s) allocated from:
    #0 0x55b5b99cf745 in malloc (/home/shiny/dev/tarantool-ee/build-asan-release/tarantool/src/tarantool+0x3c7745) (BuildId: 5734aabea48158206be8be71e45f2c40edd09a4b)
    tarantool#1 0x55b5ba4c6c9a in small_asan_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
    tarantool#2 0x55b5ba4c5c42 in region_prepare_buf /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
    tarantool#3 0x55b5ba4c5d07 in region_aligned_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
    tarantool#4 0x55b5b9fb6800 in region_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
    tarantool#5 0x55b5b9fb6800 in curl_easy_header_cb /home/shiny/dev/tarantool-ee/tarantool/src/httpc.c:124:12
    tarantool#6 0x55b5ba292ab0 in cw_out_ptr_flush /home/shiny/dev/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
```

In scope of tarantool/tarantool-ee#1407

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan
sergepetrenko added a commit that referenced this pull request Aug 22, 2025
@sergepetrenko
lsan: add more suppressions for reported leaks
2240b91 
Leak sanitizer started detecting new leaks in etcd-client tests in
the enterprise repo. This only happens on 3.2 branch, and must be
due to the fact we haven't backported commits regarding correct Lua
state cleanup on shutdown. Commit 80a11c4 ("box: close Lua state
on exit") in particular.

Since that patch series is rather heavy, let's simply suppress the leak
in 3.2 branch.

The leaks in question:
```
Direct leak of 52 byte(s) in 1 object(s) allocated from:
   #0 0x556c873b3aae in malloc (/__w/tarantool-ee/tarantool-ee/tarantool/src/tarantool+0x1573aae) (BuildId: b2a73382837eb52617097838e12bd4d33ce21792)
   #1 0x556c89ebd8ec in small_asan_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
   #2 0x556c89eb5f84 in region_prepare_buf /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
   #3 0x556c89eb6919 in region_aligned_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
   #4 0x556c8895d4b9 in region_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
   #5 0x556c8894b88a in curl_easy_header_cb /__w/tarantool-ee/tarantool-ee/tarantool/src/httpc.c:124:12
   #6 0x556c89477809 in cw_out_ptr_flush /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
   #7 0x556c89477364 in cw_out_do_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:377:14
   #8 0x556c89476df4 in cw_out_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:415:14
   #9 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   #10 0x556c894bc525 in cw_download_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:253:14
   #11 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   #12 0x556c8948578e in hds_cw_collect_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/headers.c:367:10
   #13 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   #14 0x556c894bcb6d in cw_raw_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:367:10
   #15 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   #16 0x556c894ba8fe in Curl_client_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:91:12
   #17 0x556c89493ab4 in http_write_header /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3363:12
   #18 0x556c89492fab in http_on_response /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3399:14
   #19 0x556c894909fe in http_rw_hd /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3688:14
   #20 0x556c894918b2 in http_parse_headers /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3929:14
   #21 0x556c894913f9 in Curl_http_write_resp_hds /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3986:14
   #22 0x556c8948a3af in Curl_http_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:4010:12
   #23 0x556c894d6385 in Curl_xfer_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:1168:14
   #24 0x556c894d45b4 in sendrecv_dl /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:343:14
   #25 0x556c894d3eb3 in Curl_sendrecv /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:451:14
   #26 0x556c894af0b0 in multi_runsingle /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:2374:16
   #27 0x556c894b388a in multi_run_expired /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3151:14
   #28 0x556c894b15d4 in multi_socket /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3234:12
   #29 0x556c894b1701 in curl_multi_socket_action /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3358:10

Direct leak of 843 byte(s) in 10 object(s) allocated from:
    #0 0x55b5b99cf745 in malloc (/home/shiny/dev/tarantool-ee/build-asan-release/tarantool/src/tarantool+0x3c7745) (BuildId: 5734aabea48158206be8be71e45f2c40edd09a4b)
    #1 0x55b5ba4c6c9a in small_asan_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55b5ba4c5c42 in region_prepare_buf /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
    #3 0x55b5ba4c5d07 in region_aligned_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
    #4 0x55b5b9fb6800 in region_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
    #5 0x55b5b9fb6800 in curl_easy_header_cb /home/shiny/dev/tarantool-ee/tarantool/src/httpc.c:124:12
    #6 0x55b5ba292ab0 in cw_out_ptr_flush /home/shiny/dev/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
```

In scope of tarantool/tarantool-ee#1407

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan
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