Browse Prior Art Database

A method to selectively attach and remove probes in child processes from parents dynamic tracing session

IP.com Disclosure Number: IPCOM000235068D
Publication Date: 2014-Feb-26
Document File: 3 page(s) / 25K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article describes a method of allowing parent tracing session to implant selective trace points into its childern whenever they are created, without having to create a new debug session.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 3

A method to selectively attach and remove probes in child processes from parents dynamic tracing session

Described is a system to implant selective trace points into the children from parent's tracing session without having to create a new session.

Dynamic tracing framework provide users the facility implant trace points/probes on the fly in an application without having to recompile the same. This framework proves to be very helpful in identifying run time problem which can be daunting with static trace/debugging tools.

One of the dynamic nature of applications is to create child processes to take care of specific tasks. Application do create multiple threads for the same reason as per the requirement. Since threads form a part of the process and has same address space as parent, managing probe points in threads is fairly straight forward.

However, when a child process is created it gets a new address space, which makes it challenging to persist the probes in child process too. There is an additional challenge of implanting only selected probes into the child.

This disclosure aims to address the above 2 mentioned challenges in a dynamic tracing framework overcoming the difficulty posed by the existing mechanisms.

Existing framework in this respect provides facilities of creating a new session from within the

parent session to trace parent and child. Depending upon the number of children created, it could be a daunting task to manage data from so many sessions. Users would need to write multiple scripts and parse data and etc. to get all the output in a single view.

System disclosed here relies on following points:


1. Use of parent process structure to indicate loader for implanting probes when a child is created.


2. It is the trace point details which determine the session to which the traced data should be sent to.


3. If, trace points with details are kept in memory pre-allocated, patching the binary does is no to minimal overhead.

With the proposed solution in place, user would be expected to specify following things at minimum to utilize the functionality of implanting trace points in child processes.


1. User would need to specify all the probes and actions in the same script i.e. probes meant for parent and child both.


2. User would use a new facility named "ProbeTagging" to group the set of probes which need to be implanted into child processes.


3. User would write probe at fork system call and using an API facilitated by this framework, user would then register what set of probes to implant in child.

Lets look into finer details of how the above mentioned set of user actions together help achieve the required.


1. When the user provides all the probes including parent and child processes, dynamic tracing framework would initialize these internally. But patches only the ones, specified for parent

process using the "ProbeTagging" method. Thi...