Opened 13 years ago

Closed 4 years ago

Last modified 4 years ago

#7434 closed bug (not reproducible)

Tracker gets in a node monitoring loop

Reported by: jonas.kirilla Owned by: nobody
Priority: normal Milestone:
Component: Applications/Tracker Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #7552
Platform: All

Description

Recent changes to Tracker's Model class appears to set off node monitoring events, making Tracker windows loop.

I believe it happens only when Tracker is set to display localized names (via the Locale preferences) and I assume this is related to my recent changes to Model, where the SYS:NAME attribute is read (if present) when a Model is opened. It doesn't do any writing AFAIK, so I don't see how it happens.

Other node monitoring apps such as Pe and TextSearch pick up on the events too.

Change History (5)

comment:1 by jonas.kirilla, 13 years ago

Blocking: 7552 added

(In #7552) I don't think it's a good idea to make this option default to on without first fixing #7434. When set to translate Tracker window threads sometimes get in a loop and peg a CPU core. It's most likely due to my work and I apologize for not having put more effort into finding the root cause.

comment:2 by axeld, 7 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:3 by humdinger, 4 years ago

I've been running Haiku around hrev53636 32bit with the German locale (including the app/folder translation) for a week now.
I didn't encounter Tracker pegging a CPU in normal usage in this time.

I then used TextSearch to grep for "Window" in data/catalogs/ of the Haiku source, which turns up a large number of hits. Then I switched back and forth between the r1beta1 branch and current master, which should trigger many node monitoring events when catalogs dis/appear.
While the w>TextSearch thread does peg for quite some time, I suppose that's just due to the actual grepping. The PathMonitorLoop thread stays pretty calm throughout.

Maybe this issue was resolved in the past decade...

comment:4 by pulkomandy, 4 years ago

Resolution: not reproducible
Status: assignedclosed

Closing as not reproducible as no one has confirmed this in a while. Thanks for testing :)

comment:5 by nielx, 4 years ago

Milestone: R1

Remove milestone for tickets with status = closed and resolution != fixed

Note: See TracTickets for help on using tickets.