Fixing Tracker Crashes and Hangs on Haiku
Recover Tracker without rebooting, preserve Haiku crash and thread evidence, isolate folders, add-ons and settings, then verify the trigger.
Tracker is Haiku’s desktop and file manager. It is a user-space application, so a Tracker-only crash or hang does not require an immediate system reboot. First prove the scope, preserve crash or thread evidence, and use a supported team-control tool before changing settings.
Distinguish Tracker from a desktop-wide failure
Test Deskbar, another running application, keyboard shortcuts, and mouse movement. If other windows redraw and Deskbar works while folder windows/desktop icons do not, Tracker is the likely scope. If every window stops, investigate app_server, input, or kernel state instead.
A crash usually invokes Haiku’s debug workflow. Save the report/core before dismissing it. A hang does not create a crash report; attach Debugger to Tracker and save thread stacks, states, CPU use, and waits before terminating it.
Record Haiku revision/architecture, package state, open folders, view mode, action immediately before failure, mounted volumes/network shares, and whether the issue repeats.
Restart Tracker safely
Use ProcessController or Team Monitor/Debugger to quit Tracker normally. If it does not respond, terminate only the Tracker team after saving stacks. Haiku’s launch infrastructure normally starts the desktop component again; use the system launcher rather than an undocumented kill -9 pipeline.
Wait for desktop icons and folder windows to return, then test a neutral local folder. Unsaved file-operation state may be lost when forcibly terminating Tracker, so do not kill it during an active copy/move unless the alternative is an unrecoverable hang.
If Tracker does not restart, inspect launch/system logs and package availability. Repeated manual launches can create competing instances and obscure the original failure.
Isolate a folder, file, or volume trigger
If Tracker works until one folder opens, reproduce with that folder and note its view mode, item count, file types, attributes, and mounted filesystem. A malformed icon/attribute, problematic add-on/translator, slow network share, or file-system error can affect enumeration and rendering.
Create a separate test folder and copy suspected entries into it one at a time with an attribute-preserving Haiku tool. This binary-search style reduction can isolate one file without repeatedly opening a huge production directory. Compare the copied node’s MIME type, icon attributes, name encoding, size, and symlink target with a normal file of the same kind.
If creating, renaming, or deleting entries triggers the hang, record the exact operation and whether the folder is under an active query. Tracker consumes node-monitor and query notifications; a reproducible event-order problem is different from a static thumbnail decoder crash. Keep a screen recording or timestamps when several file operations are involved.
Move a suspected file using Terminal only after backing it up and confirming path identity. Do not delete the entire folder to test. Compare list view versus icon/thumbnail behavior; a failure only when previews/icons are generated narrows the code path.
Unmount removable/network volumes through supported UI and retest local BFS. Save syslog and check the volume safely if I/O errors appear. A Tracker hang waiting on a failing disk is not necessarily a Tracker logic bug.
Test settings and add-ons conservatively
Back up Tracker’s user settings directory/files, then rename only Tracker-specific state while Tracker is stopped. Relaunch with defaults. Do not delete all user configuration or claim a settings fix without identifying which state mattered.
If restoring previous windows immediately recreates the problem, keep the clean session and reopen folders one at a time. Preserve the old settings for developer reproduction.
Boot once with user add-ons disabled or temporarily isolate relevant non-packaged Tracker add-ons/translators. If the crash disappears, re-enable one component at a time. For an update regression, compare the previous package state rather than copying an old Tracker binary/library into current packagefs.
Diagnose and report
For a crash, inspect the faulting thread and first meaningful Tracker/add-on frames with matching symbols. For a hang, follow wait chains across Tracker threads and any server/volume dependency. A high-CPU stack and a blocked I/O stack require different fixes.
Check free RAM, boot-volume space, and package state, but do not treat resource pressure as an explanation without correlation. If several applications fail together, widen the scope; if only Tracker fails at one node, keep the report focused on that input and code path.
Search Haiku tickets using the symbolic frame, action, and file type. Attach complete report/stacks, exact steps, revision, settings/add-on comparison, filesystem/volume, and a minimal non-private sample if one triggers it. Keep private filenames/content sanitized.
After a fix, restart Tracker normally, reopen the triggering folder repeatedly, switch view modes, mount/unmount the relevant volume, and reboot. A desktop that merely reappears after termination is recovery; completion of the original action without new errors is verification.
Related:
- Fixing Haiku Boot Failures with Safe Mode
- Fixing and Diagnosing App Crashes Using Haiku’s Debug Server
Sources: