[haiku-commits] Re: haiku: hrev52350 - src/kits/tracker

  • From: Rene Gollent <anevilyak@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sun, 16 Sep 2018 21:35:54 -0400

On Sun, Sep 16, 2018 at 7:21 PM waddlesplash <waddlesplash@xxxxxxxxx> wrote:


hrev52350 adds 2 changesets to branch 'master'
old head: 15cb367a40000778f533582a8e1fc0cbc629ba38
new head: 48a6df083d036939a22a6935ff30c233a3e43ea8
overview: 
https://git.haiku-os.org/haiku/log/?qt=range&q=48a6df083d03+%5E15cb367a4000

----------------------------------------------------------------------------

497f099f5a24: Tracker: Clean up AddPoses threads properly.

  They may still be running at the point we detach from the window, and
  as we stop watching everything else at that point (and the threads
  themselves depend on the window looper as the global "lock"), we
  need to tear them down then.

  We especially cannot do this in the destructor, as there are some
  virtual methods that the threads need during their teardown which
  obviously will not work in ~BPoseView.

This analysis doesn't seem correct from how AddPosesTask works. The
latter locks the looper via BMessenger::LockTarget(), which in turn
operates by checking if the looper is valid via the global looper
list. If we're as far as BPoseView's d'tor, that is no longer the
case, and this will fail to lock, and things like
IsValidAddPosesThread won't be reached in such a circumstance. Also,
nothing with respect to the thread teardown is dependent on the looper
except in the successful completion case, and there likewise a lock is
acquired first. I suspect whatever crash is being seen here has a
different cause.

Regards,

Rene

Other related posts:

  1. Home
  2. haiku-commits
  3. Archive
  4. 09-2018