Tracker w>Desktop high CPU usage

[Meanwhile]

In Haiku r1a1, I get continuous high CPU usage of the Tracker w>Desktop thread. Icons actions are all impossible as a result: selecting, clicking, moving etc. My idea is that it is the high number of icons (177 at 64x64 size) that triggered it, but the attached serial will be more useful.

[Meanwhile]

serial debug output

[anevilyak]

That serial log appears corrupted.

[Meanwhile]

Replying to anevilyak:

That serial log appears corrupted.

True. (Added ungarbled version)

[anevilyak]

That log is very very abridged, and doesn't really yield a useful hint as to why that thread's busy. In fact the output appears to be almost entirely from the boot loader. Is serial_debug_output set to true in config/settings/kernel/drivers/kernel ?

[Meanwhile]

Okay, fixed the settings.

[anevilyak]

That looks better...however, whatever the Desktop thread is doing to stay busy isn't resulting in any kernel activity that winds up on serial, so it's probably not an I/O issue or anything in that vein. Does it have high CPU usage even when just idling, i.e. no mouse/keyboard activity?

[anevilyak]

Also, did this start recently or has r1a1 always been doing that for you?

[Meanwhile]

Recently, as the system was stable for a long time. Since all I did on it was icon development, what changed was nothing else than the amount of icons added to the Desktop (or so I figure).

[Meanwhile]

Replying to anevilyak:

That looks better...however, whatever the Desktop thread is doing to stay busy isn't resulting in any kernel activity that winds up on serial, so it's probably not an I/O issue or anything in that vein. Does it have high CPU usage even when just idling, i.e. no mouse/keyboard activity?

Yes it does.

[anevilyak]

In that case it seems likely that either the view info attr got corrupted or there's an icon on there whose data's tripping it up somehow, as it shouldn't be doing anything whatsoever otherwise. Can you try quitting Tracker, removing the _trk/pinfo_le attribute from /boot/home/Desktop via Terminal's rmattr and starting Tracker again? If that makes no difference, (this may be a bit tedious) try moving icons into another folder temporarily and see if removing any particular one fixes the behavior. Tracker restarts might be needed after icon moves depending on how that thread's getting stuck.

[anevilyak]

Also, _trk/viewstate_le might be worth trying to remove.

[Meanwhile]

What should I type exactly into the Terminal to do that? (not used to using terminal at all)

[Meanwhile]

After quitting Tracker, I typed: rmattr _trk/pinfo_le Desktop and restarted. If that's correct, the situation is unchanged.

[Meanwhile]

After typing: rmattr _trk/viewstate_le Desktop there are no changes in behaviour. Only the icons are all displayed in a smaller size now.

[Meanwhile]

Moving icons into anothe folder is impossible. In fact I already tried to move them off the Desktop one by one, using another Haiku partition's 'Find' app.

[anevilyak]

In that case, you could try:

mkdir /boot/home/icons ; mv /boot/home/Desktop/* /boot/home/icons

From the Terminal (without Tracker running). That should put all of them in /boot/home/icons. If that fixes it, it would be interesting to know if opening /boot/home/icons in Tracker causes the window for that folder to likewise spike.

[Meanwhile]

Nice, that method removed the spike along with the icons. /boot/home/icons also shows no spike. Thanks, anevilyak.

[stippi]

Hm. I am unfortunately too late with my suggestion, but next time, you can traverse to the busy thread in ProcessController and click it to "Debug this thread". Then you can at least see where the thread was in a back trace.

[axeld]

You might also want to check if a more recent revision behaves the same.

[Meanwhile]

Replying to stippi:

Hm. I am unfortunately too late with my suggestion, but next time, you can traverse to the busy thread in ProcessController and click it to "Debug this thread". Then you can at least see where the thread was in a back trace.

Redid it, see attachment

[anevilyak]

Just to verify, what's seen in 5128DeBug.txt is in fact when the thread is looping forever?

[Meanwhile]

Replying to anevilyak:

Just to verify, what's seen in 5128DeBug.txt is in fact when the thread is looping forever?

Correct, the situation was recreated by placing the same troublesome icons on the Desktop again. Then stippi's instructions were followed. I don't remember if the spike went away after clicking the 'DeBug' button, though...can't find the folder with the backup of those icons at the moment.

[Meanwhile]

Replying to Meanwhile:

Replying to anevilyak:

Just to verify, what's seen in 5128DeBug.txt is in fact when the thread is looping forever?

Correct, the situation was recreated by placing the same troublesome icons on the Desktop again. Then stippi's instructions were followed. I don't remember if the spike went away after clicking the 'DeBug' button, though...can't find the folder with the backup of those icons at the moment.

Err, I meant to say: 'I don't remember if the spike went away after clicking the "Debug this Thread!" button, or after clicking the 'DeBug' button' (it went away in any case).

[Meanwhile]

The bug is still present in hrev38360; this time with only 155 icons on the Desktop. Anything that lies on top of the icons after the spiking behaviour occures wipes them away (i.e. you get to see only the background where the overlying element was, so that -for example- a screensaver effectively wipes all icons off. Did the Terminal trick again, thanks.

It seems that the amount of icons doesn't trigger it, nor does any particular troublesome icon. The situation announces itself in that tracker becomes a bit unstable.

This time I noticed it wasn't the addition of a new icon on the Desktop, but an adding-and-saving action of an icon's gradient to an icon that already sat on the Desktop.

Maybe the Desktop can hold only a certain weight in icons. In this case there were 78 non-linked icons together weighing 1.84 MiB at the time of the crash/spike.

[anevilyak]

Fixed in hrev39012.

[Meanwhile]

Replying to anevilyak:

Fixed in hrev39012.

Thanks a lot!