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

[MichaelCrawford]

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.

[aldeck]

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.

[aldeck]

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.

[aldeck]

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?

[anevilyak]

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()

[axeld]

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.

[axeld]

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.

[axeld]

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

Will fix the code duplication next :-)

[aldeck]

Fixed, thanks :)

[anevilyak]

Confirmed here as well, thanks Axel!