Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#5042 closed bug (fixed)

Tracker prefs won't open, then cannot open any Tracker windows

Reported by: MichaelCrawford Owned by: axeld
Priority: critical Milestone: R1
Component: Kits/Application Kit Version: R1/Development
Keywords: Tracker, Preferences, Windows Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

This is with hrev34248, GCC 4 Hybrid under VirtualBox 3.0.8 on Fedora 11 x86_64.

When Haiku first starts, the Tracker operates normally - I can bring up folder windows and so on.

But if I try to open the Tracker preferences, the window doesn't appear.

After that I cannot get any new Tracker windows to appear at all - not just the prefs, but the folder windows.

This seems to be 100% repeatible. Once it starts happening, the only way to get new Tracker windows is to reboot.

Change History (10)

comment:1 by aldeck, 10 years ago

Never seen that problem, will update and have a look.
Tracker prefs is currently (temporary workaround) a very small app that sends a message to Tracker to open it's internal preference panel, if in some rare cases, Tracker isn't running it tries to start it.
Note that in cases such as yours, you should be able to quit (or at worst kill) and start again Tracker from ProcessController in the Deskbar. You might also get some debug output by starting it (/boot/system/Tracker) from the terminal.

comment:2 by aldeck, 10 years ago

Owner: changed from nobody to aldeck
Status: newassigned

Hmm, in fact no program at all will start after that. Using "hey Tracker do Preferences" works well, until you run preferences/Tracker, after that 'hey' will block and never return :/
Just updated my install looking into it.

comment:3 by aldeck, 10 years ago

After some binary searching i found out that the problem lies betwenn hrev34203 and hrev34229. I strongly suspect hrev34210, but can't totally confirm yet if it's a local rebuilding issue or if the mechanism introduced in hrev34210 is bogus, or both. At least syslog shows the new "server protocol version error", not always on the first time though, and leaves the system in a somewhat unusable state. Clean rebuilding as we speak. Axel?

comment:4 by anevilyak, 10 years ago

Possibly related issue: After a while Deskbar's Twitcher window hangs such that it can't be summoned with ctrl-tab any more. Kill/restarting Deskbar fixes it (temporarily) though. When it occurs, Twitcher's window thread is hung in a trace that looks like:

commpage_syscall()
port_buffer_size_etc()
BPrivate::LinkReceiver::AdjustReplyBuffer(long long)
BPrivate::LinkReceiver::ReadFromPort(long long)
BPrivate::LinkReceiver::GetNextMessage(long&, long long)
BPrivate::ServerLink::FlushWithReply(long&)
BRoster::ActivateApp(long)
TSwitchManager::ActivateApp(bool)
TSwitchManager::Stop(bool, unsigned long)
TIconView::Pulse()
BView::_Pulse()

comment:5 by axeld, 10 years ago

I'm currently looking into the latter, though I'm not sure they are related as I didn't see that message in the syslog yet.

comment:6 by axeld, 10 years ago

Component: - GeneralKits/Application Kit
Owner: changed from aldeck to axeld
Status: assignednew

Looks like the DesktopLink uses AS_GET_DESKTOP as well. That should be the reason - I'm currently looking into making this a bit nicer.

comment:7 by axeld, 10 years ago

Status: newassigned

comment:8 by axeld, 10 years ago

Probably fixed in hrev34394, at least the Switcher problem is. Please confirm.

Will fix the code duplication next :-)

comment:9 by aldeck, 10 years ago

Resolution: fixed
Status: assignedclosed

Fixed, thanks :)

comment:10 by anevilyak, 10 years ago

Confirmed here as well, thanks Axel!

Note: See TracTickets for help on using tickets.