Description of problem: This is a new warning that started appearing in rpmlint about a week ago, and I'm quite disturbed by it for a number of reasons. Some cases where an exit() call in a shared library are valid design choices: 1. Panic conditions, such as failed assertions 2. Common error handlers and/or exit handlers put in a shared library In general, the comments provided seem to be for a library providing a public API while ignoring dynamically loaded libraries used internally by an application. It could be argued that this is just a warning, and is therefore not worth changing, but here's why I think leaving it as is is dangerous. Fixing this will always require at least an architectural review to assess the impact of changes, and often an architectural rethink. Fixes by the packager in this regard could have unintended consequences and will most surely lead to library version conflicts with the upstream version. This is a message to the upstream developers and requiring or implying that a packager should fix it will only lead to problems. More so, reviewers may not be aware of the potential complications. Finally, given the number of cases where this could be a valid design choice, a lot of personal resources could be dedicated to evaluating and fixing problems that aren't really problems. At the very least, the message should be reworded to reflect these concerns. Version-Release number of selected component (if applicable): 0.85 How reproducible: Reproducible. Steps to Reproduce: 1. Download and install the arm4 library source: Spec URL: http://arm4.org/Downloads/0.8-0.4/arm4.spec SRPM URL: http://arm4.org/Downloads/0.8-0.4/arm4-0.8-0.4.fc9.src.rpm 2. build the libraries 3. run rpmlint on arm4-0.8-0.4.fc9.i386.rpm Actual results: arm4.i386: W: shared-lib-calls-exit /usr/lib/libarm4db.so.1.0.0 exit This library package calls exit() or _exit(), probably in a non-fork() context. Doing so from a library is strongly discouraged - when a library function calls exit(), it prevents the calling program from handling the error, reporting it to the user, closing files properly, and cleaning up any state that the program has. It is preferred for the library to return an actual error code and let the calling program decide how to handle the situation. ... other similar warnings Expected results: No warning. Additional info:
Bill, comments? (This check was added per his request in bug 450011.) I'm not quite convinced that this check should be ditched altogether, but I agree that a note in the info message that encourages packagers to ask upstream to fix the issue (if any) rather just go patching themselves would be a good thing to add to it. Could you suggest a reworded info message? Also, if there are some more ways to detect generic usage patterns for which this warning should be muted (like is currently being done for fork() and friends) without dropping the check altogether, ideas and implementations for them is very much welcome.
If it's causing this much churn, we can take it out. It's just something that might be useful to prod upstreams about fixing where it does occur, because it's bitten us in the past.
Hm, "this much churn"... this is the only bit of feedback I've heard about the check so far so I'm not quite ready to toss it out yet.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.