[squid-dev] New Defects reported by Coverity Scan for Squid after IndependentRunner
Christos Tsantilas
christos at chtsanti.net
Fri Sep 9 17:21:30 UTC 2016
On 09/09/2016 07:00 PM, Alex Rousskov wrote:
> On 09/09/2016 07:34 AM, Christos Tsantilas wrote:
>> On 09/09/2016 02:21 PM, Amos Jeffries wrote:
>>> These issues are caused by the new RegisterRunner() design using
>>> GetRidOfRunner(rr) if shutdown has already begun. That can potentially
>>> result in the constructor of a class inheriting from IndependentRunner
>>> deleting 'this', then the new'd object being used.
>
>
>> However the GetRidOfRunner will never delete an IndependedRunner, so
>> there is not a real problem here.
>
> To be more precise, there is a Coverity problem here, not a Squid
> problem, right?
There is a "delete this" inside constructor, but it is never called.
The Coverity just does not know that it is not called.
I am not sure if it is problem or not. Someone can argue that even if it
is not called may confuse developers in the future and make them to add
a "delete this" inside the GetRidOfRunner which will be called.
>
>
>>> I think what we should be doing is using Must(RegisterRunner(this))
>>> instead of just RegisterRunner(this) for children of IndependentRunner
>>> so their constructors throw on errors.
>
> That does not sound right: AFAICT, the code logic does not really
> require successful registration of [independent] runners so it would be
> inappropriate to throw when registration fails. In other words, a failed
> independent runner registration does not indicate a bug in the code AFAICT.
>
> IIRC, the current RR API does not guarantee emitting (and the code
> should not rely on receiving) any RR events. If we want to make that
> guarantee, we would probably have to supply a list of events (that a
> specific RR must receive) to the registration function. I do not think
> we need it, but please let me know if I missed any good use cases for
> that functionality.
>
>
>>> Also the IndependentRunner::registerRunner() method is not used
>>> anywhere. Was it supposed to be called by the child classes ?
>>> (IdleConnList and ConnStateData)
>
>> Well, the registerRunner() method should be used instead of
>> RegisterRunner for ConnStateData and IDleConnList. But this change
>> somewhere lost while I was playing with the patches.
>
> [rant] Which means our testing was inadequate again. Accidents happen,
> but such a major bug should not have went unnoticed if proper testing
> was in place.[/rant]
Yep.
But it is not exactly bug. The registereRunner() method just calls
"RegisterRunner(this)", it does not do anything else.
Just we did not replace RegisterRunner(this); with the
IndependedRunner::registerRunner call.
>
>
>> However this is alone I think will not solve the problem.
>
> Just to make sure we are on the same page: Which problem are you trying
> to solve? A false USE_AFTER_FREE defect reported by Coverity?
yep.
>
>
>> Maybe we need to re-implement registerRunner() with something like:
>>
>> IndependedRunner::registerRunner() {
>> RegisterRunnerIgnoreOnShutdown();
>> }
>>
>> The RegisterRunnerIgnoreOnShutdown() is similar to RegisterRunner but it
>> will not call GetRidOfRunner().
>
> To avoid code duplication, you will need something like this:
>
> void
> RegisterRunnerUnlessShutDown(rr)
> {
> if (FindRunners())
> RegisterRunner_(rr);
> // else do nothing past finishShutdown
> }
>
> bool
> RegisterOrGetRidOfRunner(rr)
> {
> if (FindRunners()) {
> RegisterRunner_(rr);
> return true;
> } else {
> GetRidOfRunner(rr);
> return false; // past finishShutdown
> }
> }
>
> where RegisterRunner_() is a static void function that never calls
> GetRidOfRunner() and throws if it cannot FindRunners().
>
> One advantage of this more verbose/explicit solution is that it
> minimizes fears about using dynamic_cast<> on a being-constructed
> object. I think the current code is actually OK there, but avoiding that
> question is a good thing so I support this change.
OK, I will try to prepare a patch on this base.
>
>
> Thank you,
>
> Alex.
>
>
>
>
>>> On 9/09/2016 5:45 a.m., scan-admin wrote:
>>>>
>>>> ** CID 1372673: Memory - illegal accesses (USE_AFTER_FREE)
>>>> /src/servers/FtpServer.cc: 55 in Ftp::Server::Server(const
>>>> RefCount<MasterXaction> &)()
>>>>
>>>>
>>>> ________________________________________________________________________________________________________
>>>>
>>>> *** CID 1372673: Memory - illegal accesses (USE_AFTER_FREE)
>>>> /src/servers/FtpServer.cc: 55 in Ftp::Server::Server(const
>>>> RefCount<MasterXaction> &)()
>>>> 49 static bool CommandHasPathParameter(const SBuf &cmd);
>>>> 50 };
>>>> 51
>>>> 52 Ftp::Server::Server(const MasterXaction::Pointer &xact):
>>>> 53 AsyncJob("Ftp::Server"),
>>>> 54 ConnStateData(xact),
>>>>>>> CID 1372673: Memory - illegal accesses (USE_AFTER_FREE)
>>>>>>> Dereferencing freed pointer "this".
>>>> 55 master(new MasterState),
>>>> 56 uri(),
>>>> 57 host(),
>>>> 58 gotEpsvAll(false),
>>>> 59 onDataAcceptCall(),
>>>> 60 dataListenConn(),
>>>>
>>>> ** CID 1372672: Memory - illegal accesses (USE_AFTER_FREE)
>>>> /src/servers/Http1Server.cc: 27 in Http::One::Server::Server(const
>>>> RefCount<MasterXaction> &, bool)()
>>>>
>>>>
>>>> ________________________________________________________________________________________________________
>>>>
>>>> *** CID 1372672: Memory - illegal accesses (USE_AFTER_FREE)
>>>> /src/servers/Http1Server.cc: 27 in Http::One::Server::Server(const
>>>> RefCount<MasterXaction> &, bool)()
>>>> 21 #include "servers/Http1Server.h"
>>>> 22 #include "SquidConfig.h"
>>>> 23 #include "Store.h"
>>>> 24
>>>> 25 CBDATA_NAMESPACED_CLASS_INIT(Http1, Server);
>>>> 26
>>>>>>> CID 1372672: Memory - illegal accesses (USE_AFTER_FREE)
>>>>>>> Dereferencing freed pointer "this".
>>>> 27 Http::One::Server::Server(const MasterXaction::Pointer &xact,
>>>> bool beHttpsServer):
>>>> 28 AsyncJob("Http1::Server"),
>>>> 29 ConnStateData(xact),
>>>> 30 isHttpsServer(beHttpsServer)
>>>> 31 {
>>>> 32 }
>>>>
>>>>
>>>> ________________________________________________________________________________________________________
>>>>
>>>> To view the defects in Coverity Scan visit,
>>>> https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbvv5V1jRT-2FFTEh5SouD11PsnhHEJCA6aD7rB3cIxbLXQ-3D-3D_gndHAcXBoX6qDcYycKjMaKhQpd-2BDW-2BORg0izVeF8khSp2-2BSTODpQkV5I-2Fmydok7q79FMgS3x7g7GnwLNQ6LGBoh25NErdySWe-2FmGN-2Byw29L3E76sjeJMeKn74qRS8yQ07x6d-2Ba5gkubs9LPJj8j2O8-2B5-2FVzqEqPeXMnWlnFfh3X252jxFQIppsOaAa8iZzFwCFNfhmHLg1OqwRzwN-2FtsF8AlRD7-2B-2BejzeO-2FJpfrpEFs-3D
>>>>
>>>>
>>>> To manage Coverity Scan email notifications for
>>>> "noc at lists.squid-cache.org", click
>>>> https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4W76P2yZz75NEA4ckHihJ8hDUYC6WdPXELy5U35hjpH-2Bx0oGMlKYQxYZwu48zd34K0Fjksb1evIPVJe6QGymC0lD6Es5FNSogirJxAlrf7ao-3D_gndHAcXBoX6qDcYycKjMaKhQpd-2BDW-2BORg0izVeF8khSp2-2BSTODpQkV5I-2Fmydok7q79FMgS3x7g7GnwLNQ6LGBmkrenZtrNlpx1-2BVjUi4Qg1xsrieY0Pubzw8nl6tSWWV-2Fs2nSEb4qDzyeDJ9n6WRJBtiwZ74i6RhCXGJPf2SAmsQ-2BNYadNWqGwN4eFNzJPOthrQj3nlFSCY22YNeA1h5L-2BL43yXDsuegZsWQ-2BKWbTKU-3D
>>>>
More information about the squid-dev
mailing list