Opened 6 years ago

Last modified 4 years ago

#10037 reopened bug

ActivityMonitor replicant locks up Tracker upon startup

Reported by: stippi Owned by: axeld
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by diver)

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.

Tracker stack trace

Attachments (1)

IMAG0746.jpg (2.5 MB) - added by stippi 6 years ago.
Tracker stack trace

Change History (6)

Changed 6 years ago by stippi

Attachment: IMAG0746.jpg added

Tracker stack trace

comment:1 Changed 6 years ago by 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.

comment:2 Changed 4 years ago by diver

Component: - GeneralApplications/Tracker
Owner: changed from nobody to axeld

comment:3 Changed 4 years ago by diver

Description: modified (diff)
Resolution: fixed
Status: newclosed

comment:4 Changed 4 years ago by diver

Resolution: fixed
Status: closedreopened

comment:5 Changed 4 years ago by pulkomandy

Is it possible that 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?

Note: See TracTickets for help on using tickets.