Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: degradation on src/box/sql/libsql build after commit a33108a "sql: fix mem_apply_type double type truncation" #5067

Closed
avtikhon opened this issue Jun 10, 2020 · 1 comment
Assignees
Labels
bug Something isn't working build qa Issues related to tests or testing subsystem

Comments

@avtikhon
Copy link
Contributor

Tarantool version:
Commit a33108a
"sql: fix mem_apply_type double type truncation"

OS version:
Debian Buster + ASAN + Clang8

Bug description:
https://gitlab.com/tarantool/tarantool/-/jobs/588714883

 [100%] Built target merger.test
 /usr/bin/ld: ../../src/box/sql/libsql.a(build.c.o): in function `vdbe_emit_fk_constraint_create':
 /builds/pUzQszzd/0/tarantool/tarantool/src/box/sql/build.c:1061: undefined reference to `fk_constraint_match_strs'
 /usr/bin/ld: /builds/pUzQszzd/0/tarantool/tarantool/src/box/sql/build.c:1063: undefined reference to `fk_constraint_action_strs'
 /usr/bin/ld: /builds/pUzQszzd/0/tarantool/tarantool/src/box/sql/build.c:1065: undefined reference to `fk_constraint_action_strs'
 /usr/bin/ld: ../../src/box/sql/libsql.a(pragma.c.o): in function `sql_pragma_foreign_key_list':
 /builds/pUzQszzd/0/tarantool/tarantool/src/box/sql/pragma.c:308: undefined reference to `fk_constraint_action_strs'
 /usr/bin/ld: /builds/pUzQszzd/0/tarantool/tarantool/src/box/sql/pragma.c:310: undefined reference to `fk_constraint_action_strs'
 clang: error: linker command failed with exit code 1 (use -v to see invocation)
 make[4]: Leaving directory '/builds/pUzQszzd/0/tarantool/tarantool'
 make[4]: *** [test/unit/CMakeFiles/luaT_tuple_new.test.dir/build.make:141: test/unit/luaT_tuple_new.test] Error 1
 make[3]: *** [CMakeFiles/Makefile2:8112: test/unit/CMakeFiles/luaT_tuple_new.test.dir/all] Error 2
 make[3]: *** Waiting for unfinished jobs....
 /usr/bin/ld: box/sql/libsql.a(build.c.o): in function `vdbe_emit_fk_constraint_create':
 /builds/pUzQszzd/0/tarantool/tarantool/src/box/sql/build.c:1061: undefined reference to `fk_constraint_match_strs'
 /usr/bin/ld: /builds/pUzQszzd/0/tarantool/tarantool/src/box/sql/build.c:1063: undefined reference to `fk_constraint_action_strs'
 /usr/bin/ld: /builds/pUzQszzd/0/tarantool/tarantool/src/box/sql/build.c:1065: undefined reference to `fk_constraint_action_strs'
 /usr/bin/ld: box/sql/libsql.a(pragma.c.o): in function `sql_pragma_foreign_key_list':
 /builds/pUzQszzd/0/tarantool/tarantool/src/box/sql/pragma.c:308: undefined reference to `fk_constraint_action_strs'
 /usr/bin/ld: /builds/pUzQszzd/0/tarantool/tarantool/src/box/sql/pragma.c:310: undefined reference to `fk_constraint_action_strs'
 clang: error: linker command failed with exit code 1 (use -v to see invocation)
 make[4]: *** [src/CMakeFiles/tarantool.dir/build.make:191: src/tarantool] Error 1
 make[4]: Leaving directory '/builds/pUzQszzd/0/tarantool/tarantool'
 make[3]: *** [CMakeFiles/Makefile2:2108: src/CMakeFiles/tarantool.dir/all] Error 2
 make[3]: Leaving directory '/builds/pUzQszzd/0/tarantool/tarantool'
 make[2]: *** [Makefile:152: all] Error 2
 make[2]: Leaving directory '/builds/pUzQszzd/0/tarantool/tarantool'
 make[1]: *** [.travis.mk:117: build_asan_debian] Error 2
 make[1]: Leaving directory '/builds/pUzQszzd/0/tarantool/tarantool'
 make: *** [.gitlab.mk:18: test_asan_debian_no_deps] Error 2
 ERROR: Job failed: exit code 1

Steps to reproduce:

Optional (but very desirable):

  • coredump
  • backtrace
  • netstat
@avtikhon avtikhon added build bug Something isn't working qa Issues related to tests or testing subsystem labels Jun 10, 2020
@avtikhon avtikhon changed the title build: degradation on src/box/sql/libsql build after commit a33108add842cf5cb08c3d9ee070582e244f6c72 build: degradation on src/box/sql/libsql build after commit a33108add842cf5cb08c3d9ee070582e244f6c72 "sql: fix mem_apply_type double type truncation" Jun 10, 2020
@avtikhon avtikhon changed the title build: degradation on src/box/sql/libsql build after commit a33108add842cf5cb08c3d9ee070582e244f6c72 "sql: fix mem_apply_type double type truncation" build: degradation on src/box/sql/libsql build after commit a33108a "sql: fix mem_apply_type double type truncation" Jun 10, 2020
@Gerold103
Copy link
Collaborator

The commit clearly not related to the bug, it existed always. But somewhy didn't reveal itself. Seems like SQL library is totally broken - it heavily depends on box library and its symbols, but does not link with it. Instead, it waits until box will include it. This somehow worked before, but when UB sanitizer is on, it seems something is being built or linked a little differently. Although I couldn't find what exactly, so far.
luaT_tuple_new.test build perfectly fine if you use ENABLE_UB_SANITIZER=OFF, but fails when it is one. When I turned VERBOSE=1, I saw, that the target build command is exactly the same in both cases (not counting -fsanitize flags).
Perhaps we should remove sql library, and build sql sources inside box library. Anyway they depend on each other.

Gerold103 added a commit that referenced this issue Jun 13, 2020
SQL heavily depends on box, and box on SQL. So they can't be
separate libraries. The build started failing with undefined box
symbols in SQL, when code of the latter has slightly changed in
one of the recent commits.

The build failed only with UB sanitizer enabled, but
'VERBOSE=1 make' showed that both with UB and without UB the build
command was the same (not counting -fsanitize flags). So the
sanitizer has nothing to do with it.

The patch makes SQL sources being built as a part of box library.

Closes #5067
Gerold103 added a commit that referenced this issue Jun 14, 2020
Clang undefined behaviour sanitizer was turned on using
-fsanitize=undefined flag, which is supposed to turn on all the
sanitizations, except a few ones. Not needed sanitations were
turned off explicitly, using -fno-sanitize=<type> flags. However
appeared it does not work with some flags. For example,
nullability sanitations can't be turned off when
-fsanitize=undefined is used.

Nullability sanitations lead to lots of false-positive fails
such as typeof(*obj) where obj is NULL, or memcpy() with NULL
destination but 0 size.

The patch splits -fsanitize=undefined into separate flags and
never turns on nullability checks.

Follow up #5067
Gerold103 added a commit that referenced this issue Jun 15, 2020
SQL heavily depends on box, and box on SQL. So they can't be
separate libraries. The build started failing with undefined box
symbols in SQL, when code of the latter has slightly changed in
one of the recent commits.

The build failed only with UB sanitizer enabled, but
'VERBOSE=1 make' showed that both with UB and without UB the build
command was the same (not counting -fsanitize flags). So the
sanitizer has nothing to do with it.

The patch makes SQL sources being built as a part of box library.

Closes #5067
Gerold103 added a commit that referenced this issue Jun 15, 2020
SQL heavily depends on box, and box on SQL. So they can't be
separate libraries. The build started failing with undefined box
symbols in SQL, when code of the latter has slightly changed in
one of the recent commits.

The build failed only with UB sanitizer enabled, but
'VERBOSE=1 make' showed that both with UB and without UB the build
command was the same (not counting -fsanitize flags). So the
sanitizer has nothing to do with it.

The patch makes SQL sources being built as a part of box library.

Closes #5067
avtikhon pushed a commit that referenced this issue Aug 21, 2020
SQL heavily depends on box, and box on SQL. So they can't be
separate libraries. The build started failing with undefined box
symbols in SQL, when code of the latter has slightly changed in
one of the recent commits.

The build failed only with UB sanitizer enabled, but
'VERBOSE=1 make' showed that both with UB and without UB the build
command was the same (not counting -fsanitize flags). So the
sanitizer has nothing to do with it.

The patch makes SQL sources being built as a part of box library.

Closes #5067
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working build qa Issues related to tests or testing subsystem
Projects
None yet
Development

No branches or pull requests

2 participants