Bansh33,
please have in mind that the basic idea of this forum was and still is delivering help for real world problems. And since the majority of Ossn admins wouldn't maltreat their databases with 3rd party tools there's no need to alter the code for 'just-in-case-they-do' issues.
You might end up with uncountable additional checks otherwise - for whatever horror scenario you can think of ... deleted object tables, mixed up group-guids ... no limits. :)

um, I did NOT suggest implementing a "large amount of code". It is literally one line, which simply checks whether or not the instantiated user object is NULL (non-empty, technically). It happens to be required in a lot of files because there are many files which instantiate an OssnUser object - that is not my doing.

The origin of the problem was that a password hash and salt in 1 row was altered (directly through phpmyadmin rather than the provided admin interface) and the salt was incorrect. In this case, it entirely crashed when that specific user tried to login (just terminated at /home after logging in), and when any other user tried to log in, showed only a partial HTML render of the newsfeed because it was terminating with the fatal error that I pasted. OSSN is clearly not smart enough to handle corrupted rows in the ossn-users table, at least not with the default settings I am using.

Still don't see how anything I pointed out would be a "weird conclusion to reach". In any case, I'm not trying to be a dick here, I just wanted to point that out in case somebody else finds it useful; no disrespect intended to you Z-Man.

Thanks for sharing your thoughts, Bansh33.
But to be honest: Your 'conclusion' sounds pretty weird to me. Actually, I don't see any good reason for implementing a large amount of additional code in order to even handle manually corrupted databases. Having a closer look you'll notice that OSSN is indeed smart enough to delete any chained records when a user gets deleted under normal circumstances. Hence, no need for doing extra checks whether a user does exist or not.
Of course there's always a chance that a database may become inconsistent all of a sudden for whatever reason ... but I would strongly recommend to restore a working backup then - instead of pumping up the code just in order to be prepared for all kind of possible desasters.

in case anyone else has this problem, I managed to fix it. It tends to happen with corrupted entries in the ossn-users table (I think I tried to change one user's passwd manually and that created the corrupted row). You can fix this by either just removing the offending rows in ossn-users and recreating the user, or by adding an if (!empty($user)) before calls to member functions like $userObj->iconURL() or profileURL(). This will allow you to view the newsfeed page even if there's data (posts) from a user whose entry in ossn-users is corrupt. Check the error_log for each instance of where this is needed, there's several.

also, I should mention that logging in with other users seems to work ok, it's just an error with the user whose passwd i changed.