fixed: race condition when starting a new fresh profile besides master w...

[wsoltys]

...hich leads to an abort in cpluff. CAddonInstaller::UpdateRepos is called at startup and still runs if you login and CGUIWindowLoginScreen::LoadProfile calls ADDON::CAddonMgr::Get().ReInit() which leads to an invalid cpluff handle for the update job and aborts XBMC (#13826).

I created a pr as I dunno if this is the right way to fix it and if it could have other side effects. For me it runs fine and the update job is triggered again if the second profile is loaded.

[wsoltys]

Logfile for the abort: http://www.xbmclogs.com/show.php?id=24354

[jmarshallnz]

Try wrapping anything that uses m_cpluff and m_cp_context with a lock on the critical section.

[wsoltys]

Not sure if this is enough. CAddonInstaller and CAddonMgr have its own critsection and the update job runs in the CRepositoryUpdateJob context. Another point is that CRepositoryUpdateJob works with the database which at this point is not existing for that new profile. It'll create when the profile is loaded, the update jobs runs when the login screen is shown.

[wsoltys]

I wrapped m_cpluff in AddonManager with the critsect. Now XBMC won't abort any more but as stated above the database accesses still fail http://www.xbmclogs.com/show.php?id=24660.
IMO we shouldn't run the update job when showing the login screen as at this point we dunno which profile will be chosen and therefore for which profile the job should run. Especially as we run the job again when we have logged into the new profile.
What I don't know is if the way I have implemented it here is the right way and on the right spot.

[jmarshallnz]

Ok, add a comment such as

// don't run repo update jobs while on the login screen which runs under the master profile

and pull it in.

The critical section stuff should be a separate PR - I suggest merging that one after Frodo.