Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11
Description
This is a split from MDEV-8378, priority and fix version inherited.
Lintian reports: http://labs.seravo.fi/~otto/mariadb-repo/mariadb-10.0-sid-amd64/lintian-0f7cb30.log and https://lintian.debian.org/tags/shlib-calls-exit.html
The listed shared library calls the C library exit() or _exit() functions.
In the case of an error, the library should instead return an appropriate error code to the calling program which can then determine how to handle the error, including performing any required clean-up.
In most cases, removing the call should be discussed with upstream, particularly as it may produce an ABI change.
Severity: wishlist, Certainty: possible
Check: shared-libs, Type: binary, udeb
This tag is marked experimental, which means that the code that generates it is not as well-tested as the rest of Lintian and might still give surprising results. Feel free to ignore experimental tags that do not seem to make sense, though of course bug reports are always welcome.
nm ./storage/mroonga/ha_mroonga.so|grep exit
U __cxa_atexit@@GLIBC_2.2.5
|
U exit@@GLIBC_2.2.5
|
Attachments
Issue Links
- is part of
-
-
- Closed
-
Activity
I don't see any Lintian overrides about
{shlib-calls-exit}in https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/source/lintian-overrides nor complaints about this specific issue in latest Lintian report at https://mariadb-team.pages.debian.net/-/mariadb-server/-/jobs/3505163/artifacts/debian/output/lintian.html
If illuusio agrees that this issue is either already fixed or has become obsolete, then feel free to close issue.
Note that there are other Lintian remarks about Mroonga still.
C exit still is there examined with objdump and I examined other storage engines (10.10):
- MRoonga ha_mrooga.so ha exit
- RockDB ha_rocksdb.so has exit
- Connect ha_connect.so has exit
There is several exit-functios used even in 10.3. They should be check are they causing problems.
In MRoonga exit is inside function segv_handler which is only called when there is memory handling problem.
On Connect there is exit function tabrest.cpp but it's not build default and exit probably comes from libxml2 (which should not be there but it is) as it does not exit libmysqlservices.a or zlib libz.so. There is newer JIRA task for this MDEV-30432
my_rocks has exit on ha_rocks.cc
There is nothing to be done. In mroonga there is signal handler but it's only used if build with:
- vendor/groonga/src/groonga.c
- vendor/groonga/src/httpd/nginx-module/ngx_http_groonga_module.c
These files are not included when building inside MariaDB. It's safe to suppress them inside Lintian (which has already done)
In RocksDB is kind of builded in option if one has `rocksdb_allow_to_start_after_corruption` set to false then it should not start MariaDB server.
Connect should be handled in other JIRA task. Which has been already opened.
The report does not seem to be complaining about mroonga anymore:
https://lintian.debian.org/sources/mariadb-10.6
(that is, it complains a lot about mroonga, but not about shlib-calls-exit / exit-in-shared-library)
https://lintian.debian.org/tags/exit-in-shared-library
(but maybe the warning got suppressed, as was suggested in
MDEV-9280)