nodestate can be NULL when node is no longer connected,
leading to a segmentation fault (refer T64).
Added assertions to other places where node state was
obtained and later used without checking if non-null.
Differential D324
Fix segfault when node no longer connected freetrader on Jul 13 2017, 23:07. Authored by Tags None Subscribers None
Details
nodestate can be NULL when node is no longer connected, Added assertions to other places where node state was make check
Diff Detail
Event Timeline
Comment Actions Man I feel like toxic LukeJr lately. All I can come up with are critical comments. Sorry ahead of time. You guys know that in C++, the value '0' is a sort of universally castable type to any pointer? 'NULL' is a C-ism, and has a long history. I still see plenty of C++ programmers and code using NULL, or things like 'nullptr' needlessly. It's ok to use 0. It's perfectly good C++. You can just assert(nodestate) or if you want to be verbose: assert(nodestate != 0) But PLEASE .. stop using NULL. It just makes me feel like I'm back in 1989 programming in C or something. C++ has 0. 0 is always null. On every architecture. No need to use "NULL". It looks.. well, strange these days. Like we are a bunch of C programmers that just learned how to use this C++ thing because it's what the kids these days are doing... Comment Actions Gladly moving to nullptr, I just didn't want to mix refactoring with semantic change here. So please let's look at D325, so I can rebase this one on that one . Comment Actions OK, aside from my bitching about the use of NULL.. the real thing is here the end result will be the same with these asserts, namely the program will EXIT (effectively crash). We should recode all these methods to at least return gracefully with some error or something if notestate is NULL. Not exit the program! asserts() really just are about as bad as dereferencing nodestate, obviously, when it comes to reliability of the client. Comment Actions No disagreement there (about the asserts not doing much for reliability of the software). I just consider this a hotfix - we should look at the big picture and rewrite the methods doing this, but that will take much longer and users are experiencing the issue.
Comment Actions These asserts do not seem related to fixing the segfault. Fixing the segfault is hi pri, so there is no treason to bundle it with change on which there are still open questions.
Comment Actions Please have a look if you think the log message is ok.
Comment Actions Question: when is that lNodesAnnouncingHeaderAndIDs private list cleaned up if a node should disconnect early. I don't see it being cleaned up in FinalizeNode()... Could this be a source of bad peer id's that then don't exist in the CNoteState map? Just a thought...
|