ActivityMonitor replicant locks up Tracker upon startup

[stippi]

I am trying to debug a problem I am observing after the PM merge. Tracker locks up during boot. I am not sure yet what to make of it. I have an ActivityMonitor replicant on the Desktop. Someone decided it was a neat idea to watch for input devices in the System information monitor, even though that is not even supported in our input_server, yet. Anyway, this calls watch_input_devices(), which in turn calls _control_input_server_, which in turn sends a synchronous BMessage to the input_server. In the input_server, the messages is simply forwarded via PostMessage() to the AddOnMonitor. A reply is send there. The Tracker stack crawl is always the same, blocking in port_buffer_size_etc(), see attached screen shot. A couple of weird things go along with it:

• Deskbar always runs, I can use ProcessController to start the Debugger.
• Even though I have links to LaunchPad and Workspaces in my home/config/settings/boot/launch folder, only Deskbar runs. One time LaunchPad came up as well.
• I have changed the implementation of _control_input_server_() to send the message with a timeout of five seconds, yet Tracker still locks up.
• I have never seen this problem ever before the PM merge, but I embed the ActivityMonitor replicant since ages.

[stippi]

Tracker stack trace

[bonefish]

I don't have an explanation for the behavior, but I would recommend employing the kernel tracing feature to track this down. There's already some output prepared in BMessage::_SendMessage(), though it might be helpful to add the reply port/token as well. Then just enabled kernel tracing for BMessage (BMESSAGE_TRACING), ideally also for syscalls (SYSCALL_TRACING), and for team events (TEAM_TRACING) for good measure. This should allow following the message trail, with sufficient additional information to see what's going on. Stack traces in KDL (particularly for the input server, which is otherwise somewhat inconvenient to debug) help as well. Obviously you can also add other ktrace_printf()s at strategic points.

[pulkomandy]

Is it possible that ​http://cgit.haiku-os.org/haiku/commit/?id=3f57b13504ec30f19ec617feac42f1f69736967b was involved? It led to a freeze of activitymonitor because it was exhausing memory and CPU time in the view thread. Maybe something similar happened in your case?