degradation in master after commit 03790ac5510648d1d9648bb2281857a7992d0593 #5001
Comments
|
This should help for LTO: |
|
Strangely, it is already set: Line 94 in 9fba29a |
|
NB1: look at |
|
LTO link in the original comment is wrong. Here is correct: https://gitlab.com/tarantool/tarantool/-/jobs/559124307 |
|
I see why ASAN complains about mp_type_hint. This is because the symbol is defined both in Tarantool executable, and in the shared library function1.so. I think this is fine, and should be ignored. But it definitely has nothing to do with the current ticket. The problem existed always, but asan noticed it only now somewhy. And it is not a problem actually. |
Gerold103
added a commit
that referenced
this issue
May 19, 2020
There were lots of errors of kind:
/builds/M4RrgQZ3/0/tarantool/tarantool/src/exports.h:395:1: error: variable ‘uuid_nil’ redeclared as function
EXPORT(uuid_nil)
^
/builds/M4RrgQZ3/0/tarantool/tarantool/src/lib/uuid/tt_uuid.c:39:22: note: previously declared here
const struct tt_uuid uuid_nil;
when LTO was enabled. That happened because exports.c file, to
take symbol addresses, declared lots of functions and variables
from all the code base as
extern void <symbol>(void);
This is crazy, but it worked for normal builds. Because symbol is
symbol. The compilers couldn't find conflicting declarations,
because they never met in one compilation unit.
However the lie was revealed by linker with LTO enabled. It could
see, that actual symbol definitions didn't match their exports in
exports.c. It could live with mismatching function-function or
variable-variable cases, but couldn't withstand function-variable
mismatches. When a symbol was declared as a variable in one place
and as a function in another.
This was the case for variables:
- uuid_nil
- tarantool_lua_ibuf
- log_pid
- log_format
- crc32_calc
- _say
- log_level
The errors were false positive, because the symbols were never
used for anything except taking their addresses. To calm the
linker down exports.c now does not participate in LTO.
Closes #5001
|
NB: try RTLD_DEEPBIND to fix mp_type_hint double symbol. |
Gerold103
added a commit
that referenced
this issue
May 25, 2020
Test modules are shared libraries. They link with Tarantool at
runtime and resolve missing symbols then. However in case they
already contain some of the same symbols used by tarantool, that
leads to a conflict in ASAN build. Nothing serious, there are
strict rules how a linker should be have in this case, but there
is still a warning. This is how it looked (the text is shortened):
==25624==ERROR: AddressSanitizer: odr-violation (0x000001123b60):
[1] size=1024 'mp_type_hint' /builds/nZUxDh2c/0/tarantool/tarantool/src/lib/msgpuck/hints.c:39:20
[2] size=1024 'mp_type_hint' /builds/nZUxDh2c/0/tarantool/tarantool/src/lib/msgpuck/hints.c:39:20
These globals were registered at these points:
[1]:
#0 0x478b8e in __asan_register_globals (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0x478b8e)
#1 0x7ff7a9bc9d0b in asan.module_ctor (/tmp/tntz2FLhA/function1.so+0x6d0b)
[2]:
#0 0x478b8e in __asan_register_globals (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0x478b8e)
#1 0xab990b in asan.module_ctor (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0xab990b)
The symbol mp_type_hint is defined both in tarantool executable,
and in function1.so dynamic library. This is because both build
with msgpuck static library.
However the modules don't need to be built with msgpuck. They can
link with it at runtime from tarantool executable.
This patch removes msgpuck from test dynamic modules, and exports
all msgpuck non-inlined symbols explicitly, so they couldn't be
removed in future.
Follow-up #2971
Follow-up #5001
Gerold103
added a commit
that referenced
this issue
May 25, 2020
Test modules are shared libraries. They link with Tarantool at
runtime and resolve missing symbols then. However in case they
already contain some of the same symbols used by tarantool, that
leads to a conflict in ASAN build. Nothing serious, there are
strict rules how a linker should behave in this case, but there
is still a warning. This is how it looked (the text is shortened):
==25624==ERROR: AddressSanitizer: odr-violation (0x000001123b60):
[1] size=1024 'mp_type_hint' /builds/nZUxDh2c/0/tarantool/tarantool/src/lib/msgpuck/hints.c:39:20
[2] size=1024 'mp_type_hint' /builds/nZUxDh2c/0/tarantool/tarantool/src/lib/msgpuck/hints.c:39:20
These globals were registered at these points:
[1]:
#0 0x478b8e in __asan_register_globals (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0x478b8e)
#1 0x7ff7a9bc9d0b in asan.module_ctor (/tmp/tntz2FLhA/function1.so+0x6d0b)
[2]:
#0 0x478b8e in __asan_register_globals (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0x478b8e)
#1 0xab990b in asan.module_ctor (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0xab990b)
The symbol mp_type_hint is defined both in tarantool executable,
and in function1.so dynamic library. This is because both build
with msgpuck static library.
However the modules don't need to be built with msgpuck. They can
link with it at runtime from tarantool executable.
This patch removes msgpuck from test dynamic modules, and exports
all msgpuck non-inlined symbols explicitly, so they couldn't be
removed by the linker in future.
Follow-up #2971
Follow-up #5001
avtikhon
added a commit
that referenced
this issue
May 27, 2020
After commit: 03790ac ("cmake: remove dynamic-list linker option") the issue with test initialy appeared: [001] box/push.test.lua [001] [001] [Instance "box" returns with non-zero exit code: 1] [001] [001] Last 15 lines of Tarantool Log file [Instance "box"][test/var/001_box/box.log]: [001] ==25624==ERROR: AddressSanitizer: odr-violation (0x000001123b60): [001] [1] size=1024 'mp_type_hint' src/lib/msgpuck/hints.c:39:20 [001] [2] size=1024 'mp_type_hint' src/lib/msgpuck/hints.c:39:20 [001] These globals were registered at these points: [001] [1]: [001] #0 0x478b8e in __asan_register_globals (src/tarantool+0x478b8e) [001] #1 0x7ff7a9bc9d0b in asan.module_ctor (function1.so+0x6d0b) [001] [001] [2]: [001] #0 0x478b8e in __asan_register_globals (src/tarantool+0x478b8e) [001] #1 0xab990b in asan.module_ctor (src/tarantool+0xab990b) [001] [001] ==25624==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0 [001] SUMMARY: AddressSanitizer: odr-violation: global 'mp_type_hint' at src/lib/msgpuck/hints.c:39:20 [001] ==25624==ABORTING [001] [ fail ] the following issue was created: #5001 The fail was described there by Vladislav Shpilevoy: """ I see why ASAN complains about mp_type_hint. This is because the symbol is defined both in Tarantool executable, and in the shared library function1.so. I think this is fine, and should be ignored. But it definitely has nothing to do with the current ticket. The problem existed always, but asan noticed it only now somewhy. And it is not a problem actually. """ He added suggestion to try RTLD_DEEPBIND, but in real it is not supported on OSX and the same issue with discussion can be found here: root-project/root#4668 The initial issue closed and the new one created especialy for the test. The fix was made in ASAN suppresion list to block the ASAN check for file: src/lib/msgpuck/hints.c Closes #5023
Gerold103
added a commit
that referenced
this issue
May 27, 2020
Test modules are shared libraries. They link with Tarantool at
runtime and resolve missing symbols then. However in case they
already contain some of the same symbols used by tarantool, that
leads to a conflict in ASAN build. Nothing serious, there are
strict rules how a linker should behave in this case, but there
is still a warning. This is how it looked (the text is shortened):
==25624==ERROR: AddressSanitizer: odr-violation (0x000001123b60):
[1] size=1024 'mp_type_hint' /builds/nZUxDh2c/0/tarantool/tarantool/src/lib/msgpuck/hints.c:39:20
[2] size=1024 'mp_type_hint' /builds/nZUxDh2c/0/tarantool/tarantool/src/lib/msgpuck/hints.c:39:20
These globals were registered at these points:
[1]:
#0 0x478b8e in __asan_register_globals (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0x478b8e)
#1 0x7ff7a9bc9d0b in asan.module_ctor (/tmp/tntz2FLhA/function1.so+0x6d0b)
[2]:
#0 0x478b8e in __asan_register_globals (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0x478b8e)
#1 0xab990b in asan.module_ctor (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0xab990b)
The symbol mp_type_hint is defined both in tarantool executable,
and in function1.so dynamic library. This is because both build
with msgpuck static library.
However the modules don't need to be built with msgpuck. They can
link with it at runtime from tarantool executable.
This patch removes msgpuck from test dynamic modules, and exports
all msgpuck non-inlined symbols explicitly, so they couldn't be
removed by the linker in future.
Follow-up #2971
Follow-up #5001
Closes #5023
Gerold103
added a commit
that referenced
this issue
May 28, 2020
Test modules are shared libraries. They link with Tarantool at
runtime and resolve missing symbols then. However in case they
already contain some of the same symbols used by tarantool, that
leads to a conflict in ASAN build. Nothing serious, there are
strict rules how a linker should behave in this case, but there
is still a warning. This is how it looked (the text is shortened):
==25624==ERROR: AddressSanitizer: odr-violation (0x000001123b60):
[1] size=1024 'mp_type_hint' /builds/nZUxDh2c/0/tarantool/tarantool/src/lib/msgpuck/hints.c:39:20
[2] size=1024 'mp_type_hint' /builds/nZUxDh2c/0/tarantool/tarantool/src/lib/msgpuck/hints.c:39:20
These globals were registered at these points:
[1]:
#0 0x478b8e in __asan_register_globals (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0x478b8e)
#1 0x7ff7a9bc9d0b in asan.module_ctor (/tmp/tntz2FLhA/function1.so+0x6d0b)
[2]:
#0 0x478b8e in __asan_register_globals (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0x478b8e)
#1 0xab990b in asan.module_ctor (/builds/nZUxDh2c/0/tarantool/tarantool/src/tarantool+0xab990b)
The symbol mp_type_hint is defined both in tarantool executable,
and in function1.so dynamic library. This is because both build
with msgpuck static library.
However the modules don't need to be built with msgpuck. They can
link with it at runtime from tarantool executable.
This patch removes msgpuck from test dynamic modules, and exports
all msgpuck non-inlined symbols explicitly, so they couldn't be
removed by the linker in future.
Follow-up #2971
Follow-up #5001
Closes #5023
Closed
LeonidVas
added a commit
that referenced
this issue
Jul 29, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac Part of #5932
LeonidVas
added a commit
that referenced
this issue
Jul 29, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac Part of #5932
LeonidVas
added a commit
that referenced
this issue
Jul 29, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac Part of #5932
LeonidVas
added a commit
that referenced
this issue
Jul 29, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac Part of #5932
LeonidVas
added a commit
that referenced
this issue
Jul 29, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac Part of #5932
LeonidVas
added a commit
that referenced
this issue
Jul 30, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 2, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). The "check_merge_source.c" test has been changed, now working with "fiber" and "diag" is done through API (changes were caused by hiding "diag_get"). To get a fiber Lua state, the "fiber_lua_state_internal" function has been added to the internal API. 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 2, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). The "check_merge_source.c" test has been changed, now working with "fiber" and "diag" is done through API (changes were caused by hiding "diag_get"). To get a fiber Lua state, the "fiber_lua_state_internal" function has been added to the internal API. 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 2, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). The "check_merge_source.c" test has been changed, now working with "fiber" and "diag" is done through API (changes were caused by hiding "diag_get"). To get a fiber Lua state, the "fiber_lua_state_internal" function has been added to the internal API. 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 3, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). The "check_merge_source.c" test has been changed, now working with "fiber" and "diag" is done through API (changes were caused by hiding "diag_get"). To get a fiber Lua state, the "fiber_lua_state_internal" function has been added to the internal API. 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 3, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). The "check_merge_source.c" test has been changed, now working with "fiber" and "diag" is done through API (changes were caused by hiding "diag_get"). To get a fiber Lua state, the "fiber_lua_state_internal" function has been added to the internal API. 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 5, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). The "check_merge_source.c" test has been changed, now working with "fiber" and "diag" is done through API (changes were caused by hiding "diag_get"). To get a fiber Lua state, the "fiber_lua_state_internal" function has been added to the internal API. 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 5, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). The "check_merge_source.c" test has been changed, now working with "fiber" and "diag" is done through API (changes were caused by hiding "diag_get"). To get a fiber Lua state, the "fiber_lua_state_internal" function has been added to the internal API. 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 6, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 6, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 8, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 8, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 8, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 9, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
kyukhin
pushed a commit
that referenced
this issue
Aug 9, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
LeonidVas
added a commit
that referenced
this issue
Aug 9, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
yanshtunder
pushed a commit
that referenced
this issue
Oct 4, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
yanshtunder
pushed a commit
that referenced
this issue
Oct 4, 2021
After unhiding all internal symbols([1]) we experience a bunch of problems ([2], [3]). The second one (clash of symbols from different version of the "small" library) still have no good solution. You can find more on the topic [4]. The situation for tarantool executable is the same as for any other library. A library should expose only its public API and should not increase probability of hard to debug problems due to clash of a user's code with an internal name from the library. Let's hide all symbols by default and create a list of exported symbols. (In fact, this patch is a revert of the patch 03790ac ([5]) taking into account the changes made to the code) Explanation of adding some controversial symbols to the export list: * The following symbols are used in shared libraries used in tests ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so", "gh-5938-wrong-string-length.so", "module_api.so") mp_check mp_encode_array mp_encode_bin mp_encode_bool mp_encode_int mp_encode_map mp_encode_nil mp_encode_str mp_encode_uint mp_decode_array_slowpath mp_decode_str mp_next_slowpath mp_load_u8 mp_next mp_sizeof_array mp_sizeof_str mp_type_hint decimal_from_string * These symbols are used in "crypto.lua" and, if absent, will lead to the failure of the "static_build_cmake_linux" on CI (the crypto prefix was used to avoid the clashes of names) crypto_ERR_error_string crypto_ERR_get_error crypto_EVP_DigestInit_ex crypto_EVP_DigestUpdate crypto_EVP_DigestFinal_ex crypto_EVP_get_digestbyname crypto_HMAC_Init_ex crypto_HMAC_Update crypto_HMAC_Final * For correct work of "schema.lua" in the "static_build_cmake_linux" rl_get_screen_size * The following symbols are used in "ssl-cert-paths-discover.test.lua" (I think these symbols will have to be wrapped in the to avoid clashes problems) X509_get_default_cert_dir_env X509_get_default_cert_file_env ssl_cert_paths_discover From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and "tt_uuid_str" (see [7]). 1. #2971 2. #5001 3. tarantool/memcached#59 4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html 5. 03790ac 6. #4225 7. acf8745 Part of #5932
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tarantool version:
master
OS version:
Linux
Bug description:
Degradation in master after commit
https://gitlab.com/tarantool/tarantool/-/commit/03790ac5510648d1d9648bb2281857a7992d0593
Issues:
https://gitlab.com/tarantool/tarantool/-/jobs/559124309
https://gitlab.com/tarantool/tarantool/-/jobs/559124309
Steps to reproduce:
Optional (but very desirable):
The text was updated successfully, but these errors were encountered: